On Thu, Jul 17, 2003, Alan Stern <[EMAIL PROTECTED]> wrote: > A bug has turned up in the UHCI driver. Briefly, when an URB completes, > uhci_transfer_result() doesn't store the status in urb->status but only in > urbp->status. urb->status is set just before calling hcd_giveback_urb(). > > However, the hcd glue layer uses urb->status == -EINPROGRESS as a test for > whether or not to allow the URB to be unlinked. As a result, it's > possible to unlink an URB after it has completed and is already on the > urb_complete_list. This causes severe problems.
This check is kinda racy in the first place, but I can see the problem with the current code. > My suggestion is to set urb->status along with urbp->status in > uhci_transfer_result(). In fact, looking through the code it appears that > urbp->status is completely unnecessary, since it should pretty much always > be equal to urb->status. Is there any reason for keeping urbp->status? I actually added urbp->status to fix a bug in 2.4. I don't think it applies to 2.4 or 2.5/2.6 anymore. I think we can probably clean that up. > P.S.: In addition, when URBs are dequeued, they should be added to the > _tail_ of remove_list. That way the completion handlers will be called in > the order the URBs were unlinked. I assume you mean urb_remove_list? Looking at the code now, I have no idea why I named it uhci_remove_pending_qhs(), since it has nothing to do with QHs, only URBs. The idea was to delay completing the URBs because the QH/TDs might still be in use by the HC until the next frame. JE ------------------------------------------------------- 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
