Red Hat Bugzilla – Bug 427122
RFE: enter laptop_mode when saving power
Last modified: 2018-04-11 11:33:43 EDT
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
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):
Steps to Reproduce:
1. Unplug a laptop from AC power.
2. cat /proc/sys/vm/laptop_mode
"0" in /proc/sys/vm/laptop_mode, indicating that the kernel is not in laptop mode.
Some nonzero value in /proc/sys/vm/laptop_mode, indicating that the kernel is in
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:
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.
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.