Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!gatech!uflorida!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.unix.ultrix
Subject: Re: 8800 crashing way too often
Message-ID: <27482@mimsy.umd.edu>
Date: 6 Nov 90 21:06:12 GMT
References: <1990Nov6.185546.26468@portia.Stanford.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 24

In article <1990Nov6.185546.26468@portia.Stanford.EDU>
dennis@portia.Stanford.EDU (Dennis Michael) writes:
>ULTRIX Engineering: "The panics occuring at Stanford appear to be caused
>by a flink (forward link) of a request packet getting corrupted while
>the request packet sits on the active queue ...
>
>Anyone seen this before?

Not that particular problem, but the MSCP driver I wrote, distributed
with 4.3BSD-tahoe and 4.3BSD-reno, has two special features that can
be compiled in.  One is designed specifically for a bug in the Emulex
SC41/MS Unibus MSCP controller, in which command reference numbers
occasionally have their low word replaced with zero (this bug is fixed
in revision F of the SC41/MS ROMs).  The other is more generic; it
is called `MSCP_PARANOIA', and it checks the command reference number
in every response packet to make sure that it matches an outstanding
I/O request.  If not, the board is reset.

This is all for returned packets, not outgoing requests.  Since requests
live in main memory, and are never supposed to be modified by the device,
I was not paranoid enough to add checks there.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris