If you have a relatively recent x86 laptop, odds are it supports either Advanced Power Management (APM) or Advanced Configuration and Power Interface (ACPI). ACPI is the newer of the two technologies and puts power management in the hands of the operating system, allowing for more intelligent power management than is possible with BIOS controlled APM. This is most useful for battery-powered laptops. You can only have one power management interface in control of your machine at a time, so it's important you decide which method best suits your situation.
Advanced Power Management (APM) allows your computer's BIOS to control your system's power management without the knowledge of the operating system. The advantages to APM under Linux are that it's stable, well supported by Linux vendors and has a solid history behind it. However, not much development has been done with it over the past few years.
To use it, you'll need to enable APM in the kernel. Most of the other APM options exist as work-arounds for known problems with specific hardware devices, so you'll probably only want to enable the first one (CONFIG_APM).
Advanced Power Management BIOS support (CONFIG_APM): You'll need to enable this in order to do anything useful with APM. User-space programs will receive notification of APM events (e.g., battery status change) and a /proc/apm device will provide you with battery status information.
Ignore USER SUSPEND (CONFIG_APM_IGNORE_USER_SUSPEND): This is a workaround for NEC Versa M notebooks.
Enable PM at boot time (CONFIG_APM_DO_ENABLE): Although it sounds nifty, most machines do not require this feature to be enabled and in fact can hang some systems at boot time.
Make CPU Idle calls when idle (CONFIG_APM_CPU_IDLE): On some machines, this option provides increased power savings. On others, it will hang the system at boot time. Use with caution.
Enable console blanking using APM (CONFIG_APM_DISPLAY_BLANK): Instead of blanking the virtual console actually turn off the screen. This won't work with X-Windows and actually can cause more problems that it solves.
RTC stores time in GMT (CONFIG_APM_RTC_IS_GMT): If you want to store GMT (Greenwich Mean Time) in your RTC (Real Time Clock), say yes here.
Allow interrupts during APM BIOS calls (CONFIG_APM_ALLOW_INTS): This is a workaround for some IBM Thinkpads that hang while suspending.
Use real mode APM BIOS call to power off (CONFIG_APM_REAL_MODE_POWER_OFF): This is a workaround for a number of broken BIOSes. If your computer crashes instead of powering off properly, turn this on.
You'll want to install the APM daemon from http://www.worldvisions.ca/~apenwarr/apmd/ and configure your system startup scripts to activate it on boot:
# Start the APM daemon if APM is enabled in the kernel if [ -x /usr/sbin/apmd -a -d /proc/apm ]; then if cat /proc/apm 1> /dev/null 2> /dev/null ; then echo "Starting APM daemon: /usr/sbin/apmd" /usr/sbin/apmd fi fi |
The APM daemon is actually made up of three primary programs:
apmd - handles power management tasks
apm - a command-line tool to print the current battery status or suspend the computer
xapm - a simple battery meter for X
If you're looking for a simple, "works out of the box" approach to power management for your Laptop, APM is definitely the way to go.
Advanced Configuration and Power Interface (ACPI) is the successor to APM, which places the responsibility of power management away from the BIOS and into the hands of the operating system. ACPI Linux is newer than APM Linux, more flexible in responding to power management events, has seen much more development as of late, and as a result of all this is prone to its own share of bugs from time to time.
If you're into cutting-edge development and are not intimidated with kernel builds and applying patches against source code, ACPI is worth consideration.
There are two parts to ACPI under Linux: The ACPI driver built into the kernel itself, and the ACPI daemon (ACPID). ACPID in its current incarnation is pretty simple: monitor /proc/acpi/event and do things in response. Even if you don't load the daemon, you'll still get the benefit of ACPI features built into the kernel such as processor thermal support.
You can determine which version of the ACPI driver you are using, along with supported suspend states, by using:
bash $ cat /proc/acpi/info version: 20030619 states: S0 S1 S3 S4 S4Bios S5 |
ACPI development is progressing at a steady rate, so you might want to consider patching your kernel against any recent updates to the kernel-level ACPI code. Once you have downloaded the patch for your specific kernel, you can patch it with something like:
bash$ gunzip acpi-[version]-[kernel].diff.gz bash# mv acpi-[version]-[kernel].diff /usr/src/linux-[version] bash# cd /usr/src/linux-[version] bash# patch -p1 < acpi-[version]-[kernel].diff |
You'll want to recompile your kernel after this, of course.
You'll also want to install the ACPID daemon from http://sourceforge.net/project/showfiles.php?group_id=33140 and configure your system startup scripts to activate it on boot:
if [ -x /usr/sbin/acpid -a -d /proc/acpi ]; then echo "Starting ACPID Daemon: /usr/sbin/acpid" /usr/sbin/acpid fi |
A bit of history... Microsoft was the first vendor to implement ACPI. This is both good and bad. It is good because when you buy a system, you can pretty much guarantee that it has passed Microsoft's hardware compliance tests, including the test of its ACPI implementation. However, these tests come up short in that they do not indicate compliance with the ACPI specification, but rather with Microsoft's implementation of ACPI. When that same machine is used with Linux, some classes of errors that did not manifest themselves under Windows may become apparent. To protect against this problem, the Linux ACPI driver maintains a "bad BIOS" blacklist of known BIOS's that are known to not be ACPI compliant, and as a result will refuse to enable ACPI if your system is listed.
Many manufacturers are now validating that their systems run on Linux. However, they use major Linux distributions with the default kernel. This means that it is somewhat difficult to get OEMs to ensure that their systems work with ACPI-enabled Linux until a major Linux distribution ships an ACPI kernel. This presents a slight dilemma in that Linux distributions want to ship kernels that run on as many systems as possible, but there have been some positive moves in this area lately.
To conserve energy while remaining quickly available, ACPI-compatible PCs may enter system sleep states. The ACPI specification defines five of these states, known as S-states. Unlike processor sleep states, no work is done by the system under S-states. Each state introduces greater power savings but requires commensurately more time to awaken and begin performing work. These are patterned on system states from the APM standard, a predecessor of ACPI.
Full details on ACPI sleep states are available at http://acpi.sourceforge.net/documentation/sleep.html. Processor states are described at http://acpi.sourceforge.net/documentation/processor.html.
For more specific background information on ACPI itself, you can visit the ACPI website at http://www.acpi.info
There are currently two competing standards for providing power management: APM and ACPI. Both cannot be used at the same time, so which one is best for your situation? If you have a relatively recent (>2.4.20) kernel and are not intimidated by kernel builds and patching source code, you'll find many benefits with the flexibility of ACPI. If you just want to enable generic power management, or are using an older machine, choose APM. Neither method spins down idle hard drives; use hdparm for that instead. Either way, your system's BIOS must correctly support the power management scheme you'd like to use as well; if your system does not fully support either standard, some of the power management options might crash your system and/or cause data loss. You have been warned!
Even if you don't enable power management on your x86-laptop, Linux will always issue the HLT instruction to your processor whenever nothing needs to be done [1]. Many Microsoft Windows CPU cooling program use this technique. This results in lowering the power consumption of your CPU. Note that the system doesn't power down when it receives the HLT instruction; it just stops executing instructions until there is an interrupt.
Some system manufacturers may have omitted the pre-ACPI tables used for SMP configuration. In this case, ACPI is required [2]. If a system supports HyperThreading, it must use ACPI tables to discover all the virtual processors present. IA64 machines require ACPI, and NUMA servers are starting to require it for proper initialization as well.
There is generally no advantage to enabling either type of power management on servers or workstations that do not fall into these categories.
[1] | source/arch/i386/kernel/process.c |
[2] | Andrew Grover |