Matthew Dharm wrote: > The issue is the word 'often', which implies 'sometimes not'. > > If the urb completes via unlink or transfer failure, that's fine. I chose > not to unlink and let them fail. But if there is a condition under which > they won't fail, I'd like to know about it.
That condition would be a bug. I've never seen it happen, but I think Manfred says he's seen it (rarely) with usb-uhci-hcd. - Dave > Matt > > On Thu, Jul 04, 2002 at 08:08:40PM -0700, David Brownell wrote: > >>Matthew Dharm wrote: >> >>>Blocking until all URBs complete is (effectively) what we do now... >>> >>>But this is an important question.. do those URBs get 'completed' or not at >>>disconnection? Better question: should they? >> >>Please explain your question a little better. I just >>said they'll complete via unlink or transfer failure. >>What's the issue? >> >> >> >>>Matt >>> >>>On Thu, Jul 04, 2002 at 03:05:19PM -0700, David Brownell wrote: >>> >>> >>>>Matthew Dharm wrote: >>>> >>>> >>>>>Now... wait a second here.... >>>>> >>>>>You say the dirver "is supposed to wait until all urbs" are completed... >>>>>but we're talking about the case where the device is now gone... >>>>> >>>>>So how do the urbs complete? Something is causing them to complete when >>>>>the cable is removed -- that's the behavior I've observed, at least. >>>> >>>>Normally I'd expect the device driver to forcibly unlink >>>>anything it's started. Failing that, the host controller >>>>will often fail the transfer if the device is gone. (But >>>>I seem to recall recent speculation about maybe one of the >>>>UHCIs not doing that.) >>>> >>>>In either case, the device driver should block until all >>>>its pending URBs complete. >>>> >>>>- Dave >>>> >>>> >>>> >>>> >>>>>Matt >>>>> >>>>>On Thu, Jul 04, 2002 at 01:23:54PM -0700, David Brownell wrote: >>>>> >>>>> >>>>> >>>>>>>>Test case: user pulls out the usb cable while a transfer is in progress. >>>>>>>>urb submitted to the device, reply not yet received. >>>>>>>>Result: storage_disconnect() would hang for 20 seconds until >>>>>>>>command_abort() is called. >>>>>>> >>>>>>> >>>>>>>No, not quite. The HCD accelerates the URBs to completion if the device >>>>>>>is removed with an URB pending on it. It therefore shouldn't hang for the >>>>>>>timeout -- if you're seeing this behavior, then the HCD is broken. >>>>>> >>>>>>Actually all of the interesting work is triggered by khubd, >>>>>>and then the device driver. >>>>>> >>>>>>Khubd calls usb_disconnect() for the device. That disconnects >>>>>>each driver (which is supposed to wait until all urbs it's >>>>>>submitted have completed, and not submit any more URBS). >>>>>> >>>>>>Only at the very end of this does the HCD hear anything about >>>>>>devices going away. If there's any URB still submitted at that >>>>>>point it's not a bug in the HCD at all ... but in a device >>>>>>driver that didn't implement disconnect() correctly. >>>>>> >>>>>>- Dave >>>>>> >>>>>> >>>>>> >>>>> >>>>> >> > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
