Messages in this thread |  | | | Date | Fri, 19 Nov 1999 18:44:57 -0500 | | From | "Theodore Y. Ts'o" <> | | Subject | Re: Kodak DC-265 overrunning linux serial driver? |
| |
From: brian@worldcontrol.com Date: Fri, 19 Nov 1999 11:00:26 -0800
I believe I'm running into the same problem with another device. A Cardinal 56K modem, which has had similar problems for about a year. It works up to 38400 but becomes unreliable at higher speeds. What has worried me about that problem is that it works fine at 115200 under FreeBSD. However, I've just lived with the 38400.
The bottem line when using a 16550A UART in a UNIX-like OS is that the system must service the FIFO in the time it takes for 14 or so characters to come in. Apparently, this is not happening.
Actually, the UART interrupts when the FIFO is half-full, so the OS has 8 character times in which to react.
On the other hand, even at 38400 I get lots of errors. Can the latency in linux be that bad?
Are you using an old IDE controller that does programmed I/O (i.e., no DMA?). If so, look at the man page for hdparm's -u option. That should make your problem go away. (The explanation for the -u option will also explain why this isn't the default.)
If my analysis is right I can think of two fixes for this problem, of which I consider only one of value.
The of value fix works like this:
The serial driver itself keeps a local circular buffer of say 4096 characters.
The serial driver already has a local two 512 byte double-buffers, and that's not the problem. At 38400, the problem isn't that the we're not getting things out of the double-buffer to the 4k high-level tty buffer fast enough.
The problem is that certain other device drivers (and the IDE PIO driver is the prime example) keeps interrupts off to long, thus increasing the interrupt latency to the point where you start overflowing the FIFO. Increasing the buffer which the interrupt routine uses to copy characters out of the FIFO isn't going to help, because they're getting lost before the interrupt routine even has a chance to run.
One thing I've never understood is that many of these problems come about due the the old unix tty line discipline. Why not make a raw mode serial driver that bypasses all this?
There is a raw mode in the serial driver; if you don't need to do any cooked line discpline processing, all of that code gets bypassed. But as I explained, the problem is that characters are getting lost before the interrupt routine even has a chance to run.
Another fix is implemented in some UARTS (16550A like chips).
The other fix is to use UART's with bigger FIFO's. The Oxford Semiconductor has a UART with a 128-byte FIFO, which is quite nice.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |