Date: Sun, 25 Feb 1996 23:50:02 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs Subject: Re: i386/1042: Warning from sio driver reports wrong device FDIV045 Message-ID: <199602260750.XAA01521@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/1042; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.ORG, uhclem@freefall.freebsd.org
Cc: Subject: Re: i386/1042: Warning from sio driver reports wrong device FDIV045
Date: Mon, 26 Feb 1996 18:33:51 +1100
>...
>Ports sio0, sio2, sio3 connected to modems, sio1 not connected to anything
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>...
>Feb 25 19:48:00 nemesis /kernel: sio1: 247 more tty-level buffer overflows (total 3100)
>Note that the system reports the problem on sio1, when there is nothing
>connected to that port. That actual overrun probably occurred on sio0
>or sio3.
This may be caused by sio1 picking up radiation from the other ports.
It shouldn't occur if sio1 isn't open, however (then the UART may be
kept busy by the radiation but the driver ignores it). The radiation
problem can usually be fixed by connecting the port to something (even
something inactive).
The verbose error reporting can take long enough to interfere with the
reception of futher data :-(. Errors were once reported every clock
tick (the rc driver still does this) and slow machines take more than
one clock tick to report an error so the first error triggered an
endless cascade of errors.
>Another interesting thing is that the Cardinal modem is V.34 and receives
>compressed news at rates up to 3100CPS, but never appears to cause
>these overruns. The Telebits (Turbo PEP or PEP) only manage between
>1600 and 2100 CPS and they do experience these overruns when the DTE
>is set to 57600. There are no overruns when the Worldblazers are fixed
>at 38400.
Do the Telebits honour flow control?
>So the problems appear to be:
>1. Faulty reporting of the guilty device in the kernel warning message.
> It seems to always blame sio1 regardless of what lines are active.
Probably not.
>2. There doesn't appear to be any documentation on what the kernel
> error message is trying to report.
See the sio man page.
> Reducing the FIFO interrupt trigger did not help, implying a
> different type of overrun in the kernel instead of a hardware FIFO
> overrun. Because PEP tends to return data in bursts of 64 bytes,
> perhaps some software-based buffer is being overrun.
The raw queue has a size of only 1024 at all baud rates so it is quite
easy to overrun at high baud rates. At 115200 bps, 1024 bytes may arrive
in less than one process scheduling quantum (100 msec) so there the buffer
is too small if there are 2 hog processes. Flow control had better work.
> Since there appears to be code in sio.c that would detect overruns
> in the hardware FIFO, report this and lower the trigger value
> automatically, either this code isn't working or this isn't the
> type of overrun the kernel is trying to report. Again, no
> documentation.
That code has almost always been disabled and doesn't exist in -current.
It tended to drop the trigger level to 1 for transient errors.
>3. When the kernel message is displayed, it usually is displayed three
> times in a row, all with the same timestamp. It only appears once
> in /var/log/messages.
Messages are normally repeated for each root login.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602260750.XAA01521>