> From: "Graham, James" <James.Graham@Schwab.COM>
> Date: Tue, 29 Apr 1997 17:40:38 +0100

> [don't know if this got through originally,
>  please excuse me if this is duplicate data...]
> 
> The zs0a overruns don't happen nearly as frequently under a
> GENERIC  1.2.1 kernel as they do under a custom 1.2.1D kernel.
> 
> Also, at one point I was accessing the floopy drive and getting
> bad block errorson accesses while the zs0a overruns were happening.

The floppy driver interaction is a good hint.  Part of the problem
with the old zs driver (used by the sparc port) is that flow-control
events are handled at the "soft" interrupt priority, and the handler
that runs at "soft" priority has poor response (long latency).  This
may be exacerbated somewhat by the fact that the interrupt handler in
the floppy driver can stay a while in a loop at high priority...

We were having similar problems with the old zs driver on the sun3
and other ports, where flow control events would occasionally be
handled to late to prevent silo overflows.  It was impossible to
make the silos large enough to avoid any chance of overflows.

Therefore, we (Bill Studenmund, myself, others) undertook an effort
to redesign the flow-control event handling in the new zs driver.
The most important change from the old driver is that flow-control
"throttling" events are handled in the "high priority" interrupt
handler.  (The flow-control "unthrottle" events are still handled in
the "low priority" handler due to tty layer interactions.)

After the implementation of this design, is is basically impossible
to get silo overflows if you are using any H/W flow control mode.
(i.e. CRTSCTS)

It sounds like the sparc port might benefit from the new zs code.

Gordon