From nobody@FreeBSD.org  Sat Mar 31 19:05:08 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id C75B537B718
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 31 Mar 2001 19:05:08 -0800 (PST)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f31358B95983;
	Sat, 31 Mar 2001 19:05:08 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200104010305.f31358B95983@freefall.freebsd.org>
Date: Sat, 31 Mar 2001 19:05:08 -0800 (PST)
From: richw@webcom.com
To: freebsd-gnats-submit@FreeBSD.org
Subject: silo overflow problem in sio driver
X-Send-Pr-Version: www-1.0

>Number:         26261
>Category:       kern
>Synopsis:       [sio] silo overflow problem in sio driver
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 31 19:10:01 PST 2001
>Closed-Date:    
>Last-Modified:  Wed Sep 14 07:03:51 GMT 2005
>Originator:     Rich Wales
>Release:        4.2-RELEASE
>Organization:
>Environment:
FreeBSD jekyll.richw.org 4.2-RELEASE FreeBSD 4.2-RELEASE #8: Sat Mar  3 21:17:31 PST 2001     richw@jekyll.richw.org:/big/4.2/usr/src/sys/compile/JEKYLL  i386
>Description:
I'm getting lots of "silo overflow" errors on an internal serial port
in my 800-MHz Athlon system.

I tried patching isa/sio.c to set a lower receive FIFO threshold, but
even with a threshold of FIFO_RX_MEDL, I still get silo overflows unless
I reduce the serial port speed to 19200 or slower.

The serial port works flawlessly if I run Win98 and Hyperterm -- so I
assume the problem is in FreeBSD and not in my hardware.
>How-To-Repeat:
Sustained high-speed serial input at 38400 or above.
>Fix:
No fix known.  Reducing port speed to 19200 or slower is a workaround,
but not a very satisfying one.
>Release-Note:
>Audit-Trail:

From: WATANABE Kiyoshi <aab10490@pop16.odn.ne.jp>
To: freebsd-gnats-submit@FreeBSD.org, richw@webcom.com
Cc:  
Subject: Re: i386/26261: silo overflow problem in sio driver
Date: Wed, 04 Apr 2001 00:12:32 +0900

 try this patch.
 
 --- /usr/src/sys/isa/sio.c.orig	Tue Oct 10 19:08:12 2000
 +++ /usr/src/sys/isa/sio.c	Wed Apr  4 00:08:54 2001
 @@ -2480,6 +2480,7 @@
          * but a bit less for CS5-CS7 modes).
          */
         cp4ticks = speed / 10 / hz * 4;
 +       cp4ticks *= 10;                     /* to avoid buffer overflow */
         for (ibufsize = 128; ibufsize < cp4ticks;)
                 ibufsize <<= 1;
         if (ibufsize == com->ibufsize) {
 
 

From: Rich Wales <richw@webcom.com>
To: WATANABE Kiyoshi <aab10490@pop16.odn.ne.jp>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: i386/26261: silo overflow problem in sio driver
Date: Tue, 3 Apr 2001 22:02:41 -0700 (PDT)

 WATANABE Kiyoshi wrote:
 
     > try this patch.
     > +      cp4ticks *= 10;   /* to avoid buffer overflow */
 
 Thanks.  This helped to some extent, though I'm still seeing some
 silo overflows even with the above patch.  Should the "10" be bumped
 up to something larger, perhaps?
 
 Rich Wales         richw@webcom.com         http://www.webcom.com/richw/
 

From: Bruce Evans <bde@zeta.org.au>
To: Rich Wales <richw@webcom.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: i386/26261: silo overflow problem in sio driver
Date: Wed, 4 Apr 2001 21:02:24 +1000 (EST)

 On Tue, 3 Apr 2001, Rich Wales wrote:
 
 >  WATANABE Kiyoshi wrote:
 >  
 >      > try this patch.
 >      > +      cp4ticks *= 10;   /* to avoid buffer overflow */
 >  
 >  Thanks.  This helped to some extent, though I'm still seeing some
 >  silo overflows even with the above patch.  Should the "10" be bumped
 >  up to something larger, perhaps?
 
 This can't possibly help reduce silo overflows, since it increases the
 size a driver buffer, but silo overflows occur when a hardware buffer is
 too small.
 
 Silo overflows are caused by non-sio hardware hogging the bus or by
 interrupt latency outside the driver.  They should never occur at low
 speeds like 115200 bps even on 386/20's (except in -current, where
 interrupt latency outside the driver is certainly broken enough to
 matter even on 486DX2/66's).
 
 Bruce
 

From: WATANABE Kiyoshi <aab10490@pop16.odn.ne.jp>
To: freebsd-gnats-submit@FreeBSD.org, richw@webcom.com,
	bde@zeta.org.au
Cc:  
Subject: Re: i386/26261: silo overflow problem in sio driver
Date: Fri, 06 Apr 2001 21:51:16 +0900

 Sorry I sent temporary patch to gnats by mistake.
 
 Bruce Evans wrote:
 > On Tue, 3 Apr 2001, Rich Wales wrote:
 > 
 > >  WATANABE Kiyoshi wrote:
 > >  
 > >      > try this patch.
 > >      > +      cp4ticks *= 10;   /* to avoid buffer overflow */
 > >  
 > >  Thanks.  This helped to some extent, though I'm still seeing some
 > >  silo overflows even with the above patch.  Should the "10" be bumped
 > >  up to something larger, perhaps?
 > 
 > This can't possibly help reduce silo overflows, since it increases the
 > size a driver buffer, but silo overflows occur when a hardware buffer is
 > too small.
 > 
 > Silo overflows are caused by non-sio hardware hogging the bus or by
 > interrupt latency outside the driver.  They should never occur at low
 
 I agree.
 
 > speeds like 115200 bps even on 386/20's (except in -current, where
 > interrupt latency outside the driver is certainly broken enough to
 > matter even on 486DX2/66's).
 
 
 I guess that INTR_TYPE_FAST flag is  suspicious.
 Only sio, cy, and loran use this flag.
 
 but I cant get silo overflows in my Celeron-700Mhz/i810 machine.
 so I cant test.
 
 
 --- /usr/src/sys/isa/sio.c.orig      Tue Oct 10 19:08:12 2000
 +++ /usr/src/sys/isa/sio.c      Fri Apr  6 21:19:41 2001
 @@ -1333,16 +1333,20 @@
         com->irqres = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, 0ul, ~0ul, 1,
             RF_ACTIVE);
         if (com->irqres) {
 +#if 0
                 ret = BUS_SETUP_INTR(device_get_parent(dev), dev, com->irqres,
                                      INTR_TYPE_TTY | INTR_TYPE_FAST,
                                      siointr, com, &com->cookie);
                 if (ret) {
 +#endif
                         ret = BUS_SETUP_INTR(device_get_parent(dev), dev,
                                              com->irqres, INTR_TYPE_TTY,
                                              siointr, com, &com->cookie);
 +#if 0
                         if (ret == 0)
                                 device_printf(dev, "unable to activate interrupt in fast mode - using normal mode");
                 }
 +#endif
                 if (ret)
                         device_printf(dev, "could not activate interrupt\n");
         }
 
 
 WATANABE Kiyoshi  aab10490@pop16.odn.ne.jp
 
 

From: Bruce Evans <bde@zeta.org.au>
To: WATANABE Kiyoshi <aab10490@pop16.odn.ne.jp>
Cc: freebsd-gnats-submit@FreeBSD.org, richw@webcom.com
Subject: Re: i386/26261: silo overflow problem in sio driver
Date: Fri, 6 Apr 2001 23:32:33 +1000 (EST)

 On Fri, 6 Apr 2001, WATANABE Kiyoshi wrote:
 
 > > Silo overflows are caused by non-sio hardware hogging the bus or by
 > > interrupt latency outside the driver.  They should never occur at low
 > 
 > I agree.
 > 
 > > speeds like 115200 bps even on 386/20's (except in -current, where
 > > interrupt latency outside the driver is certainly broken enough to
 > > matter even on 486DX2/66's).
 > 
 > I guess that INTR_TYPE_FAST flag is  suspicious.
 > Only sio, cy, and loran use this flag.
 
 It is the main thing that is supposed to make silo overflows not happen.
 I don't know of any bugs in it.
 
 > 
 > but I cant get silo overflows in my Celeron-700Mhz/i810 machine.
 > so I cant test.
 
 You can probably get them by removing the INTR_TYPE_FAST flag :-).  Try
 toggling the caps lock key while input is arriving.  For some (most?)
 keyboards, setting the LEDs takes 2-5 msec.  Tty interrupts are disabled
 while the LEDs are being set, and 2-5 msec is long enough to cause silo
 overflows.
 
 Bruce
 

From: Rich Wales <richw@webcom.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: i386/26261: silo overflow problem in sio driver
Date: Mon, 16 Apr 2001 09:20:25 -0700 (PDT)

 I think my "silo overflow" problem is being caused (or, at least,
 provoked) by XFree86-4.x.
 
 I'm using XFree86 version 4.0.1 on the machine that exhibited the
 problem.  When I tried going back to version 3.3.6, the silo over-
 flows went away.
 
 Unfortunately, I had to go back to 4.0.1, as the XF86_SVGA server
 I need to use in 3.3.6 to run my ATI Xpert 128 video card has
 several nasty bugs -- but that's another story.
 
 I also get solid, error-free serial I/O if I escape out of X and
 display high-speed serial output directly to the monitor.
 
 Let me also mention, for the record, that I checked my null modem
 serial cable very carefully with a continuity tester, and the cable
 is definitely wired OK (it swaps RTS and CTS, for example).
 
 This presumably leaves open the question of whether the problem is
 due to a bug in XFree86-4.x itself, or if XFree86-4.x is innocently
 tickling some FreeBSD kernel bug.
 
 Rich Wales       richw@webcom.com       http://www.webcom.com/richw/
 

From: Rich Wales <richw@webcom.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: i386/26261: silo overflow problem in sio driver
Date: Fri, 27 Apr 2001 21:53:32 -0700 (PDT)

 Earlier, I wrote:
 
     > This presumably leaves open the question of whether the problem
     > is due to a bug in XFree86-4.x itself, or if XFree86-4.x is
     > innocently tickling some FreeBSD kernel bug.
 
 The people on the "xpert@xfree86.org" list suggest that the XFree86-4
 accelerator code is being overly aggressive about pipelining commands
 to the video card -- and, in the process, is locking up the PCI bus
 and interfering with the timely servicing of serial I/O interrupts.
 
 I was able to sidestep the problem (and get rid of the silo overflows)
 by enabling the "XaaNoScanlineCPUToScreenColorExpandFill" video driver
 option (this disables "indirect" CPU-to-screen color expansion).
 
 Alternatively, the "XaaNoSolidFillRect" option (disabling solid filled
 rectangle acceleration) also fixed the problem.  In either case, I see
 no degradation of overall video performance.
 
 The XFree86 people are still unclear as to how video acceleration ops
 could lock up the PCI bus, so I suppose there might still be a bug
 somewhere in FreeBSD that is allowing this problem to occur.  So it
 might not quite be time to close this PR yet.
 
 Rich Wales        richw@webcom.com        http://www.webcom.com/richw/
 
>Unformatted:
