On Mon, 12 Jan 2004, Axel Waggershauser wrote: > On Mon, 2004-01-12 at 19:43, Alan Stern wrote: > > > > Not really... Your completion routine should get called as soon as the > > "USB disconnect" message appears in the syslog. Below you said that's > > what happens on your other system; the question is why doesn't it happen > > here? Are you submitting this URB from within your probe() routine? > > Yes, of course, I should get the completion handler called. Since I > called the usb_unlink_urb synchronously, I should have expected it to be > called before the unlink call returns, right?
No. One would think it should work that way, but it doesn't always. In particular, if the URB had _already_ been unlinked (but not yet sent to your completion routine) when you made the synchronous unlink call, then your call would return immediately with error code -EBUSY, as you found. > That recognized, I got the ingenious idea to check the return value of > the unlink call... It returns -EBUSY (-16). So it looks to me like the > controller driver sort of "got stuck" with this urb. Something "got stuck" with it, all right. It might have been the controller driver or it might have been the hcd "glue" layer. It might even have been something else. > Can I generally expect that the controller cancels the urb by itself > when the device gets disconnected (like it does on the other machine)? The controller does not. Neither does the controller driver. The hub driver is responsible for noticing when devices get disconnected. It's what prints the log message and it's what calls the disconnect() routine in drivers bound to the device. It also unlinks all the outstanding URBs for the device. > What am i supposed to do if the usb_unlink_urb call returns -EBUSY? Since that means the URB has already been unlinked, all you have to do is wait for your completion handler to be called. The problem is that something was preventing this from happening. You could try adding some printk statements to usb_hcd_giveback_urb() in drivers/usb/core/hcd.c -- that's the routine the controller driver uses to call your completion handler. > > > 7. I replug the device, the kernel panics immediately > > > > Do you know if the kernel detects the newly replugged device before > > panicking? > > No I do not. Any suggestions how to find that out? Like I said before, you need to use another computer as a serial console. > > The way to do this is to have another computer handy, hook them together > > by a null-modem serial cable, and then boot your test system telling it to > > use the serial port as the console. Then use a communications program > > like minicom on the other system to capture the log output and save it in > > a file. > > I don't have such a cable at the moment so I try to get as far as I can > without it. It's not hard to make such a cable, provided you have the proper connectors. Or you could buy one from any computer store; they aren't expensive. > I had the idea of unloading the uhci-hcd module after I unplugged the > device... attached is a syslog excerpt. Maybe you can extract some > useful information. It wasn't very helpful, I'm afraid. > If I try to load the module again, modprobe segfaults. > > Any suggestions for the next step to do? Try adding some printk's to the giveback_urb routine. That will at least tell you if the URB is getting stuck in the controller driver or somewhere else. You can also try adding some printk's to hcd_endpoint_disable() also in the hcd.c source file; that routine is the one that unlinks all the URBs when a device gets disconnected. 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
