On Fri, Jun 21, 2002 at 05:35:36AM -0700, David Brownell wrote: > >>>Summary: > >>>Seems like a bug in usbdevfs. The attached program is enough to > >>>trigger it. > >> > >>Sure does :( > >> > >>Don't remember if I've asked, but does this also happen on 2.5? > > > > > >It does with 2.5.22 (with an oops!). Here is the oops: > >... > >Trace; cc8a0427 <[usb-uhci-hcd]uhci_urb_dequeue+53/5c> > >Trace; cc8913cf <[usbcore]hcd_unlink_urb+143/1cc> > >Trace; cc891890 <[usbcore]usb_api_blocking_completion+0/20> > >Trace; cc891882 <[usbcore]usb_unlink_urb+26/34> > >... > > > >Code; cc89f4c0 <[usb-uhci-hcd]uhci_unlink_urb_sync+90/118> > >00000000 <_EIP>: > >Code; cc89f4c0 <[usb-uhci-hcd]uhci_unlink_urb_sync+90/118> <===== > > 0: 8b 45 00 mov 0x0(%ebp),%eax <===== > > Ah, so both of the "hcd-ized" UHCI drivers have a common bug: > they've got logic to look at the USB_ASYNC_UNLINK flag and > block unless it's clear ... but the hcd framework is already > handling the synchronous behavior, so that's wrong. > > Try to repeat that with the patch I've attached, which rips > out that duplicated code ... and so should at least get rid of > that oops, even if it doesn't entirely fix the timeout issue. > > (Or: try with either the OHCI driver, or with the EHCI driver > through a USB 2.0 hub, if you have appropriate hardware.) > > - Dave > > p.s. Disclaimer about this patch: all it does is rip out > code and make it compile without warnings, but I've > not tested it otherwise. There's a possiblity it'll > uncover latent issues on the other code path, but then > that's exactly why we only want one unlink code path > inside the HCDs! So Greg, please merge anyway ...
Applied, thanks. It seems to work for me, but I haven't stressed it out much yet. greg k-h ------------------------------------------------------- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
