Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!rutgers!clyde!watmath!watnot!watcgl!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Help on deciphering crash
Message-ID: <15174@onfcanim.UUCP>
Date: Mon, 5-Jan-87 10:50:06 EST
Article-I.D.: onfcanim.15174
Posted: Mon Jan  5 10:50:06 1987
Date-Received: Tue, 6-Jan-87 02:44:42 EST
References: <3645@sdcrdcf.UUCP> <4891@mimsy.UUCP> <1419@cit-vax.Caltech.Edu>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 22
Xref: mnetor comp.unix.questions:536 comp.unix.wizards:508

In article <1419@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (System Mangler) writes:
>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?

At Waterloo, someone added code to set the "force cache miss" bits,
then access the address that got the parity fault; the idea being that
this might cause the bad cache entry to be cleared.  Without any way
to generate cache errors on demand it's hard to check whether the code
really works as designed.  However, it's been running on perhaps a
dozen machines for a year or two, so it is at least benign.
The code looks like this; it's for a 780 so the magic bits may be
somewhere else on a 750:


			/* Force Cache Miss and Replace */
			mtpr(SBIMT, mfpr(SBIMT) | 0x1e000);
			i = *(int *)mcf->mc8_vaviba;	/* Access address */

			/* Return to normal */
			mtpr(SBIMT, mfpr(SBIMT) & ~0x1e000);