From owner-freebsd-usb@FreeBSD.ORG  Mon Jun 19 07:32:14 2006
Return-Path: <owner-freebsd-usb@FreeBSD.ORG>
X-Original-To: freebsd-usb@freebsd.org
Delivered-To: freebsd-usb@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D0C3316A479
	for <freebsd-usb@freebsd.org>; Mon, 19 Jun 2006 07:32:14 +0000 (UTC)
	(envelope-from hselasky@c2i.net)
Received: from mail44.e.nsc.no (mail44.e.nsc.no [193.213.115.44])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 472FF43D45
	for <freebsd-usb@freebsd.org>; Mon, 19 Jun 2006 07:32:13 +0000 (GMT)
	(envelope-from hselasky@c2i.net)
Received: from Unknown-00-c0-9f-49-78-d8.lan (ti131310a080-6417.bb.online.no
	[85.165.217.17])
	by mail44.nsc.no (8.13.6/8.13.5) with ESMTP id k5J7W1cL023651;
	Mon, 19 Jun 2006 09:32:02 +0200 (CEST)
From: Hans Petter Selasky <hselasky@c2i.net>
To: freebsd-usb@freebsd.org
Date: Mon, 19 Jun 2006 09:32:05 +0200
User-Agent: KMail/1.7
References: <e6vefe$5bq$1@sea.gmane.org> <4495D48C.2000601@apeiron.net>
	<20060618.170129.1791048549.imp@bsdimp.com>
In-Reply-To: <20060618.170129.1791048549.imp@bsdimp.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200606190932.07437.hselasky@c2i.net>
Cc: mainland@apeiron.net
Subject: Re: ucom/uftdi dropping bytes, with debug logs FIXED
X-BeenThere: freebsd-usb@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: FreeBSD support for USB <freebsd-usb.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-usb>,
	<mailto:freebsd-usb-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-usb>
List-Post: <mailto:freebsd-usb@freebsd.org>
List-Help: <mailto:freebsd-usb-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-usb>,
	<mailto:freebsd-usb-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jun 2006 07:32:14 -0000

On Monday 19 June 2006 01:01, M. Warner Losh wrote:
> In message: <4495D48C.2000601@apeiron.net>
>
>             Geoffrey Mainland <mainland@apeiron.net> writes:
> : 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?
>
> 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