Re: [PATCH v6 05/23] ata: libata-scsi: Disable scsi device manage_system_start_stop

[Phillip Susi <phill@thesusis.net>]

Damien Le Moal <dlemoal@kernel.org> writes:

> However, restoring the ATA device to the active power mode must be
> synchronized with libata EH processing of the port resume operation to
> avoid either 1) seeing the start stop unit command being received too
> early when the port is not yet resumed and ready to accept commands, or
> after the port resume process issues commands such as IDENTIFY to

I do not believe this is correct.  The drive must respond to IDENTIFY
and SET FEATURES while in standby mode.  Some of the information in the
IDENTIFY block may be flagged as not available because it requires media
access and the drive is in standby.  There is a bit in the IDENTIFY
block that indicates whether the drive will automatically spin up for
media access commands or not, and if not, then you must issue the SET
FEATURES command to spin it up.  For such drives, that VERIFY command
will fail.

> revalidate the device. In this last case, the risk is that the device
> revalidation fails with timeout errors as the drive is still spun down.

If a request can timeout before the drive has time to spin up, then that
would be a problem outside of suspend/resume.  You would get such
timeouts any time you manually suspend the drive with hdparm -y, or the
drive auto suspends ( hdparm -S ).  The timeout needs to be long enough
for the drive to spin up.  IIRC, it defaults to 10 seconds, which is
plenty of time.


It sounds like you are saying that you unconditionally wake the drive
with a VERIFY command to make sure that you can then IDENTIFY.  This
should not be needed.  In addition, if the drive has PuiS enabled, I
would like to leave it in standby after a system resume, not force it to
wake up.  After all, that is why it has PuiS enabled.