ucom/uftdi dropping bytes, with debug logs FIXED

[Hans Petter Selasky]

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 ...

>
> : 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) {
> :

--HPS