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/