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.
-Dan
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:27 EST