Strange ES40 Boot Solution

[Bob Olewine]

Has anyone seen this ...

I have an ES40 configured:
> 2 front cages with 2 each 18gb disks
the default boot device is DKA0
> 16 gb memory
> 2 @ 1gb fibre cards
> 1 SCSI card
> 1 @ 10 / 100 NIC card with a SCSI port
> CD drive
> Floppy drive

The O/S is OpenVMS V8.3
> with patch kit 12
> patch kit ACRTL V600
> the LDAP ACME Server is installed
but not functional yet in that
the SYSUAF records are not modified.

The problem is after an INITIALIZATON .or. power
reset .or. any other 'COLD' boot situation.

When the 'P00>>' appears and the default boot
(to one of the front cage disks) is invoked,
P00>> boot -flag 0,0 , the boot fails
with a stack dump and returns to the 'P00>>'
prompt.

In the past simply repeating the boot solved the
problem and the system came up, ie: P00>> boot -flag 0,0

Now the boot continues to fail unless I jump through
some hoops which I will describe later.

I have booted with the flags set to 0,30000
and gotten the messages:

The last message before the failure is:
> Checking if this system supports deferred memory testing.
> This system does not support deferred memory testing.

Then a '****' box is drawn and inside the box is the
message:
* Exception taken before handler has been loaded ! *
* Unable to take crash dump! *

Then a message:
Access control violation through vector 00000080

Then the usual stack dump.



It did not matter ... I booted -flags 0,30001
and at sysboot:
> set mmg_ctlflags 7 and 0 also was tried
> set writesysparams 0
> continue

Still get the same messages.


Also the VMS V8.3 distribution CD will not boot.
VMS was upgraded to V8.3 in Jan 2009 and aggreate
patched at that time and the patches have been applied
as they have been released.

The firmware is at V7.3 and as far as I can tell is
current ... both AUTO and manual modes.


My work-around for booting from an INITIALLIZED state
is:
First Try: P00>> boot -flag 0,0
>>Results: get the expected failure and stack dump.

Second Try: P00>> boot -flag 0,0
>> Results: same as 'First Try' .

Third Try: Load CD for VMS V7.3 distribution
P00>> Boot -flag 0,0 DQA0
>> Results: Get the following message:
SYSBOOT-I-GCTMINOR, GCT used with minor revision mismatch
expected 00000005.00000001 got 00000005.00000002

continues with the usual failure and stack dump.

Fourth Try: Remove and Save the VMS V7.3 CD
P00>> boot -flag 0,0
>> Results: NORMAL VMS boot ... system is up and
working as expected.

WARM boots from here on work as advertised.


In the case of a 'COLD' BOOT ... revert back to
'FIRST TRY'.

As a result I have determined that 'Until Further Notice'
I will not do INITs or System ReSets unless I just have to.

-0-

[Volker Halle]

Bob,

just a quick guess:

>>> SHOW MEMORY_TEST

This environment variable needs to be set to FULL for OpenVMS systems. If not, it may cause 'strange symptoms'.

Volker.

[labadie_1]

Hi

The SRM parameter Memory_test is set to PARTIAL or FULL ?

can you try to boot with this parameter to FULL ?

[Bob Olewine]

Volker and labadie, ...

First off ... Thank you.

Right now the memory_test is NONE for no other
reason than it just takes so long for the
memory to test. I will give it a try though.

Bob /

[Bob Blunt · Accepted solution]

I'm pretty sure VMS requires MEMORY_TEST to be set to full on the Alphas. I had tried to monkey with this in our lab for the same reason, reducing boot time, and always ran into trouble if it was anything but "full"

[Colin Butcher]

I had some strange problems with first boot of an ES40 which were resolved by changing the memory test to FULL. It's worth a try.

It's also worth updating the firmware to the latest, just in case. There used to be a nasty little problem with SCSI_POLL back around V6.8 firmware I remember - didn't find all the devices properly if SCSI_POLL was set to a non-default value.

Cheers, Colin (http://www.xdelta.co.uk).

[labadie_1]

I remember, among other problems, RDB failing miserably when starting VMS with this parameter at another value than FULL.

The error message was puzzling.

[Bob Olewine]

I will not be able to test the
'set memory_test full' until Monday.
Will assign points then if that is OK.

Thank you-all for the input. I am
excited that so many of you seem to agree on the fix.

Bob /

[cnb]

Hi Bob,

From the Firmware Release Notes:

ftp://ftp.hp.com/pub/alphaserver/firmware/current_platforms/v7.3_release/DOC/es40_v73_fw_relnote.pdf

"Set Memory_Test
The memory_test environment variable [EV] allows the console to test a fixed amount
or memory. The default value of full is to test all of memory. The other values shown
are used for testing only:
P00>>> set memory_test full ; test all memory (default value)
P00>>> set memory_test partial ; test 128MB memory (for mfg use only)
P00>>> set memory_test none ; test 32MB memory (for mfg use only)
***The memory_test EV should be set to the default value before booting an operating
system.***"

HTH

Rgds,

[Bob Olewine]

Greetings everyone and Thank you.

The set memory_test full solved the
problem.
I INITIALIZEd the console and
used the front button to restart and reload the SRM console. Boots after each condition worked as advertised.

I will assign points now; but if someone could contact Mr. Volker and have him respond again so I can add a few more points for him since he was also correct before I close the thread.

Thank you all again.

Bob Olewine /