dillon at apollo.backplane.com
Mon Sep 29 09:50:07 PDT 2003
:Andrew Atrens wrote:
:> Seen on my home system ( 56k modem ) -
:> Sep 9 22:35:49 atrens-home /kernel: sio0: 7 more silo overflows (total 35)
:> these seem to be inert but are happening quite a lot - essentially
:> whenever I'm transferring data (telnet, ftp, web) through the modem.
: I was browsing through the GNATS database and I remembered this
: post. You might wanna checkout the following PRs, which seem to
: be reporting bugs to do with silo overflows. One of the PRs
: also has a workaround, which you might want to try and tell us
: if it worked.
: PR (1): http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/41569
: PR (2): http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/26261
:hmp at xxxxxxxxxxxxx
There are a couple of issues here. First, until we unwind the
big giant lock and/or remove it from the fast interrupt path, there
are going to be latency issues with DragonFly's servicing of interrupts
and characters may be lost even if the serial hardware FIFO level is
set to FIFO_RX_LOW.
The hardware fifo is typically 16 characters. FIFO_RX_HIGH interrupts
when there are 4 characters left. FIFO_RX_MEDH interrupts when there
are 8 characters left (I think). Normally this would be sufficient
time for an interrupt to come and clean out the FIFO (8 chars @ 115200
== 694 uS, but due to the current issues latencies can be much higher.
Lower FIFO levels will reduce the silo errors but they will also
be severely inefficient from a cpu perspective. You might remember
that in FreeBSD-4 Bruce had set the level to FIFO_RX_HIGH and I
rammed through a change to default it to FIFO_RX_MEDHI at baud
rates higher then 4800 bps.
I don't think we want to lower the FIFO level any more then MEDHI,
at least not until we clean up the interrupt path. I recommend
reducing the host<->modem baud rate from 115200 (which is what it is
likely set at) to 57600.
<dillon at xxxxxxxxxxxxx>
More information about the Bugs