On Fri, 18 Jul 2003, Oliver Neukum wrote: > It seems to me that you are racing against HC hardware.
Yes, certainly. > You cannot unlink an URB that is being executed, can you? With UHCI you can. What will happen is that the HCD will finish executing the current TD, but on its next loop through the hardware schedule the QH will no longer be in the chain. As a result, you end up with an invalid USB transaction: the initial packets go out on the bus but the final ones don't. > At the same time you must retain EINPROGRESS in the status > field until some time _after_ io is completed, because you > need to evaluate the result of the transfer. See above. The status can be set to -ECONNRESET because the transfer doesn't finish. Or maybe the race goes the other way and the transfer does finish; nevertheless the URB is marked as having been unlinked. The driver does not check the hardware status field to see whether the transfer completed successfully before the unlink occurred. Part of this problem is caused already in the hcd glue layer. hcd_unlink_urb() sets urb->status to -ECONNRESET or -ENOENT _before_ calling the HC driver to dequeue the URB. One could easily argue that this behavior is a bug. > IMHO the only way to learn whether an URB can be unlinked > is to try it. Is there any point in the code that tries to determine whether an URB can be unlinked without actually trying it? Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
