Description of problem: The kernel can cluster IO to reduce hard drive spin-ups, intended to help save battery power in laptops. This is activated by putting a nonzero value in /proc/sys/vm/laptop_mode. Kernel documentation recommends a value of 5 (for five seconds). Unfortunately, the pm-utils power saving infrastructure does not use this feature. That probably means we're not saving as much laptop battery power as as we could be. Version-Release number of selected component (if applicable): pm-utils-0.99.4-6.fc8 How reproducible: 100% reproducible Steps to Reproduce: 1. Unplug a laptop from AC power. 2. cat /proc/sys/vm/laptop_mode Actual results: "0" in /proc/sys/vm/laptop_mode, indicating that the kernel is not in laptop mode. Expected results: Some nonzero value in /proc/sys/vm/laptop_mode, indicating that the kernel is in laptop mode. Additional info: This could be solved by packaging up laptop-mode-tools as an RPM and then hooking its scripts up using /usr/lib/pm-utils/power.d. The upstream developer already packages laptop-mode-tools for Fedora, which should at least be a nice start: <http://samwel.tk/laptop_mode/packages/fedora>. The /usr/lib/pm-utils/power.d hook script can be as simple as running a single command: "/usr/sbin/laptop_mode auto". On the other hand, the current laptop-mode-tools is modular and can do severl other things besides just tweaking /proc/sys/vm/laptop_mode. It changes mount options, can adjust the backlight, etc. Perhaps some of these actions ought to be the responsibility of other new pm-utils's powersave scripts directly rather than delegating them through laptop-mode-tools. At a bare minimum, pm-utils could ignore laptop-mode-tools entirely and simply "echo 5 >/proc/sys/vm/laptop_mode" when enabling power saving and "echo 0 >/proc/sys/vm/laptop_mode" when disabling it.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
pm-utils itself can't do it as it doesn't have a daemon. This needs to either happen in acpid or in the hal-addon-acpi. I'm reassigning this to acpid for now.
(In reply to comment #2) > pm-utils itself can't do it as it doesn't have a daemon. This needs to either > happen in acpid or in the hal-addon-acpi. > > I'm reassigning this to acpid for now. I am pretty sure that this can be done like the reporter described it in the initial comment, i.e. put some script into /usr/lib/pm-utils/power.d. But probably this script should be provided by laptop-mode-utils, once it is packaged. The current architecture is afaics somehow like this: 1) acpid or hal make gnome-power-manager aware of running on battery or a/c 2) gnome-power-manager uses dbus/hal to run pm-powersave 3) pm-powersave runs the power.d hooks Probably the proper assignment would be distribution, because it needs to be implemented in a package that yet needs to be imported into Fedora.
Hello, although acpid can do this, rpm never contains such things. There are several reasons for that. Scripts for acpid are always written by users. The behaviour is like this: When acpi event occurs, acpid executes a script, hal-addon-acpi simply sends a message to DBus. Futher, I'm quite sure that acpid rpm will not contains a script for laptop_mode setting in future. I'm reassigning this to gnome-power-manager, which listens on DBus and reacts on these kind of messages(acpi events), so the maintainer can add his comments.
There is nothing to triage here. Switching to ASSIGNED so that developers have responsibility to do whatever they want to do with it.
I'd actually lean towards saying that laptop-mode should always be enabled, but it has the unfortunate behaviour that it will trigger syncing of all devices when it decides to flush dirty blocks - rather than just the device which has reached the appropriate timeout. This is due to there not being a terribly good interface in the kernel to handle syncing an individual device. I'll look into that. (Note that "laptop-mode" is a poor name for this feature. It's actually a tunable that affects how long the kernel will buffer data before flushing it)
Closing this dead bug now laptop_mode is even dead in pm-utils.