spindown settings lost on pm-suspend indirectly affects powernap power savings

Bug #738757 reported by heckheck
This bug affects 3 people
Affects Status Importance Assigned to Milestone
hdparm (Ubuntu)
Fix Released
Martin Pitt
pm-utils (Ubuntu)

Bug Description

Binary package hint: hdparm

Upon wakeup from pm-suspend, all spindown settings on drives as set in hdparm.conf are lost and drives will not spindown until reboot.

This will affect the performance of such useful packages such as powernap, since drives will not enter spindown after the first time a system is suspended and then resumed. Power will be wasted, watts that could be saved will be lost!!!

Upon investigation I found that a similar problem has been found and fixed for APM settings by use of the script /usr/lib/pm-utils/power.d/95hdparm-apm, which restores '-B' APM hdparm settings on capable drives following power events if laptop-mode-tools are not installed.

Since laptop-mode-tools is not a suitable package for a server environment, it is important the hdparm provide a similar script for spindown. Indeed, hdparms has already set the precedent that it should provide such backstop functionality as part of the package to support pm-utils functionality for critical drive parameters.

I have prepared a patch file that is more or less a clone of the script used for the APM functionality, but which restores the '-S' spindown hdparm parameters. I suggest that it be placed in /usr/lib/pm-utils/sleep.d/95hdparm-spindown. I kept the hdparm-try-apm test so that it will not apply to USB or firewire drives, and also kept the logic so that is applied only on drives that support APM (figured that test wouldn't hurt and might be important). I assumed it would not apply in pm-powersave and so moved it from power.d/ to sleep.d/.

As a side note, I also have a patch I am submitting to powernap to extend functionality to add a monitor plugin that will key off drive standby/sleep state. The patch will only work, however, if the drives spindown more than once per boot...

Related branches

Revision history for this message
heckheck (jinfo) wrote :
tags: added: patch
Martin Pitt (pitti)
Changed in pm-utils (Ubuntu):
status: New → Invalid
Revision history for this message
Martin Pitt (pitti) wrote :

(This should be fixed in hdparm, closing pm-utils task).

Thanks heckneck for this report!

So essentially your script changes two things:

  * It runs at suspend/resume time instead of when changing AC <-> Battery (by being placed into suspend.d instead of power.d)
     I agree that this should be fixed, and the existing /usr/lib/pm-utils/power.d/95hdparm-apm even supports being called as suspend.d already. I'm happy to add a symlink to suspend.d/ to this.

  * It adds handling of the -S option from /etc/hdparm.conf. We don't specify one by default, so adding support for this sounds safe, as it won't change default behaviour.

However, don't think we should handle -S only for the power.d script and -B only for suspend, but both in both modes.

Changed in hdparm (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: New → Triaged
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hdparm - 9.32-1ubuntu2

hdparm (9.32-1ubuntu2) natty; urgency=low

  * debian/95hdparm-apm: Also handle -S option from /etc/hdparm.conf. (side
    issue in LP #738757).
  * debian/rules: Install a suspend.d symlink to also call the pm-utils hook
    on resuming. (LP: #738757)
 -- Martin Pitt <email address hidden> Thu, 24 Mar 2011 22:49:48 +0100

Changed in hdparm (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
heckheck (jinfo) wrote :

I have done more testing with the patch released in hdparm (9.32-1ubuntu2) and found that there are some problems with the approach taken. I think this bug should be marked FIXED-FAILED and revisited.

By adding the hdparm -S parameter handling to the power.d script for 'true' and 'false' power.d events in addition to the 'thaw' and 'resume' events proposed in the original patch, a side effect has now been introduced. The drive will now be awakened from standby state for every power event transition ('true' and 'false') so that the hdparm -S command can be applied.

This is undesirable from several perspectives. First, and foremost, it wakes a sleeping drive to submit a command that affects how long the drive should wait before going to sleep. When the drive goes to sleep again, that parameter will be lost, so waking it to tell it that serves no positive purpose.

Unlike the -B apm parameter modification, the -S parameter should not be modified on both a 'true' and 'false' power event, since there is no side benefit to changing the -S parameter when entering or exiting powersave mode for a drive that is still awake, since it will already have the -S parameter from the hdparm.conf file currently applied. The -S parameter is static in the hdparm.conf file and should have been applied at power on, or when it last came back from standby or sleep on a 'resume' or 'thaw' event.

Another undesired consequence of applying the hdparm -S command in the power.d script is that it creates an incompatibility in the powernap utility with using the powersave ACTION mode in conjunction with the DiskMonitor plugin I have proposed https://code.launchpad.net/~jinfo/powernap/trunk. This is due to the fact that if the DiskMonitor is monitoring a drive to detect the standby/sleep state, and then subsequently tries to execute pm-powersave command, the drive will be awoken by the power.d script, which tries to apply the hdparm -S command to the drive that is in standby or sleeping, thus awakening it, and causing an invalidation of the conditions to enter low power mode (e.g. the drive is now awake).

Indeed, from my testing it seems as if even issuing a pm-suspend causes the 'true' condition of the power.d script to be triggered, as I am seeing sleeping drives awoken when I issue pm-suspend prior to the system going into standby. So the drives are awoken, given the new hdparm -S command and then the system enters standby where the drives are again immediately put back into standby, not good.

In my opinion, my original patch is the more correct handling of the loss of hdparm -S (spindown) settings within pm-utils. The reapplication of these settings should only be done from within the sleep.d script for 'resume' and 'thaw' events. Upon reawakening from sleep or standby are the only times the drive would have "lost" the settings contained in hdparm.conf.

Please reconsider using the original patch.

Best Regards,

-Jim Heck

Revision history for this message
Martin Pitt (pitti) wrote :

Ah, thanks for the details. The -S part is the second point in comment 2. It seems to me that /lib/udev/rules.d/85-hdparm.rules already applies *all* the settings (i. e. including -S) from hdparm.conf, so that should work on at least boot and probably also hibernate.

So I'll modify this to be more closely to your original proposal.

Changed in hdparm (Ubuntu):
status: Fix Released → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :

I factored out the laptop-mode test, and use two separate functions for -B and -S now:



Changed in hdparm (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hdparm - 9.32-1ubuntu3

hdparm (9.32-1ubuntu3) natty; urgency=low

  * debian/95hdparm-apm: Handle powersaving and suspend separately, and only
    apply -S settings on resuming, not on powersaving events. Thanks heckheck!
    (LP: #738757)
 -- Martin Pitt <email address hidden> Thu, 31 Mar 2011 18:03:03 +0200

Changed in hdparm (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Bazon (bazonbloch) wrote :

I have an at least similar issue on 12.10 quantal:
 I want to spin down my external USB drive /dev/sdc as fast as possible:
in /etc/hdparm.conf:

/dev/sdc {
 spindown_time = 1

that works, although I get

$ sudo hdparm -C /dev/sdc
SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 40 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 drive state is: unknown

but after resume from suspend, it doesn't work anymore.

my workaround is

case "$1" in
  hdparm -S 1 /dev/sdc


and that works, anyway, spindown settings shouldn't get lost on suspend/resume in the first place.

So what is most reasonable?
 * Reopen this bug?
 * Deal with that issue in the similar and open bug https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/199094 ?
 * Open a new bug?

Revision history for this message
Andres Rodriguez (andreserl) wrote :

Hi Bazon,

Sorry for such a late reply.

If the spindown settings are getting lost on suspend/resume, this is probably a bug that should be handled in hdparm or maybe pm-utils. I think you should file a new bug report.


Revision history for this message
Adam Felson (adam-ubuntu) wrote :

This is still broken (or broken again) in 16.04.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers