Re: [linux-usb-devel] Re: [PATCH] USB changes for 2.5.58

[David Brownell <david-b@pacbell.net>]

Doug Ledford wrote:

> Once all the commands are gone and no more are arriving, then if, and only 
> if, someone actually removes the device from the scsi subsystem (maybe 
> hotplug manager or something) then you will get the typical 
> slave_destroy() call to tell you that it is safe to release all resources 
> related to this device.  Otherwise, the device will hang around as an 
> offline device until someone does  

Does that mean there's no LLD state for that HBA (and/or devices
connected to it), so that some _other_ kind of state is representing
these zombie devices?

Seems like it must.  USB physical device model state must go away
when the device does, rather promptly ... the disconnect() is invoked
in a thread, so it can block for a very short while.   Blocking more
than a few milliseconds there is extremely antisocial though, so
that can't be the device state that will "hang around" until some user
mode agent does your suggested removal action.

I get the impression these zombie devices are largely what Linus has
recently asked to be removed from usb-storage.  Which has, so far,
been quite keen to re-animate them ... maybe a useful incremental
improvement would be just to give up the re-animation part, in such
a way that the scsi a/b/c/d identifiers eventually get recycled.


>   echo "scsi-remove-single-device a b c d" >/proc/scsi/scsi
> to remove it.

That ought to be trivial for some hotplug agent to do ... but there's
the issue of where "a b c d" come from.  Last I looked, there was no
obvious way to associate such data with the SCSI hotplug events; the
sysfs state wasn't very helpful.

- Dave