Return-Path: <owner-freebsd-usb@FreeBSD.ORG>
Delivered-To: freebsd-usb@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 568211065674;
	Fri, 20 Mar 2009 03:58:55 +0000 (UTC)
	(envelope-from weongyo.jeong@gmail.com)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237])
	by mx1.freebsd.org (Postfix) with ESMTP id 0DC188FC13;
	Fri, 20 Mar 2009 03:58:54 +0000 (UTC)
	(envelope-from weongyo.jeong@gmail.com)
Received: by rv-out-0506.google.com with SMTP id l9so885681rvb.43
	for <multiple recipients>; Thu, 19 Mar 2009 20:58:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:received:from:date:to:cc
	:subject:message-id:reply-to:references:mime-version:content-type
	:content-disposition:in-reply-to:user-agent:organization
	:x-operation-sytem;
	bh=yWk/0+e8vjbOtBM+sDrYbGGnZA4thT8W/ltmKPxefX8=;
	b=uCLK17U5x5tbFz776eoww69MfVEjrtQfSBrTsvgm2u2/VKhOY0q84h7qjiGeyEwfo3
	CfP/0hQ4AR7O1lkW7Na7MSr/XCgGiQ3a+PTiYDepLIFCk/VBZ8K0Sp7toMYLQ9b6yLCN
	AEYRw99S3bUYW0TMJsruj02BYJ+mbtdOo8Q8w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=from:date:to:cc:subject:message-id:reply-to:references:mime-version
	:content-type:content-disposition:in-reply-to:user-agent
	:organization:x-operation-sytem;
	b=Y4qrDZAd6pyT2hIipvsObJO1sHrXSyPmDI+JLBq6ok0774p7Hqv6OkYEWMlmS667RA
	yIdiwAP40z8m1d4kiV303esrfRGjHocpLsErNh8fz1P8BcsPtebLACDlHtdRBlFatEV3
	kgs/U5MWmrEn9CTYJE0+MoQLcg7v7Baf0OK2g=
Received: by 10.141.114.15 with SMTP id r15mr1121417rvm.179.1237521534558;
	Thu, 19 Mar 2009 20:58:54 -0700 (PDT)
Received: from weongyo ([114.111.62.249])
	by mx.google.com with ESMTPS id b39sm274522rvf.10.2009.03.19.20.58.52
	(version=SSLv3 cipher=RC4-MD5); Thu, 19 Mar 2009 20:58:53 -0700 (PDT)
Received: by weongyo (sSMTP sendmail emulation);
	Fri, 20 Mar 2009 12:58:50 +0900
From: Weongyo Jeong <weongyo.jeong@gmail.com>
Date: Fri, 20 Mar 2009 12:58:50 +0900
To: Hans Petter Selasky <hselasky@c2i.net>
Message-ID: <20090320035850.GB17221@weongyo.cdnetworks.kr>
References: <20090318073032.GA12632@weongyo.cdnetworks.kr>
	<200903190901.23844.hselasky@c2i.net>
	<20090319105200.GA17221@weongyo.cdnetworks.kr>
	<200903191432.24364.hselasky@c2i.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200903191432.24364.hselasky@c2i.net>
User-Agent: Mutt/1.4.2.3i
Organization: CDNetworks.
X-Operation-Sytem: FreeBSD
Cc: Sam Leffler <sam@freebsd.org>, freebsd-usb@freebsd.org,
	Andrew Thompson <thompsa@freebsd.org>
Subject: Re: q: USB_SET_TIMEOUT in ugen.
X-BeenThere: freebsd-usb@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Weongyo Jeong <weongyo@freebsd.org>
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: Fri, 20 Mar 2009 03:58:55 -0000

On Thu, Mar 19, 2009 at 02:32:23PM +0100, Hans Petter Selasky wrote:
> Hi,
> 
> On Thursday 19 March 2009, Weongyo Jeong wrote:
> > On Thu, Mar 19, 2009 at 09:01:23AM +0100, Hans Petter Selasky wrote:
> > > On Thursday 19 March 2009, Weongyo Jeong wrote:
> > > > ugen_default_read_callback:384: actlen=0, aframes=0
> > > > ugen_default_read_callback:384: actlen=0, aframes=0
> > > > ugen_read_clear_stall_callback:477: f=0xc4d5b000: stall cleared
> > >
> > > One difference from the old ugen implementation is that a stall error
> > > does not cause any error to be returned to userland!
> > >
> > > You could try to return a ZLP on errors. Try this patch:
> > >
> > > http://perforce.freebsd.org/chv.cgi?CH=159423
> > >
> > > If you need to distinguish a ZLP from a STALL, then you have to use the
> > > new libusb! Ugen is not meant to be a replacement for libusb!
> >
> > Thanks you for a patch but it's not a answer what I want because my
> > symptom is that recv(2) waits forever before or returns 0 after applying
> > your patch.  It shouldn't return 0 or nothing that the size of the recv(2)
> > return value should be 512.
> 
> The ugen interface is now double buffered, so it will read data in the 
> background! The old was not double buffered. There are currently only two 
> buffers. If you see the packet in the analyzer it has most likely also ended 
> up in a UGEN buffer.
> 
> > I tried to dump USB transactions using USB 
> > analyzer and the dump file is available at:
> >
> > 	http://people.freebsd.org/~weongyo/uathload_20090319_export.txt
> 
> What happens if you change:
> 
>               |                if (read(msg, &rxmsg, sizeof(rxmsg)) != 
> sizeof(rxmsg)) {
> 215:          |                        VERBOSE("%s", "\n");
>               |                        err(-1, "error reading msg (%s)", 
> msgdev);
>               |                        break;
>               |                }
> 
> Into while loop for sake of testing? So that if the length is 0 you loop one 
> more time and if you have more than X zero lengths returned, you break?

I tried to do your suggestion but no changes.  read(2) returned always 0
(after applying http://perforce.freebsd.org/chv.cgi?CH=159423) that it
looks ugen missed a transaction the device sent to the host.

> >
> > Interesting packets could be found after 241 transactions and the steps
> > of program are as follows:
> >
> > 	write(endpoint 0x1, buf, 512);
> > 	write(endpoint 0x2, buf, 512);
> > 	write(endpoint 0x2, buf, 512);
> > 	write(endpoint 0x2, buf, 512);
> > 	write(endpoint 0x2, buf, 512);
> > 	read(endpoint 0x81, buf, 512);  <-- here error.
> >
> > As you can see with looking the dump file, ugen couldn't catch the read
> > event even though the USB stick responses data at Transaction 264, 265
> > and 266.  It looks the problem is in ugen(4).  As looking usb_generic.c
> > it looks the read/write pipe are opened on the fly when read(2) or
> > write(2) systemcalls are called though in the previous ugen(4) in usb1
> > all pipes are opened at open(2).  Could this difference affect this
> > symptom?  I'd try to test another cases.
> 
> The old ugen would also do a clear-stall which the new one does not do, unless 
> you do an IOCTL before the first read! That is also something you can try.

Also I tried this with commenting out all of ioctl(2) calls.  But after
it it looks recv(2) never returns.

regards,
Weongyo Jeong