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

[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.

[David B Sneddon]

Volker,

From memory, the data structure prior to the FCB was
an ORB for GYA0.
I tried loading WSDRIVER earlier in the boot (by doing
it manually in SYCONFIG) maybe in the hope that it would
corrupt something else and cause a crash at a different
point, but it didn't make a difference.
I will set NPAG_RING_SIZE as requested.

I can't check the ZIP file on a Windoze box because
I happen to exist in a Windoze free zone :-)

Dave

[Jan van den Ende]

Dave,


I can't check the ZIP file on a Windoze box because
I happen to exist in a Windoze free zone :-)


WOOOOOW!!

Aren't you one happy camper!!!

Do you have _ANY_ idea what kind if misery you are now deprived of? :-)

Proost.

Have one on me.

jpe

[David B Sneddon]

Jan,

I know EXACTLY what I am missing out on...
and guess what? I don't miss it a bit :-)

I don't have any Duvel at the moment but shall
have a Chimay instead.

Dave

[David B Sneddon]

Attached is OUTPUT.ZIP containing
shadowing.txt for Rob
poolring.txt for Volker

Let me know if you want anything else...

Dave

[Volker Halle]

Dave,

I've tried a little standalone program to simulate possible failures of clearing bit 4 in WCB$L_WLFL (before deallocation) - didn't work out. It never showed the symptoms as seen in the crash.

But if I clear bit 4 in FCB$L_WLFL before inserting the new WCB, I get the same results as in your crash:

FCB$L_EXFCB -> WCB
FCB$L_WLFL -> WCB
FCB$L_WLBL -> FCB$L_WLFL

WCB$L_WLFL -> FCB$L_EXFCB-4
WCB$L_WLBL -> FCB$L_WLFL

So the 'previous' allocation history of the packet preceeding the FCB in pool might be interesting. The FCB is in the XQP FCB cache, so it would have been there LONG before DECwindows startup.

Also, to find this problem (once WPDRIVER works again) would require to set a watchpoint on FCB$L_WLFL (maybe in addition to FCB$L_EXFCB). It will still be hard to find this problem...

Could you please let me know the FCB address from your last crash (Primary_FCB from CLUE XQP/THREAD), so I can look for allocations/deallocations of packets preceeding that FCB ?

Volker.

[David B Sneddon]

Volker,

FCB is 8213E380
WCB is 8228AE80

Dave

[Volker Halle]

Dave,

no luck. Your pool ring buffer captured data from the last 3.5 seconds and no packet near the FCB has been allocated/dealloacted during that time frame.

No further hope, until WPDRIVER is fixed...

Volker.

[Robert Brooks_1]

Thanks for posting the tracing.

I don't see anything particularly interesting from a shadowing standpoint (nor did I expect to, since the bugcheck was not generated by the shadowing driver). You've got at least 1, and perhaps more, merges going on (which I guess is to be expected, since you've had a crash or two). Other than that, the tracings do not show any unexpected code paths being taken, although I must admit I didn't pour over the 500+ pages of output.

Sorry :-(

-- Rob

[David B Sneddon]

Volker, Rob,

Thanks anyway... I guess I will have to wait to
what happens with Watchpoint or until someone with
a system on support gets the problem.

Dave

[David B Sneddon]

Ok, the saga continues...

Since I have the problem using a Powerstorm 3D30
but not with an S3 Trio, I thought a different
graphics card may do the trick. I managed to get a
Powerstorm 4D20 and tried that. Much better graphics
but unfortunately the problem persists.
I guess that was to be expected since the 3D30 and
4D20 use the same driver whereas the S3 Trio uses a
different driver.
Oh well, at least I have better graphics.

Dave

[David B Sneddon]

OK, here we are, one year on...
I have just installed V8.3 and decided to try
the volume shadowing stuff again (on the off
chance) and it is still broken.

Since I have just upgraded, I decided to backup
the V8.3 system and managed to BUGCHECK doing
a control-T during the backup -- what is going
on?

Dave

[Volker Halle]

Dave,

OpenVMS problems, which don't get to the attention of OpenVMS engineering and don't get reproduced and solved at that level, are quite unlikely to disappear, if you just wait long enough ;-)

This sounds like a specific configuration-related problem on your system. If it is really related to the combination of graphics card and shadowing, how many workstation-type systems are using shadowing on their system disk ?

All the previous troubleshooting tips still apply. What's the state of WPDRIVER in V8.3 ?

What kind of bugcheck did you get typing CTRL-T during backup ? As you know, I prefer to see the full CLUE file or at least the SDA> CLUE CRASH output and - ultimately - the SYSDUMP.DMP file itself.

Volker.

PS: You probably saw my new signature in comp.os.vms ;-)

[David B Sneddon]

Hi Volker,

I don't know the state of WPDRIVER and at
the moment I am not really interested (I am
starting to get a little concerned about
the state of VMS lately).

The control-T bugcheck was an INVEXCEPTN
during the dismount when backup is playing
with the tape label. I may post the CLUE
output later when the system is back up
and I have a backup of it and I am feeling
a bit more interested...

Dave

[Volker Halle]

Dave,


The control-T bugcheck was an INVEXCEPTN
during the dismount when backup is playing
with the tape label.


What would backup have to do with the tape label during dismount the tape ?

I'm running V8.3 on a Personal Alpha (emulator), if you could provide the steps for reproducing this, I would be glad to try.

Volker.

[David B Sneddon]

Volker,

Backup mounts the tape to check/change the tape
label, then dismounts and remounts it for use
(I believe).

Just start a backup to tape then keep doing
control-t

Dave

[Volker Halle]

Dave,

I don't see this:

CHAALP $ backu/ima sys$sysdevice: $3$mua1:t123.bck/save/rew/ign=label
CHAALP::SYSTEM 13:07:15 BACKUP CPU=00:00:47.21 PF=4028 IO=27170 MEM=256
%BACKUP-I-LBLOVRWRITE, volume label TEST overwritten, new label is T123


%MOUNT-I-MOUNTED, T123 mounted on _$3$MUA1: (CHARON)
CHAALP::SYSTEM 13:07:16 BACKUP CPU=00:00:47.60 PF=4121 IO=27224 MEM=403
Input file scan inactive.
Output: Saveset volume: 1, saveset block 0 (8192 byte blocks)
0KB saved, save rate: 0KB/sec
CHAALP::SYSTEM 13:07:16 BACKUP CPU=00:00:48.05 PF=4132 IO=27366 MEM=421
Input file scan inactive.
Output: Saveset volume: 1, saveset block 2 (8192 byte blocks)
16KB saved, save rate: 32KB/sec
...

Do you think this requires a shadowed system disk ?!

Volker.

[David B Sneddon]

Volker,

Once you start the backup, just keep doing the
control-t (repeatedly), you will get the label
overwritten message but you will not get to
the mounted message -- I have done it twice
and don't really want to do it again just yet.

Dave

[David B Sneddon]

Forgot, shadowing is not an issue, the system
disk is not shadowed, that combination is
still broken.

Dave

[Volker Halle]

Dave,

I've been doing just that. Pressing CTRL-T will not cause an echo, if MOUNTSHR code is active.

Please note that you have the VMS83A_ADDENDUM-V0100 patch installed, I haven't ! And your IO_ROUTINES, where the crash happens, is from that patch.

Reference information (also see comp.os.vms):

INVEXCEPTN - ACCVIO at IOC$DISMOUNT_C+00374
IOC$DISMOUNT_C+00374: LDQ_U R23,#X0018(R0)

R0=0000003A failing VA=00000052

Using IO_ROUTINES linked 8-AUG-2006 from VMS83A-ADDENDUM-V0100

and the offset to this instruction has changed against the V8.3 SSB version of IO_ROUTINES.

Volker.

[David B Sneddon]

Closing this off again -- details on the
newest bug are in a new thread

Dave