Messages in this thread | | | From | Dan Christian <> | Subject | Re: 2.4.18 serial drops characters with 16654 | Date | Thu, 19 Sep 2002 11:24:24 -0700 |
| |
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/
| |