Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

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

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

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

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

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
Honored Contributor
Solution

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Volker,

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

Dave.
Robert Brooks_1
Honored Contributor

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

I'll jump into the fray. I'm interested in collecting some data that will absolve Shadowing.

What I'm about to ask you to do is quite unsupported, so you can happily ignore this request. If something "strange" happens, the support centre may not want to hear about it.

Prior to rebooting with shadowing enabled, go into SYSMAN and issue this command . . .

SYSMAN> SYS_LOAD ADD TR$DEBUG TR$DEBUG /LOAD_STEP=INIT/LOG

The above command will load a tracing utility early on in the booting process.

within SYSGEN, set SHADOW_D5 %XFFFFFFFF

The shadowing driver uses SHADOW_D5 to control what info is traced. I can't remember what bits are actually used, so setting all bits to be on is the easiest thing to do.

Note: It's not a good idea to leave tracing enabled for production use; there is a bit of a performance cost (it's not, however, as pronounced as setting SYSTEM_CHECK = 1).


Once this experiment is complete, please reset SHADOW_D5 = 0. To remove the early
loading of the tracing utility, get back
into SYSMAN . . .

SYSMAN> SYS_LOAD REMOVE TR$DEBUG TR$DEBUG/LOG

After the expected crash, analyze the crash dump. Within SDA, issue these commands

SDA> SET OUTPUT shadowing.txt
SDA> TR SHOW TRACE
SDA> EXIT

. . . and post shadowing.txt here

It may be that we won't find anything interesting, but it's a first step.


-- Rob
David B Sneddon
Honored Contributor

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

Rob,

Welcome to the fray! It was getting rather lonely here.
[Un]Supported is not an issue, this is a hobbyist
machine.

I will load the tracing stuff tonight and see what we
get.

Dave
David B Sneddon
Honored Contributor

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

Rob,

I followed your instructions, rebooted and got the expected crash.
It would appear however that TR$DEBUG did not get loaded.

zen_FTA11> anal/crash UNXSIGNAL-20050505-0930.DMP;1

OpenVMS system dump analyzer
...analyzing an Alpha full memory dump...

Dump taken on 5-MAY-2005 09:30:56.23
UNXSIGNAL, Unexpected signal name in ACP

SDA> tr show trace
TR$DEBUG not loaded...
SDA> exam tr$gq_debug
TR$GQ_DEBUG: 00000000.00000000 "........"
SDA>

Any ideas?

Dave
Robert Brooks_1
Honored Contributor

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

Hmmm . . . I'm a bit surprised; did you get this message when you loaded it?

%SYSMAN-I-IMGADDED, added image TR$DEBUG for product TR$DEBUG
David B Sneddon
Honored Contributor

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

Yes. I got the IMGADDED message

Dave