Date: Sun, 18 Jun 2006 18:32:44 -0400 From: Geoffrey Mainland <mainland@apeiron.net> To: freebsd-usb@freebsd.org Cc: freebsd-usb@freebsd.org Subject: Re: ucom/uftdi dropping bytes, with debug logs FIXED Message-ID: <4495D48C.2000601@apeiron.net> In-Reply-To: <20060617.131208.1589021232.imp@bsdimp.com> References: <e6vcnn$um$1@sea.gmane.org> <20060616.170242.1467007423.imp@bsdimp.com> <e6vefe$5bq$1@sea.gmane.org> <20060617.131208.1589021232.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote:
> In message: <e6vefe$5bq$1@sea.gmane.org>
> Geoffrey Mainland <mainland@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?
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) {
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4495D48C.2000601>