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    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site