q: USB_SET_TIMEOUT in ugen.

[Weongyo Jeong]

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