power management scripts should respect hdparm.conf

[nglnx]

On Ubuntu Feisty, there are several power management scripts that do not honor what the user might have defined in hdparm.conf.

For instance, in my case, my hardrive had a factory setting for the hard drive head parking that was too agressive. So I resorted to hdparm.conf:

dev/sda {
        apm = 224
}

and used update-rc.d hdparm defaults to apply those settings at boot. Since I also use laptop-mode, I was also carefull enough to specify CONTROL_HD_POWERMGMT=0 in /etc/laptop-mode/laptop-mode.conf so that laptop-mode can respect my hdparm settings

But I began noticing that after a suspend or hibernation, these settings were no longer being used. After some researching I discovered that the script /etc/power.sh had the following lines:

function laptop_mode_enable {
    $LAPTOP_MODE start

    for x in /sys/bus/ide/devices/*/block; do
       drive=$(basename $(readlink $x));
       $HDPARM -S 12 /dev/$drive 2>/dev/null
       $HDPARM -B 1 /dev/$drive 2>/dev/null
    done

    for x in /sys/bus/scsi/devices/*/block; do
       drive=$(basename $(readlink $x));
       $HDPARM -S 12 /dev/$drive 2>/dev/null
       $HDPARM -B 1 /dev/$drive 2>/dev/null
    done
}

function laptop_mode_disable {
   for x in /sys/bus/ide/devices/*/block; do
       drive=$(basename $(readlink $x));
       $HDPARM -S 0 /dev/$drive 2>/dev/null
       $HDPARM -B 255 /dev/$drive 2>/dev/null
    done
    for x in /sys/bus/scsi/devices/*/block; do
       drive=$(basename $(readlink $x));
       $HDPARM -S 0 /dev/$drive 2>/dev/null
       $HDPARM -B 255 /dev/$drive 2>/dev/null
    done
    $LAPTOP_MODE stop
}

This is inconsistent behavior, because this script decides unilaterally on hdparm settings (which by the way are too aggressive, at least for my hd), without honoring the laptop-mode and hdparm configurations.

To solve my problem I simply removed the hdparm commands from power.sh and all was well again. But I should not have to do this.

There are other scripts that also do not respect hdparm.conf. For instance a simple grep hdparm /usr/share/python-support/kde-guidance/powermanage.py shows:

cmd = "hdparm -B1 /dev/"+disk+" > /dev/null"
cmd = "hdparm -B255 /dev/"+disk+" > /dev/null"

Once again it is using hardcoded hdparm settings instead of relying on hdparm.conf. But since this script has not given me any problem I have not inspected it further to see if power-guidance has a legit reason to behave this way.

Sorry if I was not clear in my explanation. Thank you reading my bug report.

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in recently. We were wondering if this is still an issue for you? Thanks in advance.

[nglnx (nglnx)]

Yes it is still an issue in Gutsy. I haven't tried it in Hardy

[Brian Murray (brian-murray)]

This still seems to be an issue on Hardy Heron based on my understanding of the files in acpi-support package version 0.105.

[Alvaro Kuolas (kuolas)]

I'm using Hardy Alpha6 and there's no /etc/power.sh

On /etc/laptop-mode/laptop-mode.conf says:

#
# Should laptop mode tools control the hard drive power management settings?
#
CONTROL_HD_POWERMGMT=0

#
# Power management for HD (hdparm -B values)
#
BATT_HD_POWERMGMT=1
LM_AC_HD_POWERMGMT=254
NOLM_AC_HD_POWERMGMT=254

And hdparm.conf says nothing.

It seems that the defaul behaviour is the hard drive default on Hardy.

[Alvaro Kuolas (kuolas)]

But...

in /etc/acpi/power.sh

function laptop_mode_enable {
    $LAPTOP_MODE start

    for x in /sys/bus/ide/devices/*/block; do
 drive=$(basename $(readlink $x));
 $HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null
 $HDPARM -B 1 /dev/$drive 2>/dev/null
    done

    for x in /sys/bus/scsi/devices/*/block; do
 drive=$(basename $(readlink $x));
 $HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null
 $HDPARM -B 1 /dev/$drive 2>/dev/null
    done
}

[Alvaro Kuolas (kuolas)]

And again (Sorry!)

http://ubuntudemon.wordpress.com/2007/10/26/laptop-hardrive-killer-bug/

"because ENABLE_LAPTOP_MODE is false in the default install (check /etc/default/acpi-support). This means that, by default, we do not alter the hard drive power settings. In other words, the APM settings that your drive is using in Ubuntu are the ones that your BIOS programmed into it when the computer started. This is supported by the fact that people see this issue after resuming from suspend. We don’t touch the hard drive settings at that point, so the only way it can occur is if your BIOS or drive default to this behaviour."

[nglnx (nglnx)]

As i have said in that blog, the issue was not new when it was blogged by him, since launchpad contains many unanswered bug reports that largely predate those blog posts. But he had the merit of centralizing available information in one location and thus attracting a large audience to help solve hard drive power management problems in Ubuntu. Kudos to him for his effort.

I can sympathize with respecting BIOS / drive default behavior whenever possible. However, if you look closely this script does not honor the *bios* or *user specified configurations*.

As I have said before, here we have a script that decides unilaterally on hdparm settings (which by the way are too aggressive) without honoring the laptop-mode and hdparm configurations.

The fact that ENABLE_LAPTOP_MODE is not enabled by default can't be seen as an excuse not to address this script's behavior because there are many users that will enable laptop mode at some moment after initial instalation.

Also, more savy users will want to adjust hdparm.conf to their specific hardware and won't appreciate this script's behavior.

This script should check hdparm.conf (as it is the main configuration for hdparm related stuff) and then laptop-mode.conf (if laptop mode is enabled) to check if the user has special requirements for hard drive. If it finds something on those configs, honor them. If not, respect BIOS settings. But never resort to an hardcoded value inside a script. It is, IMHO, a bad practice.

[Adrien Massy (admas)]

I agree with nglnx,

After suspend or resume, my settings in /etc/laptop-mode/laptop-mode.conf are lost.

Even if ENABLE_LAPTOP_MODE is set to false in /etc/default/acpi-support, this scripts simply stops laptop-mode after setting aggressive parameters in Hdparm, not taking into account the way the user wants laptop-mode to be started or not in laptop-mode.conf.

Same goes with ENABLE_LAPTOP_MODE set to true, as in this case it is started *before* changing settings with Hdparm, thus overwriting the user configuration.

I've set laptop-mode the way I like, partly to avoid the famous "bug" of the increasing HDD Load Cycles count, and this script breaks everything.

We really need more coherent power management in Ubuntu, for this kind of script makes it very tricky to set system preferences for sure (this goes also for screen power saving by the way) and can be a source of much confusion for many users.

[Valentin Neacsu (valentin.neacsu)]

I've found that commenting the lines in /etc/acpi/power.sh is not enough since when resuming from suspend I see a power management level of 0x80 (128), which differs from what I've set in /etc/laptop-mode/laptop-mode.conf. This does not happen when resuming from hibernate, so the scripts called when resuming from suspend also has a hard coded power management level for the HDD (hdparm -B). Does anyone know what scripts are called when resuming from suspend? BTW, I'm running Hardy Beta.

[David Santamaría Rogado (howl)]

Read my comment here: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/318980/comments/8

[Steve Langasek (vorlon)]

This has been resolved for karmic and above, because acpi-support no longer calls hdparm and pm-utils honors the contents of /etc/hdparm.conf.

[David Santamaría Rogado (howl)]

So then as I said the term LTS in ubuntu releases are only three letter to make the release name more longer. Also Jaunty is already supported. And also, this bug was reported with Feisty, well is compressible that if the next versions support date if off and a fix haven't released at time, they not get fixed but Hardy and Jaunty? The best is to say this is resolved for karmic and above, today, karmic is in beta state and no officially released, so translating you to "Simple English, users we (or the ones who did the ubuntu's support convection) lied to you, our support only exists for "in developing state" versions, all our released version have no support at all. Ah and the LTS is just to make it cooler :)"