Subject: Re: fifo overrun errors...
To: Allen Briggs <briggs@puma.macbsd.com>
From: Monroe Williams <monroe@teleport.com>
List: port-mac68k
Date: 06/25/1996 16:16:56
Allen Briggs writes:
>*sigh*  This is the first I've heard of any problems other than
>Hauke's problem with the sbc driver being fixed by the spl change.
>Can you try compiling a kernel with just the splimp changed back 
>to spl2 and see if you still get the hangs?  I think there were
>a couple of other changes in the last few months.

Since the kernel was a couple of months old, I'm not sure the spl
change was really involved either.  I can try changing the spl and
making another kernel.  To avoid confusion: you would like to know if
the current ncrscsi driver with splimp() == spl2() still has the
hanging problem, correct?  (My current working kernel uses sbc and
splimp() == spl4().)

>Please mention problems or make use of send-pr to report bugs.
>The only open pr in the GNATS database with a category of port-mac
>is one about the system locking when nothings attached to the ADB.
>I know there are other problems, but I have to search back through
>mail archives to find them...

I've sent descriptions of this problem to the mailing list a couple of
times.  I think I remember someone else describing a similar problem
(hangs when accessing particular old/slow SCSI devices) on the lists,
too.  I was under the impression that work was in progress on the SCSI
drivers (at least the sbc driver), so I was waiting to see if those
changes fixed the SCSI problems I was having.  (My NetBSD system is
non-critical, so I can afford to wait.)  It appears that the
combination of the spl change and the sbc driver did fix the problem,
but at the expense of serial performance.  (I never tried just one or
the other.)  

In another response to my initial message in this thread, Scott
Reynolds indicated that he is aware of the SCSI/serial tradeoff and is
working on a fix that should make both work, at the expense of
processor cycles.  (Not that my poor old SE/30 has many to spare, but
if that's what it takes... ;)

-- monroe
------------------------------------------------------------------------
Monroe Williams                                      monroe@teleport.com