Charles Lepple writes:
   > What is the current status of the code for the 53c810? I keep seeing
   > references to how it is buggy, and that it occasionally doesn't work.
   > 
   > Essentially, I am trying to get an estimate of the percentage of uptime
   > I would have with a UDB with said SCSI adapter :-)
   
   The driver's reliability is bimodal. On a machine/disk combo on which
   it works, it is nearly 100% reliable. On a machine/disk combo on which
   it does not work, it will fail to work for more than a few seconds to
   few minutes. You will not operate the thing for several weeks only to
   have a failure -- you'll know very fast if you have trouble.
   
   Perry

Hmm, that has not precisely been my experience with the NCR driver, although
it did seem to mostly work on the UDB box.  On newer boxes, it exhibited
the behavior of working until asked to do something like a large tranfer,
say tar/untar of the sources or toolchain sources, and then it would fail,
in a way that indicates it has little or no error recovery code.  Typically
the driver would log that it had received a scsi error, then start timing
out and logging the timeouts, then hang forever instead of trying to
restart the controller and continue, requiring a reboot.  We did not see
that behavior at all on the 20164/66 boxes, but did see it on 21164 eb164s
and pc164s.

There was some loose talk here about giving this driver some priority because
of its support in SRM and being built-in to eb164 systems... is there actually
anyone doing development?  If not, is there anyone who can give pointers to
documentation on how to correct NCR scripts?  I've recently heard of a new
failure mode with Intraserver controllers and the pc164 that keeps the machine
from boostrapping once the kernel device driver has control, with latest
versions of pc164s and Seagate drives, so I have some interest in looking at
same.