Date: Thu, 19 Aug 1999 12:30:08 -0700 From: Mike Smith <mike@smith.net.au> To: Brian McGovern <bmcgover@cisco.com> Cc: hackers@freebsd.org Subject: Re: sio doesn't do HW flow correctly?!? Message-ID: <199908191930.MAA07521@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 19 Aug 1999 12:09:27 EDT." <199908191609.MAA00362@bmcgover-pc.cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I thought I'd give people a chance to jump on this before I opened a PR on it. > > I'm currently using a Cyclades board at 115200 to talk to my PII laptop with > a 16550A UART on board via a null modem cable. I'm trying to run PPP over the > link with crtscts set, although I see the same problems using programs > other than PPP. > > I stuck a printf() at line 2113 of /usr/src/sys/i386/isa/sio.c to see if > CRTS_IFLOW was being turned on, whereas CRTS_IFLOW is the input half of > crtscts. > > I managed to get the printf, so I'm assuming that sio is being advised to do > RTS input flow control. > > However, when I start running data, I get silo overflows. Sometimes its more > frequent than others, but its enough to keep most of the packets from going > through the link. > > I have a breakout box on the line, as well as detectors in the Cyclades driver > for sensing line state change, and RTS never drops on the 16550A. It just > happily overflows. > > I realize that 99% of the time, sio is used with a modem. Therefore, also being > a modem tester, I realize that its rare to completely saturate a 115200bps link > between the modem and the UART in the PC (we have exactly one test case with > highly-compressible data where this happens reliably), so I suspect that this > problem may go unnoticed in many cases, simply because you don't fill the FIFO. > > I also went so far as to check individual RS232 signals via TIOCMSET to make > sure that the port functioned as commanded. It did so. > > So, I suspect the problem is that the driver is not correctly driving flow > control. > > I will therefore start to dive in to the problem to isolate it. However, I > figured I'd give everyone a chance to comment before I filed a PR. "Silo overflow" is "the input FIFO filled up before the interrupt handler managed to respond". Since flow control on the 8250-family parts is handled entirely in software, the problem is not that flow control is not being "correctly driven", but rather that interrupt response time on your system is sufficiently poor that the time between the interrupt trigger at either 8 or 14 (I forget) characters in the FIFO and overflow (at the 17th character) is less than the time it takes your system to respond to the interrupt. In order to debug this, you will need to use a logic analyser to trap the case where the interrupt is not handled quickly enough, and snoop enough of the rest of the system (probably parts of the PCI bus at least) to work out what it's actually doing to keep it away from the UART. A few weeks ago I was at a local embedded FreeBSD shop while they were debugging a similar problem they experience with their product, which turned out to be an extension of a known erratum in the Cyrix MediaGX's PIC macrocell, whereby multiple simultaneous interrupts are not handled correctly and thus the UART interrupts are lost completely. You may be facing a similar problem, but without the right test equipment and access to suitable documentation you may have considerable trouble in determining this for certain. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908191930.MAA07521>