[lkml]   [1999]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Kodak DC-265 overrunning linux serial driver?
    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

    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.021 / U:71.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site