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