Operating System - OpenVMS
1748030 Members
5196 Online
108757 Solutions
New Discussion юеВ

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

 
SOLVED
Go to solution
David B Sneddon
Honored Contributor

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

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
51 REPLIES 51
Volker Halle
Honored Contributor

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

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).
David B Sneddon
Honored Contributor

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

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
Volker Halle
Honored Contributor

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

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

David B Sneddon
Honored Contributor

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

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
Volker Halle
Honored Contributor

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

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.
David B Sneddon
Honored Contributor

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

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
Volker Halle
Honored Contributor

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

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.
David B Sneddon
Honored Contributor

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

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
Volker Halle
Honored Contributor

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

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.