Re: Khubd calls disconnect() after driver module unloaded

On Mon, 12 Nov 2007, David Woodhouse wrote:

> We have an out-of-band reset line for kicking the wireless device in the
> head when it craps itself. We use it on driver unload, which means that
> the device is reliably removed from the bus right in the middle of our
> exit_module() function.
> 
> When this happens, khubd is scheduled to deal with it and call
> device_detach().

You mean "device_del()".  But device_del() doesn't always end up 
calling down to a disconnect method.

> But that doesn't actually happen until about a second
> later. By which time the module has already gone. 
> 
> > The device lock is supposed to serialize this so that no matter which
> > one comes first, the end result is correct.
> 
> "supposed to". :)
> 
> Let me take out the hack and show...
> 
> [  127.934681] Resetting OLPC wireless via EC...
> [  127.961925] olpc-ec:  running cmd 0x25
> [  127.991214] devpath 1 ep3in 3strikes
> [  128.017892] usb 1-1: USB disconnect, address 2
> [  128.045418] PM: Removing info for No Bus:usbdev1.2_ep02
> [  128.074081] PM: Removing info for No Bus:usbdev1.2_ep83
> [  128.101835] msh0: no IPv6 routers present
> [  128.146806] usbcore: deregistering interface driver usb8xxx
> [  128.178823] Unloading libertas driver with refcount 1. Expect it to die soon...

It's hard to tell what's going on here without additional debugging 
messages.  At what point does your disconnect method get 
called?  At what point does the device_del() call in hub.c return?  At 
what point does the rmmod task call driver_detach(), and at what point 
does the call return?

The problem you describe is supposed to be handled as follows in
drivers/base/dd.c.  The rmmod task goes through driver_unregister() and
bus_remove_driver(), ending up in driver_detach() where the call
to __device_release_driver() is in the scope of the dev->sem lock.
Similarly, the khubd task goes through device_del() and
bus_remove_device(), ending up in device_release_driver() where the
call to __device_release_driver() is also in the scope of the dev->sem
lock.  Only the first of those should be able to reach your driver's
disconnect method, since the routine ends by setting dev->driver to
NULL.

Maybe you should add some debugging to __device_release_driver(): 
entry, exit, value of dev->driver, and call to the remove routine.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel