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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Damien Le Moal <dlemoal@xxxxxxxxxx> writes:

> However, regarding the SET FEATURES command to spin up the drive, you are
> confusing the basic power management (STANDBY IMMEDIATE command support), which
> is a mandatory feature of ATA disks, with the Extended Power Conditions (EPC)
> feature set, which is optional. The latter one defines the behavior of the SET
> FEATURES command with the Extended Power Conditions subcommand to control the
> disk power state and power state transitions timers. The former, basic power
> management, does NOT have this. So trying what you suggest would only work for
> drives that support and enable EPC. Given that EPC is optional, and that we are
> not probing/supporting it currently in libata, we cannot rely on that.

I'm talking about PuiS.  At least with my 10 year old WD 1 TB blue
drives, if I enable PuiS, the drive will not spin up if you give it a
READ or VERIFY command, you have to give it the SET FEATURES command.
The kernel currently does this when it sees the drive requires it.

> That already is all taken care of. That is the basics for even the initial scan
> on boot where we send commands to the disk while it is still spinning up. The
> timeout I am mentioning is the drive not responding at all because it is spun
> down, no matter how many times one retries. And given that the ATA specs clearly
> define that a drive should not change its power state with a reset, even the
> reset after the command timeout does not change anything with some drives (I do
> have some drives that actually spin up on reset, but many that don't, as per spec).

I believe the idea of "reset" here within the context of the ATA spec is
the reset bit in the ATA TaskFile, not a hardware reset, or even an SATA
link reset.  Those genereally DO spin up the disk unless it has PuiS enabled.

> Exactly. As you said yourself, there are some drives that will not report
> everything unless they are spun up. And I have some old drives that really do
> not like receiving that command at all while spun down. So the safer approach
> taken is to spinup the drive upfront, before doing anything else.

I'd prefer to be able to avoid spinning up disks on system resume, but
my point was that if you want it to spin up, a VERIFY command might not
work.  For some drives with PuiS enabled, you have to use the SET
FEATURES command to spin it up.

> PUIS is another optional feature that we do not directly support in the kernel.
> If you want/need that, patches are welcome. With detection of that feature
> added, we could improve resume and avoid useless drive spinup. That is currently
> outside the scope of this series since we are not supporting PUIS currently.

The kernel at least currently issues the SET FEATURE command to wake a
drive with PuiS enabled, if it says that it needs that.  I hope this
patch series does not break that.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux