VMS/Alpha 8.2 BUGCHECK -- UNXSIGNAL, Unexpected signal name in ACP

[David B Sneddon]

Volker,

The busy file was [VMS$COMMON]SYSMGR.DIR.
The other files were
DECW$STARTUP.COM
DCL.EXE
DCLTABLES.EXE

zen_FTA13> dire dkb0:[vms$common]sysmgr.dir

Directory DKB0:[VMS$COMMON]

SYSMGR.DIR;1 31/33 5-MAR-2005 09:18:23.70

Dave

[Volker Halle]

Dave,

there really can't be anything wrong with the file header of that file, can't it ?

Anyway $ ANAL/DISK DKB0 (ideally when booted from CD), should make sure the disk structure is o.k.

Did SYSTEM_CHECK=1 report any other crash ?

We now have to go back to pool and find out, who else is pointing to this WCB:

Match at FFFFFFFF.82016260 822275C0 ?
Match at FFFFFFFF.82016278 822275C0 ?
Match at FFFFFFFF.820F8B0C 822275C0 FCB$L_EXFCB
Match at FFFFFFFF.820F8B18 822275C0 FCB$L_WLFL
Match at FFFFFFFF.8210CE18 822275C0 ?
Match at FFFFFFFF.82213A60 822275C0 ?

Use the following commands:

SDA> SHOW POOL/HEAD/FREE 82016260-1000;1000
SDA> SHOW POOL/HEAD/FREE 8210CE18-1000;1000
SDA> SHOW POOL/HEAD/FREE 82213A60-1000;1000

Find the data structures in pool, which include the above matching addresses (use packet start address and size). What type of packet is it ? Is the packet still allocated or is it on the [Free] or [List] pool queues ? What field has the WCB address in it ?

Volker.

[Volker Halle · Accepted solution]

Dave,

the FCB pointed to by the current WCB has it's FCB$L_WLFL/BL queue corrupted:

SDA> format 82134A80
FFFFFFFF.82134A80 FCB$L_FCBFL 82134C00
FFFFFFFF.82134A84 FCB$L_FCBBL 82132480
FFFFFFFF.82134A88 FCB$W_SIZE 0180
FFFFFFFF.82134A8A FCB$B_TYPE 07
FFFFFFFF.82134A8B FCB$B_ACCLKMODE 00
FFFFFFFF.82134A8C FCB$L_EXFCB 82262600
^ <<< points to WCB instead of being ZERO
FFFFFFFF.82134A90 FCB$L_PRIMFCB 00000000
FFFFFFFF.82134A94 FCB$L_ORB 82134B48
FFFFFFFF.82134A98 FCB$L_WLFL 82262600 <<< points to current WCB
FFFFFFFF.82134A9C FCB$L_WLBL 82134A98 <<< WLFL/BL queue is corrupt
FCB$L_WLBL pointer is in xxxxx8C instead of 9C
<<< FCB$L_WLBL has NOT been written to while linking WCB


The current WCB forward link points to the wrong field in the FCB.

SDA> form 82262600
...
FFFFFFFF.82262600 WCB$L_WLFL 82134A88 <<< should point to xxxxxx98
FFFFFFFF.82262604 WCB$L_WLBL 82134A98

This explains, why the crash is happening (the code thinks there is an extension FCB$L_EXFCB, but crashes when it really is a WCB), but why the FCB$L_WLFL/BL queue is corrupt is still a mystery.

Volker.

[David B Sneddon]

Bit of an update...

The trigger for the crash seems to be having the system disk shadowed
and using decwindows.
If I shadow the system disk but don't start decwindows automatically
then login and manually start decwindows the crash will occur.
If I have shadowing enabled (but don't shadow the system disk)
then decwindows will startup fine and I can successfully create shadowsets
of data disks.

A VERY BIG thankyou to Volker, who spent a big part of
Sunday examining the crash dumps.

More to come later (hopefully)

Dave

[David B Sneddon]

And the problem was...

after upgrading firmware, installing the V8.2 graphics patch,
all with no change to the outcome, I thought I would try a
different graphics card -- a different card works fine.

The card that causes the problem is a PBXGB-AA (ZLX2-E, TGA2).

The card that worked OK was an S3 Trio64. The problem with it
is it won't do 1280 x 1024 which is what I use.
Any suggestions on a suitable card that will give me
the resolution of 1280 x 1024?

Again, many thanks to Volker for the work he did on
this problem, I learnt a lot in the process.

Regards
Dave

[David B Sneddon]

Another update.
I wasn't happy with my last findings. The PBXGB-AA is
a supported card (according to the release notes).
I did a fresh install of V8.2,
absolute minimum setup, just enough to install licenses.
Did a conversational boot and enabled shadowing on
the system disk and let it boot and start decwindows
and it all worked fine...
So the card works with the configuration I want,
just not with my current system disk.
I shall continue investigating (either that or I have
to start with a fresh disk -- which I don't like
since it doesn't seem the "VMS way")

Dave

[David B Sneddon]

More info...

I just tried my "broken" system disk in another
system (Alphaserver 1200) with a PBXGB-AA.
It works fine. It would seem that the problem is
very specific to my hardware... more fun

Dave

[David B Sneddon]

Latest update...

Since my initial test with a fresh 8.2 install seemed to
indicate it worked, yesterday I decided to go with it
and build a fresh system disk but alas, it failed with
the same problem.
So at this point it would appear that there is some rather
obscure interaction between the graphics card and having
shadowing enabled on the system disk.
At the moment I have shadowing enabled and have five active
shadowsets with no problems.
For now I will keep an eye on any 8.2 ECOs that may be
related and in the meantime will enjoy a Duvel whilst
waiting.
(I managed to find a supplier of Duvel, only a five
minute drive from work, and it is a most excellent
brew, if a tad expensive, but worth every cent.)

Regards
Dave

[Volker Halle]

Dave,

thanks for reporting further updates. What are you using as a workaround now: not shadowing the system disk ?

As this is so reproducable with your config, it would the 'classic case' for using the Watchpoint Driver (WPDRIVER) to set a watchpoint on FCB$L_EXFCB and catch the code, which is writing a bad address into that field.

When I tested WPDRIVER with E8.2, it crashed. Maybe it's time for another test with V8.2 ?

Volker.

[David B Sneddon]

Volker,

I am not shadowing the system disk.
Watchpoint is broken on V8.2

Dave.