q: USB_SET_TIMEOUT in ugen.

[Weongyo Jeong]

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.  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

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.

regards,
Weongyo Jeong