lkml.org 
[lkml]   [1997]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.0.30 serial.c, ppp.c and pppd-2.2 questions
       Date: 	Fri, 18 Jul 1997 18:07:22 -0600
    From: Rob Riggs <rob@DevilsThumb.COM>

    In serial.c's receive_char() interrupt handler we read a
    char from the UART then just drop it if the flip buffer
    is full. If we are going to do this we should indicate
    an overflow error. An alternative solution is to test if
    the flip buffer is full before we read the UART and just
    break out of the read loop.

    The reason why we have to read chars from the UART even if the flip
    buffer is full is because if we don't, the serial interrupt flag never
    goes to zero, and we either loop endlessly in a loop (if the interrupt
    is level triggered, as in some PCMCIA cards) or never take another
    interrupt from the UART again (if the interrupt is edge triggered, which
    is typical for most PC cards).

    You're right that setting an overflow error is the most appropriate
    thing to do; however, reporting an overrun error itself requires a space
    in the flip buffer, which we won't have if the flip buffer is full.....

    If we don't read the UART data when the flip buffer is full
    it would be nice to mask the "data ready" interrupt until
    we have an empty flip buffer. This would require a callback
    from the tty layer's flush_to_ldisc() to notify us that the
    flip buffer has been flipped. This would also allow flow
    control based on how full the flip buffer is.

    This is one way we could solve things; however, in practice the flip
    buffer should really never overflow --- especially at baudrates of
    230400 or below. If it does, there's something really wrong with the
    system....

    In pppd, the code sets up the tty to IGNPAR & IGNBRK. In
    serial.c, if both of those are set, then it ignores parity
    errors and breaks, but also overflow errors. If we receive
    any of these errors in serial.c during a ppp connection,
    they are ignored.

    Specifically, this casues serial.c to not include parity errors and
    breaks in the flip buffer at all.... It's probably the wrong thing, if
    ppp.c is actually testing for errors in the tty flip buffer.

    1. Should pppd really be setting the tty to IGNPAR & IGNBRK?

    Probably not.

    2. Should serial.c ignore overflows if IGNPAR & IGNBRK are set?
    (I'm not sure what POSIX has to say about it. I didn't see
    anything mentioned in the books that I have.)

    Yes. POSIX doesn't mention overflows at all. However, serial.c ignores
    overflows in this case because this if IGNPAR and IGNBRK are set, this
    casues fast-track processing in N_TTY layer which assumes that there
    won't be extraneous characters in the flip character buffer. (This is
    the real raw mode support.)

    3. Should we drop data when the flip buffer is full and not
    report it as an overflow? (Again, POSIX may indicate
    what is and isn't allowed.)

    4. Should we drop data at all, or should we let the UART
    overflow on its own and report the error to us? (We
    would need to mask the "data ready" interrupt until
    there is an empty flip buffer available.)

    5. Are there any problems with doing flow control based on
    how full the flip buffer is?

    Consider... the flip buffer should be flipped on every clock tick (100
    times a second). The flip buffer is 512 bytes. So at anything under
    512000 bps, the flip buffer should be able to keep up.

    - Ted

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