On Tue, Mar 09, 2021 at 07:04:34PM -0800, Asutosh Das (asd) wrote: > Hello > I & Can (thanks CanG) debugged this further: > > Looks like this issue can occur if the sd probe is asynchronous. > > Essentially, the sd_probe() is done asynchronously and driver_probe_device() > invokes pm_runtime_get_suppliers() before invoking sd_probe(). > > But scsi_probe_and_add_lun() runs in a separate context. > So the scsi_autopm_put_device() invoked from scsi_scan_host() context > reduces the link->rpm_active to 1. And sd_probe() invokes > scsi_autopm_put_device() and starts a timer. And then driver_probe_device() > invoked from __device_attach_async_helper context reduces the > link->rpm_active to 1 thus enabling the supplier to suspend before the > consumer suspends. > I don't see a way around this. Please let me know if you > (@Alan/@Bart/@Adrian) have any thoughts on this. How about changing the SCSI core so that it does a runtime_get before starting an async probe, and the async probe routine does a runtime_put when it is finished? In other words, don't allow a device to go into runtime suspend while it is waiting to be probed. I don't think that would be too intrusive. Alan Stern
