Crash VAx 7640

[vmsserbo]

Our Vax system crashed lastnight. This is what I got from the Crash dump?

OpenVMS (TM) VAX System dump analyzer

Dump taken on 30-NOV-2006 00:03:12.57
ASYNCWRTER, Asynchronous write memory failure

Is this a hardware issue?


Here is more info about the crash see attachment

[Richard Brodie_1]

"Is this a hardware issue?"

That would be my first guess, so I'd be heading for the error log as the first step.

[vmsserbo]

Here is the errorlog I produced in an attachment . Can someone look at this and see what happend?

Thanks!

[Hein van den Heuvel]

Miles,

Looks like the same issue you reported almost exactly a year ago:

https://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=977153

Please re-read the replies there.

This is likely a hardware issue, but there are also software issues which have caused this in the passed: ECO VAXPHV01_070 addresses one.

If you google for ASYNCWRTER, you'll find the consensus is hardware. The INT60 entries in the error log around the crash time seem to confirm this.

hth,
Hein.

[John Travell]

Definitely hardware. CPU02 (in LSB slot 2), suffered a TAG CONTROL RAM PARITY ERROR.
Whenever an event causes a trap through SCB vector 60, the VAX7000 family always log one entry for each processor. Since you have 4 cpu's, you get 4 entries.
To identify which is which, look for the GB WHAMI register.
* ENTRY 3756. *
GB WHAMI 00E2
LSB Node ID = 02(X)
* ENTRY 3757. *
GB WHAMI 00E0
LSB Node ID = 00(X)
* ENTRY 3758. *
GB WHAMI 00E1
LSB Node ID = 01(X)
* ENTRY 3759. *
GB WHAMI 00E3
LSB Node ID = 03(X)

AS you can see, all CPU's reported in.
The ONLY entry to contain anything untoward is the first, * ENTRY 3756. *
where the relevant entries are:
LMERR 00000020
B-STAT PARITY ERROR
BIU STAT C00E3038
TAG CONTROL RAM PARITY ERROR
write_unlock
Bits 33,32 BIU Addr Reg = 00(X)
Bits 33,32 Fill Addr Reg = 03(X)


You have a number of choices, and which you take depends on whether this machine is on contract or not.
If it *IS* on a maintenance contract, have your maintainer replace the CPU.
If it is *NOT* on any contract...
1. Accept the occasional crash as inevitable.
2. Remove the CPU in LSB slot 2, then either
2a. Leave the machine running a reduced number of CPU's.
2b. Locate a replacement CPU and fit it in place of the one you removed.
I am going from memory, but I do not think that it is possible to disable the TAG control RAM on this (or any other?) VAX and still use the CPU.
JT:

[Stanley F Quayle]

You could replace the system with CHARON-VAX:

http://www.stanq.com/charon-vax.html

[Shameless Plug (tm) from your CHARON-VAX reseller] That would get you to modern hardware...