power.sh must reapply laptop-mode settings after suspend

[Dan McGuirk]

If ENABLE_LAPTOP_MODE is set, power.sh applies hdparm settings when the power source is changed. The problem is, these settings do not stick across a suspend, and hence need to be reapplied after a suspend _even if the power source is the same_.

There is a workaround for the problem here:
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/89269/comments/18

but an official fix is needed.

[ethanay (ethan-y-us)]

whoops, I commented on [url=
"https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/89269"]bug 89269[/url] about this

see [url="https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/89269/comments/29"]comment 29 [/url]

please continue discussion here :)

[ethanay (ethan-y-us)]

for example, on unplugging from a power source, my hdparm settings are untouched from their current set, and the values in /etc/acpi/power.sh seem to be ignored.

[Dan McGuirk (incandenza)]

Well, remember, those only take effect if ENABLE_LAPTOP_MODE=true in /etc/default/acpi-support.

I don't really know whether the hdparm settings should be made from acpi-support or pm-utils, but either way, it seems someone needs to figure out once and for all where the settings should be made, and make sure it happens, even when waking from suspend.

[ethanay (ethan-y-us)]

my point is that enabling laptop mode in acpi-support may be unnecessary in the first place since pm-utils has its own hdd settings under /usr/lib/pm-utils/power.d/laptop-tools which are already called. if they are not being called correctly (e.g., startup/resume on battery power when poweroff/sleep was on ac) then that is a pm-utils bug.

so the current fix holds the potential of creating conflicting settings between acpi and pm-utils where the two overlap. i think it would be a cleaner "ugly" solution to stick with the pm-utils framework (which is more streamlined and less confusing, IMO) rather than creating potential conflict between the two.

[Dan McGuirk (incandenza)]

Well, /usr/lib/pm-utils/power.d/laptop-tools currently only sets settings in /proc/sys/vm, not the hdparm settings. Those settings will stick across a suspend, so there's really no bug there currently.

It may be that the hdparm calls should be moved from power.sh into pm-utils/power.d/laptop-tools, in which case the problem is transferred over there; now that script has to run after suspend and not just after a power change (which it didn't before).

Again, I have no opinion on where the solution should ultimately lie. I'm hoping the experts on the ins-and-outs of these scripts will be able to choose where the best fix should go (and reassign the bug to a different project if necessary).

[ethanay (ethan-y-us)]

I'd be curious to see if hdparm settings were added to the pm-utils/power.d/laptop-tools script whether it would persist over a sleep cycle. Either 1) Yes, like the other settings normally do or 2) No, because there is something else going on. In this second case, we haven't got to the source of the problem -- either 1) that something outside of acpi/pm-utils is resetting or over-riding hdparm after resume from sleep (suspend) where it is allowing the apm setting to persist over power state and power cycles (shutdown/boot and reboot) or 2) hdparm normally runs on all these occasions but doesn't seem to be recognizing sleep/resume. Either way, that seems to point to a problem OUTSIDE of acpi and pm-utils.

So there are two dynamics:
1) other acpi/pm-utils hdd settings that persist over sleep cycles
2) other changes in power state (ac/batt/shutdown) that either properly execute hdparm or leave the apm alone

I am definitely not an "expert" as mentioned above, and have no clue how to chase down the culprit

[ethanay (ethan-y-us)]

I suppose that if there are hdparm settings that are specifically executed for each change in power state , EXCEPT for sleep/resume, then it would directly be an acpi/pm-utils bug for simply not including those scripts.

[Dan McGuirk (incandenza)]

A setting that goes into /proc/sys/vm is just going into system memory, which of course is retained across a suspend. But the hdparm setting is only retained by the hard drive itself, and the hard drives that I'm familiar with seem to clear the setting when they wake from suspend.

I haven't tried moving the hdparm settings into power.d/laptop-tools yet, but I believe by virtue of being in the power.d directory that that script is only meant to be run on power state changes (which is correct given its current contents).

"I suppose that if there are hdparm settings that are specifically executed for each change in power state , EXCEPT for sleep/resume, then it would directly be an acpi/pm-utils bug for simply not including those scripts."

This seems to be the current situation, yes. Sleep/resume is not considered a "change in power state". So the hdparm settings in power.sh are pretty much useless, unless of course you never suspend at all.

[Arthur Archnix (arthur-archnix)]

I posted on the wrong bug, but then followed the link here.

Basically, I need to control hdparm because I have load/cycle issues. I also cannot enable laptop-mode because it causes hangs / freezing. I have followed the suse instructions for fixing up the load cycle issue here: http://en.opensuse.org/Disk_Power_Management

They work on bootup, and when I remove and insert power cord. But when I resume from suspend disk powermanagement is always 128. I either have to insert a plug or remove the plug to get it back on my desired hdparm settings.

Valentin's workaround did not work for me, but I think that's because I have not enabled laptop mode. If I can give more information please let me know.

[ethanay (ethan-y-us)]

Arthur -- I believe you are in the same boat I was in. Still waiting for a fix on this issue and also for the official hdparm decision. in the mean time, if you are running 8.04 and/or pm-utils, then the following post contained a fix which has worked for me so far as a temporary solution...

https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/273

It is the only thing which has worked so far. also, install hddtemp and check temperature after the laptop is warmed and working hard to make sure it doesn't cause heat issues.

[chourave (gaston72)]

I posted a comment related to this issue :
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/74394/comments/5

I'm not an expert but I thing the problem is in power.sh : it doesn't make the difference whether or not laptop-mode is installed (and enabled on ac or battery) and overwrite the hdparm settings.

[chourave (gaston72)]

see :

https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/74394/comments/8

for a solution : modified power.sh script

[Alexey Borzenkov (snaury)]

I've read a lot of comments that suggest crippling laptop-mode-tools even more than it already is. The problem is that laptop-mode-tools is the only place that DOESN'T HARDCODE VALUES. Why do I have to fight hardcoded values in /etc/acpi/power.sh and /usr/lib/pm-utils/power.d/laptop-tools to make my custom values in /etc/laptop-mode/laptop-mode.conf work?

I think it's bad to hardcode values. They should be editable in one way or the other, and editing system scripts (that could get "updated" later) is not good. So the way I see it laptop-mode-tools is the way to go. You should let it do what it can do. It already can handle apm power management, spindown times, and /proc/sys/vm/laptop_mode. Why hardcoding this functionality in other scripts when you could just come up with the same defaults in /etc/laptop-mode/laptop-mode.conf?

Please don't cripple laptop-mode-tools. Let it do its work instead.

[Alexey Borzenkov (snaury)]

Ooops. Wrong bug report. It was meant for bug #89269

[Tormod Volden (tormodvolden)]

I checked this in Karmic and it looks like hdparm -B is set twice at boot now:

/etc/S99acpi-support runs in order:
1. /etc/acpi/power.sh -> pm-powersave -> /usr/lib/pm-utils/power.d -> 95hdparm-apm
2. /etc/acpi/start.d/90-hdparm.sh

But /etc/acpi/power.sh will not run pm-powersave if it is called at a later point when gnome-power-manager etc is running. This is really complicated...

[Tormod Volden (tormodvolden)]

The original issue here is taken care of by /usr/lib/pm-utils/sleep.d/96laptop-mode or /usr/lib/pm-utils/sleep.d/95hdparm-apm now.