Re: 2.4.18 serial drops characters with 16654

From: Dan Christian (
Date: Thu Sep 19 2002 - 13:24:24 EST

This still isn't getting at the core problem. I'm sending data out the
port and dropping characters. The receive works fine.

It can't be a problem with the receiving device being over-run, since
the 16550 works (even though it sends several bytes after CTS drops),
and the 16654 doesn't (it stops after the current byte).

I think that data must be lost when the receiving device drops CTS.
Either this is a hardware flaw (and data is lost from the transmit
FIFO), or there is some kind of race condition between the CTS drop and
re-loading the FIFO.


On Thursday 19 September 2002 10:38, Alan Cox wrote:
> On Thu, 2002-09-19 at 18:27, Dan Christian wrote:
> > The problem seems to be related to the RTS/CTS flow control
> > handling. The 16654 handles flow control in hardware, but the 16550
> > does it in software (I've verified this with a digital
> > oscilloscope). I don't currently have the equipment to compare
> > when the lines drop and which characters are lost.
> Actually you can do it in hardware on the 16550 depending how its
> wired. Take a look at the usenet-2 serial port design some day. The
> software mode we do does in theory mean heavy delay to the bh
> handling might delay the assertion excessively. That I think may be
> the real explanation here.
> Its
> buffer full
> bh handler delayed by bh load (tasklet nowdays I guess I
> mean) overrun
> overrun
> ...
> ksoftirqd
> Oh look I should do carrier
> Russell - does that sound reasonable.
> If so the answer yet again (as with the gige performance and some
> others) might be to make it much much harder for stuff tofall back to
> ksoftirqd.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:27 EST