Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 Apollo 5/13/85; site apollo.uucp
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!think!mit-eddie!genrad!decvax!wanginst!apollo!rees
From: rees@apollo.uucp (Jim Rees)
Newsgroups: net.bugs.4bsd
Subject: Re: mchk 2 --- tbuf error on 750 running 4.2 BSD
Message-ID: <2807aab5.1de6@apollo.uucp>
Date: Tue, 30-Jul-85 11:47:25 EDT
Article-I.D.: apollo.2807aab5.1de6
Posted: Tue Jul 30 11:47:25 1985
Date-Received: Thu, 1-Aug-85 07:28:53 EDT
References: <83@zeta.UUCP> <654@gatech.CSNET>
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 24

Actually, the bsd4.2 tape we got still didn't have the right stuff for
tbuf parity errors.  In machdep.c, the line

		if ((mcf->mc5_mcesr&0xf) == MC750_TBPAR) {

should be

		if ((mcf->mc5_mcesr&0xe) == MC750_TBPAR) {

The low order bit indicates whether the error occured in the execution
buffer or not.  Since we don't care where the error occured, we just
mask out that bit.  See the section on "Machine Check Error Summary
Register" in the Vax Hardware Handbook.

Some other early fixes caught the tbuf par error fine, but then failed
to flush the buffer before returning, resulting in an endless loop.

The 4.1 code was even worse.  As I recall, hard errors were mistakenly
reported as tbuf parity errors, and soft errors were ignored, but I
could have that the wrong way around.  As far as I know all versions
of 4.2 fix this problem.

I have all this on good authority, but if I'm wrong about the TB flush
also flushing the XB, please set me straight.