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 ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
