Re: 2.4.18 serial drops characters with 16654

[Dan Christian]

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.