From hsu@clinet.fi  Sun Jul  2 02:00:43 1995
Received: from clinet.fi (root@clinet.fi [193.64.6.1])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id CAA22164
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 2 Jul 1995 02:00:41 -0700
Received: from katiska.clinet.fi (root@katiska.clinet.fi [193.64.6.3]) by clinet.fi (8.6.10/8.6.4) with ESMTP id MAA07802 for <FreeBSD-gnats-submit@freebsd.org>; Sun, 2 Jul 1995 12:00:37 +0300
Received: (root@localhost) by katiska.clinet.fi (8.6.11/8.6.4) id MAA01179; Sun, 2 Jul 1995 12:00:36 +0300
Message-Id: <199507020900.MAA01179@katiska.clinet.fi>
Date: Sun, 2 Jul 1995 12:00:36 +0300
From: Heikki Suonsivu <hsu@clinet.fi>
Reply-To: hsu@clinet.fi
To: FreeBSD-gnats-submit@freebsd.org
Subject: sio: RS_IBUFSIZE 256 too small
X-Send-Pr-Version: 3.2

>Number:         579
>Category:       kern
>Synopsis:       sio: RS_IBUFSIZE at 256 bytes serial lines loose data (PPP)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    grog
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jul  2 02:10:00 1995
>Closed-Date:    Mon Jul 19 23:16:11 PDT 1999
>Last-Modified:  Mon Jul 19 23:20:08 PDT 1999
>Originator:     Heikki Suonsivu
>Release:        FreeBSD 2.0-BUILT-19950507 i386
>Organization:
Clinet, Espoo, Finland
>Environment:

	A 486-40 with 6 16550 ports and 4 ethernets (3 active)
	A 386-16 with 1 16550 ports and 1 ethernet (just a PPP router)

>Description:

	Both these machines report "interrupt-level buffer overflow":s 
	very frequently on a leased line running at 38400, badly dropping
	IP performance. 

	On 386-16 I also saw several spontaneous reboots when loading the 
	PPP link.

>How-To-Repeat:

	It seems that this bites only me, even though it does this on two 
	quite different configurations.  In addition the 486 machine has
	115.2k leased line connected with no apparent trouble.
	Thus I can't really tell you how to repeat this (other than sending
	the machines there :-).

>Fix:
	
	I changed RS_IBUFSIZE from 256 to 4096, and the problem disappeared. 
	It might be that a smaller amount would be sufficient (I don't mind
	8k memory waste per line in this case).  But it is apparent that
	256 bytes seems not sufficient for slow or loaded machines. 

sio.c:
< #define      RS_IBUFSIZE     256
--
> #define      RS_IBUFSIZE     4096


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->bde 
Responsible-Changed-By: pst 
Responsible-Changed-When: Thu Feb 8 12:25:01 PST 1996 
Responsible-Changed-Why:  
This report still appears valid. 
State-Changed-From-To: open->feedback 
State-Changed-By: grog 
State-Changed-When: Fri Jul 9 01:45:18 PDT 1999 
State-Changed-Why:  
Awaiting feedback from submitter 
State-Changed-From-To: feedback->closed 
State-Changed-By: grog 
State-Changed-When: Mon Jul 19 23:16:11 PDT 1999 
State-Changed-Why:  
PR rotted away, no response from submitter 


Responsible-Changed-From-To: bde->grog 
Responsible-Changed-By: grog 
Responsible-Changed-When: Mon Jul 19 23:16:11 PDT 1999 
Responsible-Changed-Why:  
grog closed this PR 
>Unformatted:

Greg Lehey, 9 July 1999

	Are you still having these problems?  It seems that our sio
	implementation has changed to the point where we don't even
	have the variable RS_IBUFSIZE any more, so I'd suggest that we
	close this PR and enter a new one if you still have the
	problems (or the machines, for that matter).  If I don't hear
	from you in a week, I'll close the PR anyway.

Greg Lehey, 20 July 1999

	I have had no reply from the submitter.  bde, to whom this PR
	had been assigned, makes the following comment:

	  It is only "completely" (*) fixed in -current.  This is not
	  easy to check because history of sio.c has been scrambled
	  (there aren't even any old_RELENG_3* tags, since RELENG_3
	  has an alpha version).

	  (*) A complete fix would involve implementing hard real time
	  capabilities (and ignoring 90% of h/w on the submitter's
	  system so that the constraints can be met :-).

	This is not likely to still be a problem, so I am closing this
	PR.
