On Fri, Feb 20, 1998 at 02:05:34PM -0500, Perry E. Metzger wrote:
> 
> As I've noted, our NCR driver really, truly sucks. The right fix is
> for someone to rewrite it. No amount of kludging with it is going to
> fix the thing.
> 
> .pm
> 
> Cliff Romash writes:
> > After some further thinking and experimentation, I've come to the
> > conclusion that the problem that we are having here at GTE is caused by
> > using a serial console! A particular machine will reliably reboot with a
> > graphics console, but fail with a serial console.
> > 
> > The choice of disk drive also seems to affect this. Machines with Seagate
> > ST34501W exhibit the problem, while a machine with a ST32155W have not
> > seen the problem over several months.

Let's be a bit less iconoclastic here.  The driver is in the tree because it
works for most people most of the time.  I used it on a Multia for months,
and then I had several 825 cards in a pc164 with about 6 fast disks for another
half a year, as a fairly important production CVS server.

Many -- most? -- of the NetBSD developers who use the Alpha port have machines
with ncr cards in them.

The problems seem to mostly be with newer disks or disks which are very
aggressive about tagged queueing, AFAICT.  It's noteworthy that even the
ahc (AIC7XXX) driver, which many people are so fond of, totally loses with
some such disks -- I have a Quantum Atlas II which is basically useless with
the ahc unless I turn off tagged queueing in the driver.

And, once more: it's the *exact same* driver that's in FreeBSD.  The only
difference which seems noteworthy to me is that in FreeBSD, the driver makes
sure the command script is in physically contiguous RAM, but the last time
I looked there was no interface to do that under NetBSD.  I doubt that that
is the source of all the trouble we're hearing about.  I've certainly seen
enough users with trouble using the NCR under FreeBSD -- since this isn't the
FreeBSD mailing list, you're not going to see them here.

The driver *is* overly complex, has poor error-handling, is written in a way
which guarantees that if your machine has any kind of cache-coherency problem
you'll learn about it *fast* (but most modern machines with reasonably mature
PCI chipsets shouldn't suffer from this) and is written in a pretty poor style
in various other ways.

We have another NCR 53c[78xx] driver in the tree, actually.  As well as a nice
script assembler which would make writing a new, clean ncr driver fairly easy.
What should really happen, if anyone is looking for a project, is that the
existing 53c7XX driver should become bus-independent, learn about tagged
queueing and cards with different kinds of script storage (the newer 8xx chips
have a local script cache as well as the ability to get scripts from host
RAM), and get bus front-ends which would replace the existing PCI 53c8xx
attachment and the VME (is there another?) 53c7xx attachment.

That really wouldn't be so painful.  Most of the code is already done.

Thor