VMS83A_ADDENDUM V1.0 patch is broken

[David B Sneddon]

I just upgraded an Alpha to V8.3 and also
installed the above mentioned patch (thinking
I was doing the right thing) then whilst
trying to backup my newly upgraded system, I
get an INVEXCEPTN bugcheck... output from
CLUE CRASH will be attached when the system
regains some semblence of stability.

It would appear that the IO_ROUTINES supplied
with this kit are broken.

Dave

[David B Sneddon]

Here is the CLUE CRASH output...

[Volker Halle]

Dave,

could you remove the patch with PRODUCT UNDO PATCH and re-try the BACKUP and CTRL-T again ? This would actually confirm, that the problem is in that patch.

I tried a BACKUP and CTRL-T to (an emulated) tape with OpenVMS Alpha V8.3 SSB and could not reproduce this crash.

Volker.

[David B Sneddon]

Volker,

I have removed the patch and the backup is currently running. I do not want to do a
control-t at this point... I did a backup
with the patch installed, no control-t and
it crashed at the same point as before,
pointing to the problem being in the patch.

Dave

[Volker Halle]

cross-reference:

also being discussed in comp.os.vms titled Alpha/V8.3/Backup/Control-T/BUGCHECK

CTRL-T not needed to produce this crash...

Volker.

[Volker Halle]

Dave,

BACKUP is out of the picture, as well as CTRL-T !

A plain MOUNT/FOR tape and a DISM/NOUNL tape is sufficient to cause this crash...

Volker.

[Volker Halle · Accepted solution]

Dave,

some code at the beginning of a local subroutine in IOC$DISMOUNT loads the UCB fork lock index into R0 - thereby overwriting the VCB address stored in R0. This seems to be new code added in VMS83A_ADDENDUM-V0100.

The instruction, which causes the ACCVIO and the crash, assumes that R0 is still pointing to the VCB (volume control block).

Volker.

[Robert Brooks_1]

I'll have a fix for this one some time Monday morning. Please log a call with your local support centre to get a new IO_ROUTINES image

-- Rob

[Karl Rohwedder]

I also noticed that I am no longer able to open a RDB database after installing this patch (get a nopriv error whilest RDB is trying to map a section), logged a call with Oracle (note: that I am running a fieldtest RDB version).

regards Kalle

[Ian Miller.]

I have just recived an advisory that the VMS83A_ADDENDUM-V0100 patch kit for OpenVMS Alpha V8.3 and the VMS83I_ADDENDUM-V0100 patch kit for HP Integrity Servers running OpenVMS
V8.3 are being placed on hold.

[Robert Brooks_1]

For what it's worth, it appears as though this is only a system crasher on a single-CPU system.

On an SMP system, the failure to preserve R0 across the invocation of the FORKLOCK macro means that R0 will contain a pointer to the relevant spinlock structure, meaning that the later code will mistakenly clear a bit in the spinlock structure (in the cell spl$q_release_count).

In any event, the wheels are now turning in an effort to get the corrected ADDENDUM kit out for V8.3. Fortunately, that change (which was backported to V7.3-2 and up) had not made it out to the field in any other SYS kit yet.


-- Rob

[John Gillings]

Dave,
Thanks for the note. Hold notice advisory is attached.

[David B Sneddon]

Where do I send the bill for doing the
QA on your patch kits?

Dave

[Volker Halle]

Dave,


Where do I send the bill for doing the
QA on your patch kits?


When sending the bill, could you please add another couple of EURO cents for my analysis down to the failing machine code instruction sequence ;-)

Volker.

[David B Sneddon]

Volker,

You are worth a LOT more than a couple of
Euro cents...

I am just a wee bit disappointed that a bug
like this could make it out -- am I the only
one who actually installed the patch?

What would have happened if the backport to
7.3-2 had got out?

Dave

[Jan van den Ende]

Dave


What would have happened if the backport to
7.3-2 had got out?


_WE_ would have lost one node (the only single processor) of our cluster; and probably started heavy escalation right after showing it to be reproducible.
As luck might have it, that node would, or would not, have been the first to reboot with the patch; with widely varying aftermaths.
Another possibility: we might well have had a patch opportunity on our development node first. That is also a single-processor... At this time, it is for some months allocated to a prestige project, and I would just LOVE to be accused of sabotaging that project :-(

It would _NOT_ have been appreciated, so, we owe you great thanks!

Proost.

Have one on me.

jpe

[David B Sneddon]

The issue is apparently under control...