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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[email protected]"
