7966 sd attach should not issue potentially slow scsi commands
Review Request #399 - Created March 13, 2017 and discarded
Work by Hans Rosenfeld (mostly).
Move everything requiring sending SCSI commands to device out of initial attach routine and do the remaining work using taskq.
As we had the PM completely disabled in sd, I have fixed the PM paths as well for upstreaming. As we need to have pm-components available when finishing attach, install the initial property having all states for both "power conditition supported" and "start/stop" cases in sdattach(). Remap the "start/stop" power levels to the "power condition supported" ones, and update the property afterwards if needed in sd_setup_pm()->sd_update_pm_components(), so now a "start/stop" would look like the following:name='pm-components' type=string items=3 dev=none value='NAME=spindle-motor' + '0=stopped' + '3=active'
This have been in production for quite some time.
I've retested the power stuff after having fixed it on a bunch of systems, where drives are not pm-capable at all, support only start/stop, and the desktop ones supporting power conditition.
|What is 'smart probing'?||Robert Mustacchi|
Can you clarify how a failure to attach in the taskq will lead to the memory and related device nodes being cleaned up? It feels like we'll need something to call detach, but blocking something forcing that, it'll just sit around. Is that right? I also, more generally, am not sure about all the power state changes. You said that you generally have tested all this with power management disabled, is that right? Do you have any idea of what the impact of that kind of overarching change is on something like this: https://github.com/joyent/illumos-joyent/commit/b380d4fce9c309a568bb92531d552f1cc69d985b which I was getting ready to upstream?