Cannot form DSA0:

[FOX MULDER_2]

Hi,
I am having a problem with a VMS server running on V6.2,the details are as follows :
When the system is booting in a single disk DKB0 its working fine.
When booting in sysboot and enabling shadowing of system disk :
>>>b -fl 0,30001 DKB0
sysboot>set SHADOW_SYS_DISK 1
sysboot>cont
the server crashes giving a dump :

BUGCHECK ****

** Code=000003C4: SSRVEXCEPT, Unexpected system service exception

** Crash CPU: 00 Primary CPU: 00 Active CPUs: 00000001

** Current Process = STACONFIG

** Image Name = STACONFIG.EXE

**** Writing dump to HBVS member with unit number of 0

**** Starting Memory Dump...

..............

**** Global page table not in memory - no global pages dumped

**** Memory Dump complete - not all processes saved


Can anyone please let me know how to solve the problem ?

Thanks

[Duncan Morris]

Hi,

do you have all the available 6.2 patches installed?

In particular, do you have ALP_CLUSI installed?

Duncan

[FOX MULDER_2]

Hi,
Thanks for the prompt reply.

The update patches are not installed,but it was working fine for ~ 2 years.
A few days back it was crashed and I am unable to add system disk shadow member.
I have a plan to install the patches but other than that is there any way to recover it.

"In particular, do you have ALP_CLUSI installed?"
What is ALP_CLUSI ?

Thnaks

[Karl Rohwedder]

How are the other shadowing parameters set, esp. SHADOWING, SHADOW_SYS_UNIT..?

regards Kalle

[Wim Van den Wyngaert]

Did the same thing in VMS 7.3 (not fully patched, no shadow license) and got a bugcheck too. But with process/exe sysinit.

And it started looping on "accessing system disk via original boot path".

Idem when I put shadowing on 1 too.

I normally change the params before the boot.

Wim

[FOX MULDER_2]

Hi,
The other params are;

Shadowing = 2
Shadow_sys_unit = 0 !as it is DSA0.

This is not a problem with license since,there are other disks also which are shadowed and are working fine.

Thanks

[Duncan Morris]

So, the system disk was part of a shadow set before the crash.

Have you tried booting from the "other" member of the shadowset? There may be a problem in the consistency of the shadowset itself.

Duncan

[Wim Van den Wyngaert]

Is your allocation class non-0 ?
(sysgen show alloc)

Wim (had tested with shadowing = 2, and also with license : same reaction)

[Wim Van den Wyngaert]

Out of doc : "You must use a nonzero allocation class for each physical device in the shadow set.".

VMS could tell you that in a nicer way ...

Wim

[FOX MULDER_2]

Hi,
Thanks to all for replying.
The system disk was shadowed before the crash.

Alloclus is set to 1.

Also,have tried booting from the other member also,same result.

Also,have restored image from tape,same result.
Hardware : no alerts or indication found.

Can anyone tell me where to find the description of the file staconfig.exe ?

[Wim Van den Wyngaert]

Staconfig is used to determine the system disk connection.

000003C4 means "no such disk quorum file". Could the file be corrupt ? Is it present ? But then why is it only checked when using shadowing.

Wim

[Volker Halle · Accepted solution]

Fox,

STACONFIG.EXE is an OpenVMS program run early during boot/startup to configure the device IO database. This program has incurrect a system service exception in kernel mode and caused the system to crash. Let's see, if we can obtain some more information from the system dump.

Once you system has written the dump, boot without using a shadowed system disk and look at the CLUE file (CLUE$COLLECT:CLUE$node_ddmmyy.LIS). It should be generated from the system dump automatically during boot.

Please post the CLUE file as a text attachment.

Volker.

[Volker Halle]

Wim,

000003C4 is the bugcheck code for SSRVEXCEPT !

ANAL/SYS
SDA> SHOW BUG 3C4

Volker.

[FOX MULDER_2]

Hi,
The dump file is not getting updated.

$ dir sysdump.dmp/date=(c,m)

Directory SYS$SYSROOT:[SYSEXE]

SYSDUMP.DMP;3 14-DEC-1996 16:29:13.79 23-NOV-1997 12:04:06.89

Total of 1 file

So,I think it is dumpede into the pagefile.

While I issued the command :
SDA> Sh crash

System information
------------------
Version of system: OpenVMS (TM) Alpha Operating System, Version V6.2

System Version Major ID/Minor ID: 3/0


System type: AlphaServer 2100 4/275

Primary CPU ID: 00

Bitmask of CPUs active/available: 00000001/00000001

CPU 00 database address: 80B10000

Is there any other way,to get the dump?

thanks

[Wim Van den Wyngaert]

"If SYSGEN system check is enabled, the first MOUNT of a system disk will crash the system." (patch 6.2 that you might not have)

(SYSGEN SHOW SYSTEM must be 0)

Wim

[Volker Halle]

Fox,

the dump is getting written to DKB0 as indicated by:

**** Writing dump to HBVS member with unit number of 0

The dumpfile modification date is NEVER updated by writing the dump. Writing the dump happens without any file system operations, the memory pages get just dumped into the blocks representing the dumpfile.

Is there a recent CLUE file (CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS) ?

What does $ ANAL/CRASH SYS$SYSTEM report ?

Volker.

[FOX MULDER_2]

Hi,

OpenVMS (TM) Alpha System dump analyzer

%SDA-E-DUMPEMPTY, dump file contains no valid dump


This is the output when
ana/crash sys$system
is given.

Thnaks

[Robert Brooks_1]

Out of doc : "You must use a nonzero allocation class for each physical device in the shadow set.".

VMS could tell you that in a nicer way ...

--

Starting with V8.3, one gets a SHDWREQALLOC bugcheck with the following text . . .

Allocation class is required for shadow set members.

-- Rob

[Martin Hughes]

Do you have the latest shadowing patch for 6.2?. See
http://ftp.support.compaq.com.au/pub/ecoinfo/ecoinfo/a62.htm

[Nigel Wright_1]

Is this system disk - when it was formed before as a shadow - mounted on another node in the cluster? If it was, is it still mounted now? What do the other nodes think is the state of this shadow disk?

Nigel.

[Steve-Thompson]

Hello Fox

Should Nigels idea is hitting the mark, boot a different disk (eg. CD) and do a mount/ov=(id,shad) .
This will zero the shadow generation information on the disk.

Steven

[FOX MULDER_2]

HI,

The outputs are :
SYSGEN> SH SYSTEM
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
SYSTEM_CHECK 0 0 0 1 Coded-valu
SYSGEN> SH ALLOC
Parameter Name Current Default Min. Max. Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
ALLOCLASS 1 0 0 255 Pure-numbe
SYSGEN>

Also,the system is not in a cluster.
I have tried the following steps already:

At the >>> prompt boot the operating system CD ie B DKA600
When the menu option appears, select DCL commands.
at the $$$ prompt Mount/over=(id,shadow) DKB0:
When the disk is mounted write a scratch file to DKB0:
Dismount DKB0:
logout of the DCL interface and shutdown
At the >>> prompt, boot OBERON conversationally ie B -flags 0,1 DKB0
At the sysboot prompt set the parameter shadow_sys_disk to 1
Continue to boot.
The result is just the same.

Thanks.

[Volker Halle]

Fox,

if the system has completely written the dump - as shown in your initial post, you should be able to boot without shadowing the system disk and read the dump with ANAL/CRASH SYS$SYSTEM:

To see, if there is anything in the dumpfile at all, try:

$ DUMP/BL=COUNT=2 SYS$SYSTEM:SYSDUMP.DMP

Volker.

[FOX MULDER_2]

Hi,
Even after issuing the command :
DUMP/BL=COUNT=2 SYS$SYSTEM:SYSDUMP.DMP

Its showing the same.

OpenVMS (TM) Alpha System dump analyzer

%SDA-E-DUMPEMPTY, dump file contains no valid dump

Not sure if this is right,since the dump file, size is small therefore it is not updating.

Thanks,

[Volker Halle]

Fox,

the DUMP command given just dumps out the first 2 blocks of the dumpfile to your terminal screen. Are the values all zeroes ? Do you somewhere see the nodename in the ASCII data ?

Volker.