M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Geoffrey Mainland <[EMAIL PROTECTED]> 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?
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) {
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
