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

[Robert Brooks_1]

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]

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]

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]

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]

Yes. I got the IMGADDED message

Dave

[David B Sneddon]

Rob,

Someone forgot the @sys$update:vms$system_images...
I will try again tonight.

Dave

[David B Sneddon]

Rob,

Attached is shadowing.txt as requested
What else can be traced via TR$DEBUG?

Dave

[Robert Brooks_1]

Hi David,

Aha! To gather tracing information on a shadowed system disk, you also have to boot with SYSTEM_CHECK = 1. There was some stuff in the file you attached; it was from the SHADOW_SERVER process, but didn't really
have anything interesting. The file that was zipped was difficult for me to read; the line breaks were largely non-existent

I suspect that very little else can be traced
via SDA> TR SHOW TRACE. It's up to the folks
who maintain each component to decided what (if any) latent tracing stuff is left in the version that ships to the world; the primary
shadowing maintainer is a heavy user of the tracing facility, and decided that it could be useful in trying to debug real tough problems.

.

-- Rob

[David B Sneddon]

Rob,

I shall try again tonight with SYSTEM_CHECK=1
(plus the other settings...)
How/where did you unzip the attachement?
It was zipped on VMS. I am unable to attach any
text files via this interface. You should be able
to "unzip -aa" to get something usable. I did test
the file after it was attached.

Dave

[Volker Halle]

Dave,

if you produce another crash with SYSTEM_CHECK = 1, could you also please increase the nonpaged pool ring buffer by setting NPAG_RING_SIZE = 20000

I would like to see the previous uses of the WCB pointed to by FCB$L_EXFCB and maybe also the useage of the packet preceeding that one in nonpaged pool.

From your previous experiments, we suspected some DECwindows components (WSDRIVER ?) to maybe cause pool corruption, as they were being loaded immediately preceeding the crash...

I copied your ZIP file to my VMS machine and just used UNZIP - the resulting file looked fine on OpenVMS. Opening the attached ZIP file with Windows caused the same problem as seen by Rob (no cr/lf in text).

Volker.