On Fri, 24 May 1996, Jukka Marin wrote:

> > At 57600, we're talking about 1400us to respond before characters are
> > lost.  Whats blocking for that long?  TTY is > then NET and BIO, right?
> 
> That's a long time, especially on a fast pentium CPU.  All I can tell is
> that on my system, the wd interface doesn't seem to make the things
> noticeably worse, but the ep (3com509) driver seemed to cause more data
> loss.  The real problem may be somewhere else, though, because I got
> FIFO overruns even when everything were supposed to be idle.

I thought I'd just share some of the problems the mac68k port has gone
through. We don't use the com driver (no isa at present), but we used to
have a LOT of problems with overruns. Our chip has a 3 byte internal
buffer, and we use a silo (we have a quick-and-dirty interrupt handler,
then a lower-priority tty servicer). We used to have overruns on lines
which were sending bytes once every other second; 0.5 bytes/second! Thus
somehow we were blocking tty interrupts for over 6 seconds!

Our problem was that spltty, which was supposed to block the
silo-to-kernel transfer, was disabling the hardware servicing interrupt
(the hardware-to-silo connection). Making spltty a soft interrupt (or a
much-lower-level hardware interrupt) made everything work well.

I don't know much about the com driver, though I think someone mentioned
that it isn't two-level. My feeling from reading the 4.3 book was that if
you had low-buffer I/O hardware, use a two-level driver w/ a silo.
Obviously, this change couldn't make 1.2, but maybe for the future? I'd
offer to help, but I suspect the folks who know the com driver already
understand silos. :-)

Take care,

Bill