kern/51982: sio1: interrupt-level buffer overflows

Bruce Evans bde at zeta.org.au
Thu May 8 17:00:24 PDT 2003


The following reply was made to PR kern/51982; it has been noted by GNATS.

From: Bruce Evans <bde at zeta.org.au>
To: Ian Freislich <ianf at za.uu.net>
Cc: FreeBSD-gnats-submit at freebsd.org, freebsd-bugs at freebsd.org
Subject: Re: kern/51982: sio1: interrupt-level buffer overflows
Date: Fri, 9 May 2003 09:56:39 +1000 (EST)

 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


More information about the freebsd-bugs mailing list