Damien Le Moal <dlemoal () kernel ! org> writes: > In theory, yes, that was the intent. In practice, the verify was issued from > scsi PM resume context while the actual drive port reset + revalidation is done > in libata EH context, triggered from ATA port resume context which itself was > not synchronized/ordered with the scsi disk resume. So we ended up with the > verify command execution sometimes being attempted with the drive not even > revalidated yet, or with the port/link not even active sometimes (depending on > timing). So problems all over and deadlocks due to scsi revalidate using the > device lock, which PM use too. Yikes. > See above. With the switch to async PM ops in scsi in kernel 5.16, things broke > badly due to the lack of synchronization that sync PM provided before that. Yes, but without async PM ops, the IDENTIFY command that was not preceeded by a VERIFY worked just fine, right? > ACS defines that only media access commands can get a drive out of standby mode > back into active mode. So an IDENTIFY command would not (normally) > spinup a Right, it won't CAUSE the drive to spin up, but if it is already in the process of spinning up ( due to the reset ), then the drive will finish spinning up before answering the IDENTIFY command. Or do you think that some drives may handle the IDENTIFY wrong if they are still in the process of spinning up?
