A large buffer could solve the problem, but would'nt it be better if
the driver could get a fore-warning when the flip buffer was on the
verge of getting full? It could then stop the RX interrupts until
the "flush_to_ldisc" would empty and flip the flip buffer and inform
the driver about the same. I have had instances on a loaded system
with all the ports on a mulltiport card doing RX s, the
"flush_to_ldisc" will not be scheduled enough to make sufficient free
space on the flip buffer for the next RX interrupt.
The driver is supposed to schedule a FLIP operation to take place at the
next clock tick. So the problem only comes up if (a) there's enough
interrupts going on that the clock tick gets delayed, or (b) the
baudrate is faster than (5120 * clock_frequency) (i.e., 512kbps on an
i386).
You're never supposed to let the flip buffer get full --- if you do,
there's something wrong with your system --- so there's not any need to
do any flow control on the thing.
Note also that the flip buffer is only there to improve interrupt
latency and efficiency in handling small numbers of characters. For
some cards, you may be better off bypassing it altogether. For example,
the Rocketport driver has huge on-board FIFO's, is polled on the
clock tick, and the driver can read in a hundred character or more at a
time. Therefore, there's no point using the flip buffer, and so the
Rocketport driver simply calls the line discpline receive_buf() directly.
- 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/