kern/51982: sio1: interrupt-level buffer overflows

[Bruce Evans]

On Mon, 5 May 2003, Ian Freislich wrote:

> >Description:
> 	Transferring data at "high" speed 115200bps over the serial
> 	line (even though the actual incoming line stream is about
> 	37000bps according to the modem LCD panel) results in the
> 	following messages on the console at a rate of about 1 log
> 	line every 10 to 15 seconds.
>
> 	These buffer overruns have gradually become more frequent
> 	from about 3 lines and 24 overruns a day around September
> 	2002 (when I started running Current - 4.x does not suffer
> 	from this) to the current flurry.

-current has excessive interrupt latency caused by Giant locking almost
everything.

Try changing this line in sio.c:

	cp4ticks = speed / 10 / hz * 4;

to something like:

	cp4ticks = speed / 10 / hz * 40;

or if you use a non-default value for hz (default is 100):

	cp4ticks = speed / 10 / 100 * 40;

The original version provides enough buffering for about 4 hardclock
ticks (default 40 msec on i386's; much smaller on some other arches)
of input at full speed.  The third version provides 400 msec of
buffering.

Transient interrupt latency problems are supposed to be made harmless
by using rts flow control.  There is a PR (maybe from you?) about rts
flow control apparently not working for one modem.

The hz term was never quite right here.  It assumes that the specified
value of hz actually works to within 100% (interrupt latency no larger
than 2/hz seconds for the lowest priority interrupt handler in the
system).  The large interrupt latency of -current shows worst-case
latency even 2/100 seconds on a multi-GHz machine may be too much for
low priority interrupt handlers to ask for.  The relevant interrupt
handler (siopoll()) became a low priority interrupt handler when it
got locked by Giant.

Bruce