Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (System Mangler)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Help on deciphering crash
Message-ID: <1419@cit-vax.Caltech.Edu>
Date: Sat, 3-Jan-87 23:43:41 EST
Article-I.D.: cit-vax.1419
Posted: Sat Jan  3 23:43:41 1987
Date-Received: Sun, 4-Jan-87 03:45:39 EST
References: <3645@sdcrdcf.UUCP> <4891@mimsy.UUCP>
Organization: California Institute of Technology
Lines: 19
Summary: smokescreen
Xref: mnetor comp.unix.questions:515 comp.unix.wizards:488

In article <3645@sdcrdcf.UUCP> davem@sdcrdcf.UUCP (David Melman) writes:
> Our Vax 750 running 4.2BSD has occassionally been crashing with:
> machine check 2: cp tbuf par fault
>	va 80039728 errpc 8000394e mdr a smr 8 rdtimo 0 tbgpar 0 cacherr 5
>	busserr 6 mcesr 9 pc 8000394e ps1 40c0008 mcsr 80016

In article <4891@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> There are two interrelated fixes for this.  Both are already in
> 4.3BSD.  The first is that some tbuf parity errors can be corrected [...]

Read the registers.  This is a cache parity error, not a tbuf parity
error.	Never mind that 4.[23] doesn't distinguish between the two.

We get these all the time.  There are two ways to "fix" it:  swap
L0003 boards until you get a good one ($$$), or change the machine
check handler to flush the cache and return.  Now, can anyone tell
me how to flush the cache?

Don Speck   speck@vlsi.caltech.edu  {seismo,rutgers,ames}!cit-vax!speck