power.sh: wrong laptop_mode activation

Bug #89269 reported by Andrea Ratto on 2007-03-02
58
Affects Status Importance Assigned to Milestone
acpi-support (Ubuntu)
High
Unassigned
Hardy
High
Unassigned

Bug Description

Binary package hint: acpi-support

I have divided this report into five parts, the first one is a real bug which prevent correct functionality, the other are good things that could be achieved with little effort.

power.sh should be really reworked, here is why:
-------------ONE------------
in power.sh laptop mode is enabled in this way:
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
}
and disabled with a similar function.

now, I don't know about IDE devices, but on my Dell d620, (sata, intel ich7) the hard disk and the dvd show as
"/sys/bus/scsi/devices/0:0:0:0/block:sda" and "/sys/bus/scsi/devices/1:0:0:0/block:sr0".

So I think the script should be "for x in /sys/bus/scsi/devices/*/block*;"
This has fixed the problem on my laptop.
This seems to affect both Edgy and Feisty.
------------TWO-------------
Let laptop mode handle the disks or handle those directly?
As of now laptop mode provides a config file to many things that are done by acpi-support, for example controlling hd with hdparm.
I suggest that all those functionalities are disabled and hidden, leaving laptop mode to care only for sysctl and mount options.
For example as of now the user can have laptop_mode to set his hd spin down timeout to 10 seconds, but just after laptop mode power.sh sets the hd parameters itself, with a value that the uset can not customize.
Should be enough to cut some stuff away from the laptop_mode script and config files.
------------THREE-----------
Following from point two, hd parameters should be tunable by the user, and power.sh should not use "magic values". I suggest to put those somewhere else, maybe in /etc/default/acpi-support.
I know those aren't strictly related to acpi, but all powersaving is already being done by acpi-support.
-----------FOUR------------
When setting an hd aggressive power saving we should also set a longer readahead (hdparm -a 1024 or more)
------------FIVE-------------
It would also be interesting to set laptop_mode and disk powersaving when the lid is closed or let the user use the functions laptop_mode_enable and laptop_mode_disable in some custom scripts.
For this I suggest to move those function in /usr/share/acpi-support/power-funcs once everything else has been taken care of.

I am at disposal for anything you should need. Thanks for reading my report.

Related branches

Andrea Ratto (andrearatto) wrote :

I can confirm this bug it's present also in festy.

There is also another bug I just found, half in power.sh and half in the init script:

powersaving it's not activated on boot (on battery) if the laptop was shut down while on battery.

I will come up with some patches if I hear some noise about this bug !!!
I want this fixed in feisty :-)

Daniel Hahler (blueyed) wrote :

Thank you for your bug report. I feel sorry that it has been missed/ignored for so long.
I can confirm the first issue, too, using SATA devices and will look into getting this fixed for Hardy.

However, please file separate bug reports for the other issues, so they can be tracked separately, if they are not reported already.

Changed in acpi-support:
importance: Undecided → High
status: New → Triaged
Daniel Hahler (blueyed) on 2008-03-28
Changed in acpi-support:
milestone: none → ubuntu-8.04

I have a Dell Inspiron 6400/E1505 with Hardy Beta x86. The fix posted under ONE does work for me partially, meaning that the values in /etc/acpi/power.sh are set for the HDD when changing power states (going from battery to AC and vice-versa), but not when resuming from suspend/hibernate. I tested by adding a "touch /tmp/test-resume" to power.sh, and the file isn't created when resuming, meaning that power.sh isn't called when waking up.

I also agree with what Andrea Ratto said. I've been using Ubuntu on this laptop since Feisty and every new version has had the same problem. Fixing this would also help fix the dreaded HDD load cycle count bug that everyone has been talking about.

Daniel Holbach (dholbach) wrote :

Steve: can you please take a look at it?

Andrea Ratto (andrearatto) wrote :

Finally something is moving.

fixing point ONE does not really help the whole powermanagement subsytem, because there is still laptop-mode touching the disk parameters.

What's most importat of this bug is that things should make sense. acpi-support vs laptop-mode (vs powernowd). Which one touches what?
We can't have a disk standby timeout in laptop-mode.conf and another in /etc/default/acpi-support.
Also hdparm -B which is causing the famouse HDD load cycling bug is called by both of them. So I don't want to post 5 different bugs, for now.

I really think that canonical should put some money on this and get to be the best distro for laptops. That is what i think it's best:
Rewrite/fork laptop-mode to take out all the functionalities not relative to HDD powermanagement, call it something easier and give it a decent config file. Hook it in the acpi-support scripts, so that it does not have to watch for battery and other power related events. Ac get plugged in, we call xxx ac and it parses its config file and sets timeouts and caching/mount options. Resuming from standby? find if on ac or on battery and call it again... and so on. Acpi-support does the transitions from power states, other tools do the settings.

This would be just phase one. Then a daemon and some dbus communication with gnome-power-manager could provide things like power profiles (a profile is just a set of config files for the new laptop-mode and powernowd, plus some settings for the screensaver); an administrative application could help the user to set parameters. But these are just ideas, for now laptop mode and its integration with acpi-support need attention.

Steve Langasek (vorlon) wrote :

Daniel,

A bzr branch is not the most useful way to grab fixes when there's no main branch to merge it to - and when the cherrypick branch is missing various changes that have been uploaded to the archive. Can you please provide a standalone patch for this change, to apply against the current package?

Daniel Hahler (blueyed) wrote :

Steve, I've synced acpi-support 0.108 (the last release) to my branch in revision 5.

This particular fix is in revision 7 of the branch, so you can get it using:
bzr diff -c 7 http://bazaar.launchpad.net/~blueyed/acpi-support/cherry-pick

Besides, the fix is really quite simple, adding a "*" to the globs in laptop_mode_{enable|disable}.

I can create a separate debdiff for it, but I don't think that it's correct.

Andrea has said:
> fixing point ONE does not really help the whole powermanagement subsytem, because there is still laptop-mode touching the disk parameters.

Steve Langasek (vorlon) wrote :

Ok, thanks - it is of course non-trivial to tell just from a bzr log whether any of the other revisions might have somehow been related to that one, so I didn't want to cherry-pick your cherry-picks without clearer direction. :)

acpi-support 0.109 to be uploaded shortly, thank you for your contribution to Ubuntu as always!

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package acpi-support - 0.109

---------------
acpi-support (0.109) hardy; urgency=low

   [ Daniel Hahler ]
   * power.sh:
     Fix glob pattern for laptop_mode_{enable,disable}. It did not match any
     devices. Thanks Andrea Ratto. (LP: #89269)

 -- Steve Langasek <email address hidden> Mon, 14 Apr 2008 06:47:19 +0000

Changed in acpi-support:
status: Triaged → Fix Released
Tomas Pospisek (tpo-deb) wrote :

I'm sorry to nitpick, but does the last message in this issue (https://launchpad.net/ubuntu/+bug/89269/comments/9) mean that the bug is regarded as fixed? And all the other good and meaningful suggestions by Andrea are left behind?
*t

Steve Langasek (vorlon) wrote :

Sorry, we're currently in freeze for release which means only the most essential changes are going to be made. It would be best to file the other suggestions as separate bug reports, since there's no way to record this single bug report as both "open" and "closed" at once on a single package.

Bart Samwel (bart-samwel) wrote :

For those still reading this bug report, I would like to add my $0.02 to Andrea's suggestions. It's always been a bit of a mystery to me why Ubuntu handles laptop mode the way it does. All of the functionality (enabling/disabling based on battery/ac power, based on lid switch, hdparm settings handling etc.) has been present in laptop mode tools from the get-go. The reason for putting separate functionality in acpi-support to steer laptop-mode-tools has never been clear to me. And especially the choice of including the full laptop mode config file for which lots of the options simply don't work (because of the acpi-support override), without even a single note, has always been a mystery -- and one of the "crime scene investigation" types, as far as I'm concerned.

FWIW, in Debian I solved this by removing the acpi-support logic for laptop mode tools completely (I maintain the downstream acpi-support package in Debian). Nobody has ever complained about this, or asked for it to be re-added.

Disclaimer: I am also the maintainer of laptop-mode-tools, the Debian package as well as the "true" upstream. That probably makes me biased. :-)

Andrea Ratto (andrearatto) wrote :

>Bart Samwel:
>FWIW, in Debian I solved this by removing the acpi-support logic for laptop mode tools completely

That is the quick way to fix it, exactly what I have on my laptop.
Though I think that in the long run would be better to do it the other way around: remove enabling/disabling based on battery/ac power/lid from laptop_mode and let it just handle disks.

Since you are the mantainer of laptop_mode what do you think? Would not it simplify the laptop_mode code and config file a lot (no more need of enabled/disabled/allowed to run and stuff like that)? Would not it all be more flexible and coherent (on some laptops one could activate disk powersaving with a button, for examble)? Would it take much work or is it just a matter of deleting code here and there?

I am glad you are following this, just like I am the the first issue got fixed.

Download full text (3.4 KiB)

Hi Andrea,

Andrea Ratto wrote:
>> Bart Samwel:
>> FWIW, in Debian I solved this by removing the acpi-support logic for laptop mode tools completely
>
> That is the quick way to fix it, exactly what I have on my laptop.
> Though I think that in the long run would be better to do it the other way around: remove enabling/disabling based on battery/ac power/lid from laptop_mode and let it just handle disks.
>
> Since you are the mantainer of laptop_mode what do you think? Would not
> it simplify the laptop_mode code and config file a lot (no more need of
> enabled/disabled/allowed to run and stuff like that)? Would not it all
> be more flexible and coherent (on some laptops one could activate disk
> powersaving with a button, for examble)? Would it take much work or is
> it just a matter of deleting code here and there?

It would take _loads_ of work. In fact, laptop mode tools originally
worked like that (it had a start/stop parameter and was called from
various other acpi scripts), but we moved away from that for various
reasons. Here's a short summary:

* Laptop mode tools has very complex enable/disable logic. We have:
enable while on battery; enable while on AC (if so configured); enable
when the lid is closed (if so configured), regardless of being on AC or
battery; *disable* data loss sensitive features when the battery is
below a certain level; *disable* data loss sensitive features when the
battery reports that it is "critical".

* I tried to support this using external scripts, but it turned out that
I had to replicate the entire logical structure in all calling scripts.
For instance, if the lid is closed, but the battery is critical, laptop
mode should not be enabled. And if the lid is opened, and the computer
is on battery, then laptop mode should not be disabled. Eventually, I
just moved the logic into the core of laptop_mode, and just supported an
"auto" parameter which evaluated all the logic and applied state changes
if the result of the calculation was different from the last time.
Ubuntu's package is based on the Debian package, but reinstates the
start/stop parameters.

* Laptop mode tools started to support many more things than laptop_mode
processing, and that complicated matters. It's not simply a matter of
starting and stopping anymore -- it's more like, depending on the AC
state, loads of settings are tweaked. There is a clear distinction in
the current code base between the activating of power saving features,
and the activating of *data loss sensitive* power saving features.

All in all, I think the laptop mode tools framework is much more robust
than the acpi-support framework. Ubuntu's current start/stop logic is
very limited. It doesn't disable laptop mode when the battery goes
critical, which can cause data loss if the battery suddenly runs out. It
doesn't allow enabling laptop mode on AC. It doesn't support enabling
laptop mode when the lid is closed.

There's one other thing to consider: laptop mode doesn't have anything
to do with ACPI, so I've always asked myself what all this is doing in
acpi-support? Laptop mode tools works on APM machines and PowerPC Macs
as well, and supports...

Read more...

Andrea Ratto (andrearatto) wrote :

acpi-support does support running scripts on lid clode.
It does not notify a "battery critical" event though. Maybe that functionality could be added to acpid and thus to acpi-support? Does it require polling?

GNU/Linux, not just Ubuntu, needs one single framework for powermanagement, be that acpi, or HAL or laptop_mode, or whatever.
One framework with hooks for various programs is the way to go. I think we can agree on that, at least at design level. Do we?

Also a full powermanagement solution requires:
disk standby,
processor frequencies;
panel brightness,
services start/stop,
actions on critical battery level,
different configuration profiles,
etc...
...and we are far away from that:
gnome-power-preferences uses HAL, acpi-support uses acpid, laptop_mode does by itself, as well as other things. It's a real mess.

Bart Samwel (bart-samwel) wrote :

Hi Andrea,

Andrea Ratto wrote:
> acpi-support does support running scripts on lid clode.
> It does not notify a "battery critical" event though. Maybe that functionality could be added to acpid and thus to acpi-support? Does it require polling?

Laptop mode tools uses the acpi battery event to check for critical
battery levels. It then checks the acpi battery state, or the sysfs
battery state (depending on what's available).

> GNU/Linux, not just Ubuntu, needs one single framework for powermanagement, be that acpi, or HAL or laptop_mode, or whatever.
> One framework with hooks for various programs is the way to go. I think we can agree on that, at least at design level. Do we?

Yup. I was missing that when I built laptop mode tools, that's why I had
to "roll my own" for everything. It's become a pretty generic framework
for power state switches, but handles no other typical laptop tasks. In
my opinion, this is correct -- power management, making-laptops-work
stuff, and suspend/hibernate are too often confused (e.g. in
acpi-support :-) ). I think that power management policy is one thing,
making-laptops-work stuff is another, and suspend/hibernate is another
thing altogether. Trying to put all of that in one framework is a big
mistake.

> Also a full powermanagement solution requires:
> disk standby,
> processor frequencies;
> panel brightness,
> services start/stop,
> actions on critical battery level,
> different configuration profiles,

For good measure, laptop mode tools supports disk standby, processor
frequencies, panel brightness, services start/stop, and specific actions
on critical battery level (not generic though -- only disabling stuff
and automatic hibernation). Furthermore, it supports extension modules
with modular configuration files in /etc/laptop-mode/conf.d.

In addition, it currently supplies modules for:
* generically swizzling configuration files for daemons based on the
power state, and signalling programs / restarting services after
switching the configuration files.
* Power saving modes for Intel IPW and iwlwifi drivers.
* Power saving modes for Intel AC97 integrated audio.
* Terminal blanking
* X screen blanking timeouts (using DPMS)

I'm definitely not saying that laptop mode tools is the ideal power
management solution. But it can handle system-wide power management
policy pretty well.

> etc...
> ...and we are far away from that:
> gnome-power-preferences uses HAL, acpi-support uses acpid, laptop_mode does by itself, as well as other things. It's a real mess.

In fact, laptop mode tools also uses acpid. The way I see it, laptop
mode tools and acpi-support are complementary: acpi-support makes
laptops work, laptop mode tools implements power management policy at
the system-wide level. Gnome power manager does it at the user level,
and this may sometimes conflict with what laptop mode tools does. The
fact that acpi-support tries to control laptop mode tools is the weird
thing that makes the acpi-support/laptop mode tools combination look a
bit messy -- it's not its core task, and IMHO it's not surprising that
it does a pretty bad job at it.

Cheers,
Bart

Dan McGuirk (incandenza) wrote :

Sorry, I'm not really up to speed on the issues here, but I have the same problem Valentin Neacsu mentions above: the 'hdparm -B 255' command is not run when waking up from suspend, which is necessary on my machine.

My previous workaround solution to this problem was to put a script in /etc/acpi/resume.d, but that no longer works, either.

It does seem that the power.sh script runs, so maybe it just looks and says, OK, I'm in the same state, the hdparm commands are not necessary. On my system that is not true; it needs to run those commands on wake from suspend even if it's in the same state as before.

Thanks for any help.

As a workaround for that bug I have done this:

1. open up a terminal window
2. cd /usr/lib/pm-utils/sleep.d
3. sudo gedit 99-power-state-fix.sh
4. paste this:

#!/bin/bash
/usr/bin/on_ac_power
if [ "$?" -eq 0 ]; then
 echo "BATTERY" > /var/lib/acpi-support/powerstate
 /etc/acpi/power.sh ac_adapter
else
 if [ "$?" -eq 1 ]; then
  echo "AC" > /var/lib/acpi-support/powerstate
  /etc/acpi/power.sh battery
 fi
fi

5. save & close
6. chmod 755 99-power-state-fix.sh

What this does is trick the power.sh file into thinking the power state has changed and forces it to recheck everything and run what's needed for this 'new' power state. It's just an ugly fix for a bigger problem and I'd rather have this fixed.

Dan McGuirk (incandenza) wrote :

Hmm, that workaround still does not make the hdparm settings take effect for me. My solution for that is just to hardcode the hdparm calls at the beginning of power.sh (since I always want it this way anyway).

It does make anacron run when it normally wouldn't, though.

Dan McGuirk (incandenza) wrote :

Oops, never mind, I forgot to reenable ENABLE_LAPTOP_MODE. With that, the posted workaround works.

Thanks for the help.

ethanay (ethan-y-us) wrote :

Dan, I might be in a similar boat. Can you go into greater detail how you got the fix to apply hdparm settings after resume?

Dan McGuirk (incandenza) wrote :

All I did was follow Valentin's exact steps above. Then I made sure that ENABLE_LAPTOP_MODE was set to 'true' in /etc/default/acpi-support. That was all that was needed for me.

The hdparm commands are already in /etc/acpi/power.sh; they were just not being executed at the needed time, for me. If it still doesn't work, maybe try putting some debug echos in power.sh and see what is happening there.

ethanay (ethan-y-us) wrote :

I followed Valentin Neacsu's instructions, and it works for me. Is /etc/acpi/power.sh the only script to contain the relevant hdparm settings (i.e., overriding laptop_mode.conf settings and the /etc/pm/config.d/disk)? In the process of figuring this whole thing out, I've set every hdparm parameter I could find to 254 and would like to know which ones still have effect.

Changed in dell:
status: New → Invalid

I have put this bug into the Dell project, and they have rejected has "invalid". Does anybody here knows why?
I have this problem on a Dell m1330, and I know that at least ethanay has the same computer and same problems as mine.

Andrea Ratto (andrearatto) wrote :

Dell too here.
Every transition in a bug state should have a mandatory comment.... I guess it means that Dell does not care for this issue.

Mario Limonciello (superm1) wrote :

Andrea,

it's not that Dell doesn't care about the issue, but it's not an issue specific to the 1330 that will be corrected by Dell and such not tracked. If you are still having this bug, open back up the Ubuntu task.

Dan McGuirk (incandenza) wrote :

It seems there still needs to be an official fix for the problem that Valentin Neacsu's workaround solves. Should this bug be reopened, or would it be better to open a new one?

Dan McGuirk (incandenza) wrote :

I opened bug 229693 to describe the remaining problem. If that is not appropriate, I'm sure someone can correct.

Thanks...

ethanay (ethan-y-us) wrote :

m1330 on Hardy w/latest

after a clean reinstall, my computer is indicating that pm-utils is handling sleep and resume scripts. As well, it is setting a "laptop-mode" hard-drive state via settings in /usr/lib/pm-utils/power.d/laptop-tools on power state change even though "enable laptop mode" in /etc/default/acpi-support is "false." Further, putting simple hdparm - B scripts in /etc/pm/x.d/ works where it doesn't in /etc/acpi/x.d/ . If this is true, then wouldn't the fix called above and enabling laptop mode tools either be ineffective or put pm-utils and acpi-support in conflict with one-another?

One workaround might be simply to change Valentin Neacsu's script to link to pm-utils locations instead of acpi locations where necessary. Can someone please explain the steps to reproduce this problem? I am unclear since learning that power management actually seems to be occurring via pm-utils vs acpi by default -- at least on my machine. That would explain why putting ugly fixes in /etc/acpi/x.d/ doesn't work.

ethanay (ethan-y-us) wrote :

whoops...please continue discussion at bug 229693

I've applied the suse fix for load/cycle problems under hardy, which sets hdparm to 254 when on ac and 200 when on battery. Works fine on boot. But when resuming from suspend I have to unplug the cord, or plug in the cord, in order to get hdparm to use one of those two values. It always starts back up from suspend with a value of 128.

Valentin's 99-fix did not work, but I laptopmode is disabled on my laptop because it causes hangs/freezes. If I can supply more info to help the bug along please ask.

Sorry, I messed up too. That comment probably doesn't belong here. I've followed ethany's link to the continuing discussion.

chourave (gaston72) wrote :

Thank's fo your script Valentin, it works for me, but only after a modification of power.sh :

Actually, the power.sh script is buggy : the script doesn't really call laptop-mode (/usr/sbin/laptop_mode) but it calls internal functions defined at the beginning of the script...and thus laptop-mode.conf are not applied...

I posted a solution (modified power.sh), which solve the same problem (laptop-mode not really enabled) after switching AC/battery power supply

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

I also recall valentin's solution for the suspend/resume on the same bug.

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

Alexey Borzenkov (snaury) wrote :

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.

Changed in somerville:
status: New → Invalid
no longer affects: dell
Timothy R. Chavez (timrchavez) wrote :

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305976

no longer affects: somerville
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers