From owner-freebsd-bugs@FreeBSD.ORG Thu May 8 16:56:57 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F18DE37B401; Thu, 8 May 2003 16:56:56 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 574E243F85; Thu, 8 May 2003 16:56:55 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id JAA28461; Fri, 9 May 2003 09:56:41 +1000 Date: Fri, 9 May 2003 09:56:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Ian Freislich In-Reply-To: Message-ID: <20030509092253.Y61808@gamplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-bugs@freebsd.org cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: kern/51982: sio1: interrupt-level buffer overflows X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2003 23:56:57 -0000 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