From owner-freebsd-bugs@FreeBSD.ORG  Thu May  8 17:04:52 2003
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
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 6669637B401; Thu,  8 May 2003 17:04:52 -0700 (PDT)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id EA3FD43F93; Thu,  8 May 2003 17:04:50 -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 KAA29817;
	Fri, 9 May 2003 10:04:43 +1000
Date: Fri, 9 May 2003 10:04:41 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Ian Freislich <ianf@za.uu.net>
In-Reply-To: <20030509092253.Y61808@gamplex.bde.org>
Message-ID: <20030509095729.F61896@gamplex.bde.org>
References: <E19CgpH-0001JQ-00@brane-dead.digs.iafrica.com>
 <20030509092253.Y61808@gamplex.bde.org>
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 <freebsd-bugs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-bugs>
List-Post: <mailto:freebsd-bugs@freebsd.org>
List-Help: <mailto:freebsd-bugs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-bugs>,
	<mailto:freebsd-bugs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 09 May 2003 00:04:52 -0000

On Fri, 9 May 2003, Bruce Evans wrote:

> ...
> 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.

PS: you should also try to find what is holding Giant for more than 40
msec.  Most syscalls hold it from near their start to near their
completion, but most syscalls don't take nearly that long.  It is
easy to write broken ones that do - just spin for a long time, or
return a huge amount of data via sysctl.

Bruce