From owner-freebsd-current  Sun Jun 18 02:49:12 1995
Return-Path: current-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id CAA08749
          for current-outgoing; Sun, 18 Jun 1995 02:49:12 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA08743
          for <current@freebsd.org>; Sun, 18 Jun 1995 02:49:06 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA22668; Sun, 18 Jun 1995 19:46:25 +1000
Date: Sun, 18 Jun 1995 19:46:25 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199506180946.TAA22668@godzilla.zeta.org.au>
To: hsu@clinet.fi
Subject: Re: kern/528: interrupt-level buffer overflows
Cc: current@freebsd.org
Sender: current-owner@freebsd.org
Precedence: bulk

>	Kernel spits out lot of these

>Jun 18 05:14:47 pommi /kernel: sio1: 119 more interrupt-level buffer over
>flows (total 3642)
>Jun 18 05:14:47 pommi /kernel: sio1: 119 more interrupt-level buffer overflows (
>total 3642)

For this to happen, softclock() must sometimes be delayed for a long time
several clock ticks (about 3 clock ticks for 119 characters at 38400 bps
and about (256 - 38) / 38 clock ticks for filling up the 256 character
buffer before that.

>	It also very easily reboots when lots of PPP load exits. 

I don't know what causes that.

>	Low tcp performance hints that it is loosing lots of data.

All the data reported in the buffer overflow messages is lost.

>>Fix:
>	
>	I think this feature has already been discussed; grepping
>	'interrupt-level' from FAQ's didn't help.  If this is a feature
>	which can be worked around, this might be a doc-bug?  However, I

Use hardware handshaking.

>	find it curous how a 386-16 could be too slow to respond for a 38400
>	bps link? 

I've heard that some systems 20 times as fast as a 386/16 are too slow for
a 38400 bps link.

Bruce