ucom/uftdi dropping bytes, with debug logs FIXED

[M. Warner Losh]

In message: <200606190932.07437.hselasky at c2i.net>
            Hans Petter Selasky <hselasky at c2i.net> writes:
: On Monday 19 June 2006 01:01, M. Warner Losh wrote:
: > In message: <4495D48C.2000601 at apeiron.net>
: >
: >             Geoffrey Mainland <mainland at apeiron.net> writes:
: > : M. Warner Losh wrote:
: > : > In message: <e6vefe$5bq$1 at sea.gmane.org>
: > : >
: > : >             Geoffrey Mainland <mainland at apeiron.net> writes:
: > : > : The fact that this runs fine under VMWare makes me strongly suspect a
: > : > : timing issue that is fixed by some sort of buffering at the VMWare
: > : > : level. Where should I start to look to hack something in to test
: > : > : this? The ucom driver seems to be setting up the read transfers that
: > : > : don't complete on time.
: > : >
: > : > I'd start looking into ucom.c and uftdi.c.
: > : >
: > : > Warner
: > :
: > : Here's a diff against ucom.c version 1.57 that fixes the problem for me.
: > :   I'm sure this is not the "correct" fix, but it stops bytes from being
: > : dropped :). I assume aborting the read and immediately restarting it
: > : flushes some pending data. Why is ucomstop is called so frequently by
: > : the tty code?
: >
: > I don't know.  Sure is weird.  I've seen tip take 100% of the CPU when
: > talking with a uftdi dongle too.
: >
: > Warner
: 
: It does not make sense to re-start the read pipe when one is flushing the 
: output pipe. Probably the cause of a lot of quirks ...

thinking about it, that makse sense.

: > : Geoff
: > :
: > : Index: ucom.c
: > : ===================================================================
: > : --- ucom.c (revision 3)
: > : +++ ucom.c (working copy)
: > : @@ -622,10 +622,12 @@
: > :
: > :   DPRINTF(("ucomstop: %d\n", flag));
: > :
: > : +#if 0
: > :   if ((flag & FREAD) && (sc->sc_state & UCS_RXSTOP) == 0) {
: > :    DPRINTF(("ucomstop: read\n"));
: > :    ucomstopread(sc);
: > :    ucomstartread(sc);
: > : +#endif
: > :   }
: > :
: > :   if (flag & FWRITE) {
: > :

Hmmm, looking at this patch again, I don't believe it was ever tested,
since the } is outside the if. :-(

Warner