Date: Thu, 8 May 2003 17:00:23 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/51982: sio1: interrupt-level buffer overflows Message-ID: <200305090000.h4900NC4063036@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/51982; it has been noted by GNATS. From: Bruce Evans <bde@zeta.org.au> To: Ian Freislich <ianf@za.uu.net> Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-bugs@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305090000.h4900NC4063036>