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);