q: USB_SET_TIMEOUT in ugen.

[Hans Petter Selasky]

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?

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

--HPS