On Tue, 13 Jan 2004, David Brownell wrote: > Axel Waggershauser wrote: > > On Tue, 2004-01-13 at 16:36, Alan Stern wrote: > > > >>>I still have these printks in giveback() and found to my surprise that > >>>this function gets called repeatedly for an other urb with a frequency > >>>of about 4/sec. This starts about the same time the unplugging is > >>>detected, that means shortly after I see the "uhci_hcd 0000:00:07.2: > >>>shutdown urb" and keeps on endlessly. At that time there is no usb > > "Endlessly"?? I'd expect to see one message for each URB queued > to each endpoint on that device. Anything else indicates a bug. > Looping on one urb? Aha! > > With device state USB_STATE_NOTATTACHED, no new URBs may be queued; > and the only state change allowed for the ones now queued is to be > given back -- just once! -- through the completion function.
No, no! The URB's Axel is seeing are not being sent to his device; they are root hub status queries. Normally these don't show up very much because they only complete when a status change event occurs. But if khubd is locked up then it can't clear the various "port changed" flags in the root hub driver, so the status query completes every time it is called -- and of course it is the same URB each time. > >>>device attached to the machine. Maybe this behavior is part of the > >>>problem or a hint where to search next? > >> > >>Maybe. It indicates the the hub driver is stuck waiting for something; > >>most likely it's waiting for your driver to return from a call to its > >>disconnect routine. > > > > > > That fits quite well with what I see. I switched back to my synchronous > > unlinking and now the these giveback() calls end as soon as disconnect() > > returns. > > Which is completely bizarre. If all you changed was whether or > not you used URB_UNLINK_ASYNC, and you kept _correct_ logic to > wait for all of your urb completions (including cancelations), > all that would do is add a duplicate synchronization point. > Which by definition is not necessary. One can hope this is all > from just one bug, not a complex of them. While it's not clear what the source of the bug(s) may be, Axel said that following the change his driver now returns from its disconnect() callback. That unblocks the khubd driver, which allows it to process the port change events, and so the event notifications stop. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
