topic Re: VMS/Alpha 8.2 BUGCHECK -- UNXSIGNAL, Unexpected signal name in ACP in Operating System - OpenVMS

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

David B Sneddon — Fri, 25 Mar 2005 07:10:59 GMT

Hi Folks,

Situation: I have a Digital PWS600au which has been running fine.
I recently acquired additional disks and a BA356 so I decided to setup
shadowing. I made the necessary SYSGEN changes and
changes to my startups using exactly the same method
I use on our machines at work.
On rebooting with shadowing enabled, it looks like it is proceeding
well (I use a boot flag of 0,20000 to see what is hapenning)
then it bugchecks with the above code.
Has anyone else come across anything similar?
The only difference between what I am doing at home and the machines
at work is that my machine is running V8.2.
Attached is the output from the SDA commands
CLUE CRASH
SHOW PROCESS
SHOW CALL
SHOW CALL/NEXT (until it ends)
If I change the configuration to NOT use shadowing, it works
fine (this is the machine I am using to post this).
With shadowing enabled, it always bugchecks.

Regards
Dave

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

Volker Halle — Fri, 25 Mar 2005 07:42:34 GMT

Dave,

nice, the first real V8.2 crash I've seen up to now ;-)

Could you please post the SDA> CLUE REGISTER output or even the full CLUE file from CLUE$COLLECT:CLUE$ZEN_250305_1107.LIS ?

Volker.

PS: If you look at your previous attachment from your OpenVMS system, can you correctly read it ? I'm having problems reading it from a non-VMS platform (looks like embedded control chars).

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

David B Sneddon — Fri, 25 Mar 2005 08:22:52 GMT

Volker,

nice, the first real V8.2 crash I've seen up to now ;-)

Glad to be of service ;-)
Pity all I wanted to do was turn on shadowing...

Attached is the CLUE$COLLECT file.

I was able to read the previous attachement on VMS,
I can also read it when I download it to a Mac.

Regards
Dave

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

Volker Halle — Fri, 25 Mar 2005 09:15:33 GMT

Dave,

the crash is in module [F11X]MAPVBN routine MAP_VBN

The code expects to handle a FCB (File Control Block) in R3, but there is a WCB (Window Control Block)

LDL R16,#X000C(R3) will pick up WCB$L_PID instead of FCB$L_EXFCB and when using the value in R16 as an address, it crashes. R1 contains 0001001A, which is the internal PID of the current process !

R11 should also contain a FCB instead of a WCB, maybe the current WCB has a problem, what's stored at CWB$L_FCB (should be a pointer to the FCB)

Try SDA> READ SYSDEF
SDA> FORMAT 822275C0
to look at the current WCB.

If you can escalate this to HP engineering, please do so.

Volker.

Crash footprint summary:

V8.2 UNXSIGNAL at MAP_VBN_C+00168: LDL R19,#X0058(R16)
R16 = 0001001A (internal PID of current process)
R11 and R3 pointing to WCB instead of FCB

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

David B Sneddon — Fri, 25 Mar 2005 09:31:59 GMT

Volker,

WCB$L_FCB does indeed point to an FCB.
This is a hobbyist machine, so unless someone
happens to spot this thread I have no "official"
mehanism for escalating it.

Dave

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

Volker Halle — Fri, 25 Mar 2005 09:45:34 GMT

Dave,

then there must be some other WCB around, which has it's WCB$L_FCB field point to the current address in R3 (=822275C0). MAP_VBN is entered with a WCB pointer and the current FCB address (should be in R11) is obtained from WCB$L_FCB of that WCB.

You would need to search nonpaged pool for this WCB address:

SDA> search @MMG$GL_NPAGEDYN:@mmg$gl_npagnext 822275C0

Then for every location in nonpaged pool, where this address is found (address should end with xxx4), try SDA> FORMAT addr-24 to see if it's a WCB.

That's how crashdump analysis works ;-)

Volker.

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

David B Sneddon — Fri, 25 Mar 2005 10:15:29 GMT

Volker,

Match at FFFFFFFF.82016260 822275C0
Match at FFFFFFFF.82016278 822275C0
Match at FFFFFFFF.820F8B0C 822275C0
Match at FFFFFFFF.820F8B18 822275C0
Match at FFFFFFFF.8210CE18 822275C0
Match at FFFFFFFF.82213A60 822275C0

None of which end in xxx4.
Attempting the FORMAT reveals no WCBs

Dave

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

Volker Halle — Fri, 25 Mar 2005 11:31:01 GMT

Dave,

offset 0x18 of a FCB is FCB$L_WLFL, the queue header for the list of WCBs linked to that FCB, so

SDA> FORMAT 82016260
SDA> FORMAT 820F8B00

may format as FCBs.

The WCBs are linked via their queue header (WCB$L_WLFL offset 0x0), try

SDA> VALI QUE/LIS 822275C0

As this problem seems to be reproducable on your node, try setting the system parameter SYSTEM_CHECK = 1, this will load code with additional checking regarding pool allocation problems etc. Then boot with shadowing enabled and see what happens...

Does the crash always happen in DECW$STARTUP ? TYPE CLUE$HISTORY will list all the crashes (1 line each) including the current process name.

Volker.

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

David B Sneddon — Fri, 25 Mar 2005 21:59:46 GMT

Volker,

SDA> FORMAT 82016260 is an invalid type
SDA> FORMAT 820F8B00 gives an FCB

SDA> VALI QUE/LIS 822275C0

Entry Address Flink Blink
----- ------- ----- -----
Header 822275C0 820F8B08 820F8B18
1. 820F8B08 00070180 822275C0

Error in forward queue linkage at address FFFFFFFF.820F8B08, after tracing 1 element
%W, unable to access location 00000000.00070180

Yes it always happens in DECW$STARTUP.

I have set SYSTEM_CHECK = 1 and will look at
the crash dump with that set.

Dave

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

Volker Halle — Sat, 26 Mar 2005 03:28:15 GMT

Dave,

it would be interesting to find the file associated with this crash. There are multiple ways to do this:

SDA> SHOW PROC/CHAN

should list at least one BUSY channel to DSA1000: and the file-id of that file (fid,seq,rvn)

$ DUMP/IDENT=(fid)/HEAD/BLOCK=COUNT=0 DSA1000:

should list the file header.

You can also follow the IRP pointed to by R6 in the crash.

SDA> EXA +IRP$L_CHAN should give the channel number

SDA> SHOW PROC/CHAN should then show the file-id for this channel

Note that routine REMAP_FILE has been executed immediately before the crash (as can be seen from the current contents of PV = R27). This routine will map the entire file, eventually creating multiple WCBs and linking them.

SDA> VALI QUE/LIS 822275C0

Entry Address Flink Blink
----- ------- ----- -----
Header 822275C0 820F8B08 820F8B18
_______________^^^^^^^^ ^^^^^^^^
_______________WCB$L_WLFL WCB$L_WLBL
1. 820F8B08 00070180 822275C0
___________^^^^^^^^ ^^^^^^^^
___________FCB$W_SIZE FCB$L_EXFCB

The WCB$L_WLFL points to FCB$W_SIZE field of the FCB, WCB$L_WLBL points to FCB$L_EXFCB, which again proves, that this WCB is linked (instead of an extension FCB) to FCB$L_EXFCB of the FCB at address 820F8B00 - this may be what got the WCB in R3 and caused the crash...

So there is some 'mess' regarding the links of this FCB and it's WCBs.

Volker.

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

David B Sneddon — Sat, 26 Mar 2005 04:02:16 GMT

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

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

Volker Halle — Sat, 26 Mar 2005 06:12:59 GMT

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.

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

Volker Halle — Sun, 27 Mar 2005 10:43:55 GMT

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.

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

David B Sneddon — Tue, 29 Mar 2005 21:08:44 GMT

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

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

David B Sneddon — Wed, 06 Apr 2005 08:21:05 GMT

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

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

David B Sneddon — Thu, 07 Apr 2005 19:31:47 GMT

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

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

David B Sneddon — Thu, 07 Apr 2005 20:56:45 GMT

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

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

David B Sneddon — Sun, 01 May 2005 07:13:03 GMT

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

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

Volker Halle — Sun, 01 May 2005 11:07:46 GMT

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.

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

David B Sneddon — Sun, 01 May 2005 17:45:59 GMT

Volker,

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

Dave.