Bug 26261

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) {

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/

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

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

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

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/

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/