<!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/power-management-guide.xml,v 1.14 2005/06/10 18:45:21 swift Exp $ -->

<!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/power-management-guide.xml,v 1.13 2005/05/28 12:59:36 yoswink Exp $ -->

Power Management is the key to extend battery run time on mobile systems like

Power Management (PM) is key to extending battery life on mobile systems

laptops. This guide assists you setting it up on your laptop.

(e.g. laptop computers.) This guide can help you enable PM for your system.

<version>1.24</version>

<version>1.25</version>

<date>2005-06-10</date>

<date>2005-07-08</date>

<title>Why Power Management?</title>

<title>Rationale</title>

Capacity and lifetime of laptop batteries has improved much in the last years.

Over the last decade, the capacity and lifespan of laptop batteries have

Nevertheless modern processors consume much more energy than older ones and

increased significantly. Nevertheless, successive generations of mobile systems

each laptop generation introduces more devices hungry for energy. That's why

introduce devices that require more power than ever. Power Management (PM)

Power Management is more important than ever. Increasing battery run time

policies, when applied intelligently, can make the difference between

doesn't necessarily mean buying another battery. Much can be achieved applying

increasing system runtime with an older battery or buying a newer battery

intelligent Power Management policies.

for your system.

<title>A quick overview</title>

<title>Overview</title>

Please notice that this guide describes Power Management for <e>laptops</e>.

The layout of this document is outlined below:

While some sections might also suite for <e>servers</e>, others do not and may

even cause harm. Please do not apply anything from this guide to a server

unless you really know what you are doing.

<p>

<ul>

As this guide has become rather long, here's a short overview helping you to

        <li>

find your way through it.

                The <e>Prerequisites</e> section discusses requirements that the

</p>

                system must meet before PM for any device can be enabled.

        </li>

<p>

The <e>Prerequisites</e> chapter talks about some requirements that should be

   <li>

met before any of the following device individual sections will work. This

        <e>CPU Power Management</e> discusses PM procedures which adjust the

includes BIOS settings, kernel configuration and some simplifications in user

        processor's frequency to save power while minimizing performance loss.

land. The following three chapters focus on devices that typically consume most

   </li>

energy - processor, display and hard drive. Each can be configured seperately.

<e>CPU Power Management</e> shows how to adjust the processor's frequency to

   <li>

save a maximum of energy whithout losing too much performance. A few different

        <e>LCD Power Management</e> discusses PM techniques to reduce power

tricks prevent your hard drive from working unnecessarily often in <e>Disk Power

        consumption by the display.

Management</e> (decreasing noise level as a nice side effect). Some notes on

   </li>

Wireless LAN and USB finish the device section in <e>Power Management for other

devices</e> while another chapter is dedicated to the (rather experimental)

   <li>

<e>sleep states</e>. Last not least <e>Troubleshooting</e> lists common

        <e>Disk Power Management</e> examines PM tactics to increase a drive's

pitfalls.

        operating efficiency, while decreasing the system's noise level.

</p>

   </li>

   <li>

        <e>Removable Device Power Management</e> addresses PM for removable

        devices, such as Wireless LAN and USB devices.

   </li>

   <li>

        <e>ACPI Suspend States</e> examines PM features (i.e. sleep states)

        provided by <b>experimental</b> kernel support for the Advanced

        Configuration and Power Interface (ACPI).

   </li>

   <li>

        <e>Troubleshooting</e> lists common PM-related pitfalls.

   </li>

</ul>

<title>Power Budget for each component</title>

<title>Component Power Distribution</title>

much energy?" caption="Power budget for each component"/>

much energy?" caption="Power Budget"/>

Nearly every component can operate in different states - off, sleep, idle,

Most components can operate in various states (e.g. <e>off</e>, <e>sleep</e>,

active to name a few - consuming a different amount of energy. Major parts are

<e>idle</e> and <e>active</e>), with each state consuming a different level of

consumed by the LCD display, CPU, chipset and hard drives. Often one is able to

energy. Although OS-independent PM can be enabled through the BIOS, a better PM

activate OS-independent Power Management in the BIOS, but an intelligent setup

policy is to configure the system to intelligently adapt to various power

in the operating system adapting to different situations can achieve much more.

states. However, any PM policy usually leads to performance loss or increased

latency.

<title>What has to be done first</title>

<title>First Things First</title>

Before going into the details on making individual devices Power Management

Before making individual devices PM-aware, certain requirements must be met by

aware, make sure certain requirements are met. After controlling the BIOS

the system. For example, once the necessary BIOS settings have been selected,

settings, some kernel options want to be enabled - these are in short ACPI,

certain kernel options — ACPI and CPU frequency scaling — must be

sleep states and CPU frequency scaling. As power saving most of the time comes

configured. Also, a new runlevel is created to make the transition between

along with performance loss or increased latency, it should only be enabled

battery power and AC power as seamless as possible.

when running on batteries. That's where a new runlevel <e>battery</e> comes in

handy.

<title>The BIOS part</title>

<title>BIOS Configuration</title>

First have a look into your BIOS Power Management settings. The best way is to

Ideally, both the BIOS and OS PM policies will be integrated. However, it is

combine BIOS and operating system policies, but for the moment it's better to

best to disable most BIOS PM settings at this stage to prevent interference

disable most of the BIOS part. This makes sure it doesn't interfere with your

with your policies. Therefore, the BIOS settings will be configured last.

policies. Don't forget to re-check BIOS settings after you configured

everything else.

<title>Configuring the kernel</title>

<title>Kernel Configuration</title>

ACPI (Advanced Configuration and Power Interface) support in the kernel is

Remember, kernel ACPI support is under heavy development. For best results, use

still work in progress. Using a recent kernel will make sure you'll get the

the latest kernel available, and enable the following options through kernel

most out of it.

configuration:

</p>

<p>

In kernel config, activate at least these options:

<pre caption="Minimum kernel setup for Power Management (Kernel 2.6)">

<pre caption="Minimum kernel setup for PM (Kernel 2.6)">

Power Management Options --->

PM Options --->

  [ ] Suspend-to-Disk Support

  ACPI (Advanced Configuration and Power Interface) Support --->

  ACPI( Advanced Configuration and Power Interface ) Support --->

    [ ]   Sleep States

    <comment>(Read the chapter on ACPI before enabling Sleep States.)</comment>

    [*]   AC Adapter

    [ ]   Sleep States (EXPERIMENTAL)

    [*]   Battery

    <*>   AC Adapter

    <M>   Button

    <*>   Battery

    <M>   Fan

    <*>   Button

    <M>   Processor

    <*>   Fan

    <M>     Thermal Zone

    <*>   Processor

    <*>     Thermal Zone

    <comment>(If the kernel is being configured for ASUS, Medion, IBM or Toshiba

    laptops, select the driver appropriate for the system below.)</comment>

    [ ]   Power Management Timer Support

  CPU Frequency Scaling --->

    < >   ACPI0004,PNP0A05 and PNP0A06 Container Driver (EXPERIMENTAL)

  CPU Frequency Scaling --->

    &lt;*&gt; <i>CPUFreq driver for your processor</i>

    <comment>(Selecting the appropriate driver below provides the kernel with

    information needed to enable frequency scaling for your CPU.)</comment>

    --- CPUFreq processor drivers

    < > ACPI Processor P-States driver                                                                                   

    < > AMD Mobile K6-2/K6-3 PowerNow!

    < > AMD Mobile Athlon/Duron PowerNow!

    < > AMD Opteron/Athlon64 PowerNow!

    < > Cyrix MediaGX/NatSemi Geode Suspend Modulation

    < > Intel Enhanced SpeedStep

    < > Intel Speedstep on ICH-M chipsets (ioport interface)

    < > Intel SpeedStep on 440BX/ZX/MX chipsets (SMI interface)

    < > Intel Pentium 4 clock modulation

    < > nVidia nForce2 FSB changing

    < > Transmeta LongRun

    < > VIA Cyrix III Longhaul

<p>

<impo>

Decide yourself whether you want to enable Software Suspend, Suspend-to-Disk and

Selecting the correct CPUFreq driver for the system during kernel configuration

Sleep States (see below). If you own an ASUS, Medion or Toshiba laptop, enable

is important, since each CPU has a different interface. Enabling an improper

the appropriate section.

interface (e.g using <e>Intel Pentium 4 clock modulation</e> on a Pentium M

</p>

system) could prove counterproductive. If in doubt, consult the kernel

documentation to decide which CPUFreq driver is appropriate for your system.

<p>

</impo>

The kernel has to know how to enable CPU frequency scaling on your processor. As

each type of CPU has a different interface, you've got to choose the right

driver for your processor. Be careful here - enabling <e>Intel Pentium 4 clock

modulation</e> on a Pentium M system will lead to strange results for example.

Consult the kernel documentation if you're unsure which one to take.

</p>

Compile your kernel, make sure the right modules get loaded at startup and boot

Once the kernel configuration is complete, compile your new ACPI-enabled kernel

into your new ACPI-enabled kernel. Next run <c>emerge sys-power/acpid</c> to get

that is configured to have applicable modules loaded at startup. Next, install

the acpi daemon. This one informs you about events like switching from AC to

and activate the ACPI daemon (acpid) using the procedure below:

battery or closing the lid. Make sure the modules are loaded if you didn't

compile them into the kernel and start acpid by executing

<c>/etc/init.d/acpid start</c>. Run <c>rc-update add acpid default</c> to load

it on startup. You'll soon see how to use it.

<pre caption="Installing acpid">

<pre caption="ACPI Daemon Installation Procedure">

<title>Creating a "battery" runlevel</title>

<title>Creating a Runlevel</title>

The default policy will be to enable Power Management only when needed -

The default policy is to enable PM only when the system is running on battery

running on batteries. To make the switch between AC and battery convenient,

power. However, creating a <e>battery</e> runlevel (to hold the scripts which

create a runlevel <e>battery</e> that holds all the scripts starting and

will start and stop PM) eases the transition between AC and battery power.

stopping Power Management.

You can safely skip this section if you don't like the idea of having another

While creating another runlevel is not an absolute necessity for PM, skipping

runlevel. However, skipping this step will make the rest a bit trickier to set

the runlevel creation procedure makes for a more challenging setup. This is

up. The next sections assume a runlevel <e>battery</e> exists.

because the rest of this chapter assumes the existence of a runlevel named

<e>battery</e>.

<pre caption="Creating a battery runlevel">

<p>

To add a runlevel, make a new directory in <path>/etc/runlevels</path>, and

populate it with the desired scripts. However, copying an existing (runlevel)

directory may be more efficient, as the procedure below illustrates:

</p>

<pre caption="Runlevel Creation Procedure">

Finished. Your new runlevel <e>battery</e> contains everything like

The <e>battery</e> and <e>default</e> runlevels now contain identical init

<e>default</e>, but there is no automatic switch between both yet. Time to

scripts. However, there is no mechanism to automatically switch between both

change it.

runlevels. The next section illustrates how to include this desired automation.

<title>Reacting on ACPI events</title>

<title>Reacting to ACPI Events</title>

Typical ACPI events are closing the lid, changing the power source or pressing

An ACPI event (e.g. changing the power source) should trigger a runlevel

the sleep button. An important event is changing the power source, which should

switch. Installing the following scripts eases the transition between the

cause a runlevel switch. Create the following files to switch between

<e>default</e> and <e>battery</e> runlevels (depending on which power source is

<e>default</e> and <e>battery</e> runlevel depending on the power source:

used by the system):

Additionally you need the package sys-power/powermgmt-base which contains

Next, install the sys-power/powermgmt-base package, which contains the

the <c>on_ac_power</c> utility. The file <path>pmg_switch_runlevel.sh</path>

<c>on_ac_power</c> utility. The script <path>pmg_switch_runlevel.sh</path> must

must be executable.

be made executable using the <c>chmod</c> command.

Give it a try: Plug AC in and out and watch syslog for the "Switching to AC

Now connect and disconnect the system's AC power supply four or five times, and

mode" or "Switching to battery mode" messages. See the Troubleshooting

observe the output of the kernel log utility (e.g. <c>syslog</c>,

section if the script is not able to detect the power source correctly.

<c>metalog</c>, etc.) You may be able to view the output of the log utility

in <path>/var/log/kernel/current</path>. You should see the

"Switching to AC mode" message or the "Switching to battery mode" message. If

the script is unable to correctly detect a change in the system's power supply,

consult the Troubleshooting section below.

Due to the nature of the event mechanism, your laptop will boot into runlevel

Due to the nature of the event mechanism, your laptop will boot into the

<e>default</e> regardless of the AC/battery state. You can add another entry

<e>default</e> runlevel, regardless of the AC/battery state. There are a few

to the boot loader with <c>softlevel=battery</c>, but it's likely to forget

ways to have the system determine when a runlevel change is necessary. One way

choosing it. A better way is faking an ACPI event in the end of the boot

is to pass another argument to the boot loader &#8212; <c>softlevel=battery</c>.

process and let the <path>/etc/acpi/default.sh</path> script decide whether a

This is an ill-advised method as the system may fail to make the necessary

runlevel change is necessary. Open <path>/etc/conf.d/local.start</path> in your

runlevel switches as needed. A better approach is to simulate an ACPI event at

favourite editor and add these lines:

the end of the boot process and let the <path>/etc/acpi/default.sh</path> script

handle runlevel switches. Open <path>/etc/conf.d/local.start</path> in your

favourite text editor, and add the following:

Prepared like this you can activate Power Management policies for individual 

Your system is now prepared to activate PM policies for individual devices.

devices.

<title>Some technical terms</title>

<title>Technical Terms</title>

CPU frequency scaling brings up some technical terms that might be unknown to

The discussion of CPU frequency scaling involves certain technical terms that

you. Here's a quick introduction.

are explained below:

First of all, the kernel has to be able to change the processor's frequency. The

To successfully deploy CPU frequency scaling on a system, the kernel must be

<e>CPUfreq processor driver</e> knows the commands to do it on your CPU. Thus

provided the instructions (or commands) needed for modifying a processor's

it's important to choose the right one in your kernel. You should already have

frequency. To this end, it is essential to select the appropriate <e>CPUfreq

done it above. Once the kernel knows how to change frequencies, it has to know

processor driver</e> via the kernel configuration process mentioned earlier.

which frequency it should set. This is done according to the <e>policy</e> which

Once the kernel is equipped with the appropriate instructions to change the

consists of a <e>CPUfreq policy</e> and a <e>governor</e>. A CPUfreq policy are

CPU's frequency, it must be made aware of what CPU frequency values may be

just two numbers which define a range the frequency has to stay between -

selected.

minimal and maximal frequency. The governor now decides which of the available

</p>

frequencies in between minimal and maximal frequency to choose. For example, the

<e>powersave governor</e> always chooses the lowest frequency available, the

<note>

<e>performance governor</e> the highest one. The <e>userspace governor</e> makes

Not every laptop supports frequency scaling. If unsure, check the list of

no decision but chooses whatever the user (or a program in userspace) wants -

supported processors in the <e>Troubleshooting</e> section to see if your CPU

which means it reads the frequency from

is supported.

<path>/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed</path>.

</note>

<p>

Frequency selection is done according to a <e>policy</e>, which includes a

<e>CPUfreq policy</e> and a <e>governor</e>. The CPUfreq policy consists of two

values (a minimum and maximum frequency) that serve as boundaries for the range

of frequencies that may be selected. The governor decides which frequencies in

the range for the CPU to operate at. For example, the <e>powersave governor</e>

always chooses the lowest frequency permitted by the policy, while the

<e>performance governor</e> selects the highest frequency permitted by the

policy. The <e>userspace governor</e> simply chooses whatever frequency the

user (or a program in userspace) desires; it reads the frequency from the

<path>/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed</path> script.

This doesn't sound like dynamic frequency changes yet and in fact it isn't.

There are two interrelated advantages to decreasing CPU speed and voltage.

Dynamics however can be accomplished with various approaches. For example,

First, less energy is consumed; this leads to thermal improvement as the system

the <e>ondemand governor</e> makes its decisions depending on the current CPU

runs cooler than it would when the CPU is operating at the maximum speed

load. The same is done by various userland tools like <c>cpudyn</c>,

possible. Unfortunately, the advantages come at the expense of performance as

<c>cpufreqd</c>, <c>powernowd</c> and many more. ACPI events can be used to

the CPU performs fewer operations.

enable or disable dynamic frequency changes depending on power source.

<title>Setting the frequency manually</title>

<title>Manual Frequency Selection</title>

Decreasing CPU speed and voltage has two advantages: On the one hand less

To verify if CPU frequency selection is operational, install another tool

energy is consumed, on the other hand there is thermal improvement as your

suitable for debugging purposes &#8212; <c>sys-power/cpufrequtils</c>:

system doesn't get as hot as running on full speed. The main disadvantage is

obviously the loss of performance. Decreasing processor speed is a trade off

between performance loss and energy saving.

</p>

<note>

Not every laptop supports frequency scaling. If unsure, have a look at the list

of supported processors in the <e>Troubleshooting</e> section to verify your's 

is supported.

</note>

<p>

It's time to test whether CPU frequency changing works. Let's install another

tool which is very handy for debugging purposes: <c>sys-power/cpufrequtils</c>

Now play around with <c>cpufreq-set</c> to make sure frequency switching works.

Tinker with the <c>cpufreq-set</c> utility to verify that frequency selection

Run <c>cpufreq-set -g ondemand</c> for example to activate the ondemand

works. Next, activate the ondemand governor via <c>cpufreq-set -g ondemand</c>

governor and verify the change with <c>cpufreq-info</c>. If it doesn't work as

and confirm the change with <c>cpufreq-info</c>. The output produced should be

expected, you might find help in the Troubleshooting section in the end of this

similar to the sample output provided above. Otherwise, consult the

guide.

Troubleshooting section at the end of this guide.

<title>Automated frequency adaption</title>

<title>Dynamic Frequency Selection</title>

The above is quite nice, but not doable in daily life. Better let your system

Manual frequency selection is simply impractical for daily applications. A

set the appropriate frequency automatically. There are many different approaches

better method is to have the system dynamically determine the appropriate

to do this. The following table gives a quick overview to help you decide on one

frequency using an automated process. The following table provides a quick

of them. It's roughly seperated in three categories <e>kernel</e> for approaches

overview on various approaches to dynamic frequency selection. The different

that only need kernel support, <e>daemon</e> for programs that run in the

approaches are split into three categories: <e>kernel</e> for approaches that

only need kernel support, <e>daemon</e> for programs that operate in the

  <th>Switch decision</th>

  <th>Switch Decision</th>

  <th>Kernel governors</th>

  <th>Kernel Governors</th>

  <th>Further governors</th>

  <th>Further Governors</th>

  <ti>Performance, powersave</ti>

  <ti>performance, powersave</ti>

    Also supports disk standby - notice however that <e>laptop mode</e> in most

    Also supports disk standby. However, in most cases, greater efficiency is

    cases will do a better job.

    achieved using <e>laptop mode</e>.

    Sophisticated (but also complicated) setup.

    Sophisticated (but complicated) setup.

  </ti>

</tr>

<tr>

  <ti><uri link="http://fatcat.ftj.agh.edu.pl/~nelchael/">ncpufreqd</uri></ti>

  <ti>Daemon</ti>

  <ti>Battery state, processor temperature</ti>

  <ti>performance, powersave</ti>

  <ti>None</ti>

  <ti>

    Supports SMP and HT enabled processors; best for semi-mobile processors

    (e.g. Pentium 4M) that are prone to heat dissipation problems, when using

    the performance governor. ACPI throttling supported. Easy policy selection

    via userspace-based utilities. Requires 2.6 kernel.

While adjusting the frequency to the current load looks simple on the first

While adjusting the frequency to the current load may appear simplistic at

view, it's not such a trivial task. A bad algorithm can cause switching between

first glance, it is a task that is far from trivial. A flimsy algorithm can

two frequencies all the time or wasting energy when setting frequency to an

cause incessant switching between two frequencies. Worse yet, such an

unnecessary high level. 

algorithm may unnecessarily select a high frequency — an undesirable

waste of energy.

Which one to choose? If you have no idea about it, try <c>cpufreqd</c>:

If in doubt about which of the utilities to deploy, try <c>cpufreqd</c>:

<c>cpufreqd</c> can be configured by editing <path>/etc/cpufreqd.conf</path>.

The <c>cpufreqd</c> utility can be configured by editing the

The default one that ships with cpufreqd may look a bit confusing. I recommend

<path>/etc/cpufreqd.conf</path> script. If you find default script that ships

replacing it with the one from Gentoo developer Henrik Brix Andersen (see

with cpufreqd confusing, consider replacing it with the script below (provided

below).

by Gentoo developer Henrik Brix Andersen):

You can't use a percentage value like above for min_freq and max_freq if you

If you are using a 2.6 kernel with the sysfs interface, percentage values for

are using kernel 2.6 with the sysfs interface (you probably do). Replace it

<e>min_freq</e> and <e>max_freq</e> as in the above example will not work.

with the lowest and highest frequency as reported by <c>cpufreq-info

Replace those entries with the lowest and highest frequency values, as reported

--hwlimits</c>. For example, on my 1.4 GHz Pentium M I put in

by <c>cpufreq-info --hwlimits</c>.

</p>

<p>

Below is a sample entry for a system with a 1.4 GHz Pentium-M processor:

Last not least start the daemon.

The next step is to start the daemon:

<title>Verifying the result</title>

<title>Verifying CPU Policies</title>

The last thing to check is that your new policies do a good job. An easy way to

The last step to verify that the new policies are providing satisfactory

do so is monitoring CPU speed while working with your laptop:

performance. An easy way to achieve this is to monitor the CPU's speed while

working on your laptop:

If <path>/proc/cpuinfo</path> doesn't get updated (see Troubleshooting),

If the information reported by <path>/proc/cpuinfo</path> does not get

monitor the CPU frequency with:

refreshed or updated, try monitoring the CPU's frequency with the following

command:

Depending on your setup, CPU speed should increase on heavy load, decrease on

When using <e>cpufreqd</e> with the verbosity level set to 5 or higher in

no activity or just stay at the same level. When using cpufreqd and verbosity

<path>cpufreqd.conf</path>, you should receive additional information about

set to 5 or higher in <path>cpufreqd.conf</path> you'll get additional

what events are being reported to the kernel log utility (e.g. syslog, metalog,

information about what's happening reported to syslog.

etc.)

<title>Energy consumer no. 1</title>

<title>Primary Energy Consumer</title>

As you can see in  <uri link="#doc_chap1_fig1">figure 1.1</uri>, the LCD display

As <uri link="#doc_chap1_fig1">Power Budget</uri> chart illustrates, most of

consumes the biggest part of energy (might not be the case for non-mobile

the system's graphical display consumes the most energy (this may not hold true

CPU's). Thus it's quite important not only to shut the display off when not

for non-mobile processors.) Nevertheless, it is important to shut off the

needed, but also to reduce it's backlight if possible. Most laptops offer the

display or lower its backlight level whenever possible. Most laptops are

possibility to control the backlight dimming. 

equipped with tools to control the level of backlight emitted by the display.

First thing to check is the standby/suspend/off timings of the display. As this

First, check the standby/suspend/off timings of the display. The procedure for

depends heavily on your windowmanager, I'll let you figure it out yourself.

checking display timings is beyond the scope of this guide, as it varies among

Just two common places: Blanking the terminal can be done with <c>setterm

window managers. Therefore, consult your window manager's documentation for

-blank &lt;number-of-minutesM&gt;</c>, <c>setterm -powersave on</c> and

further assistance on this matter.

<c>setterm -powerdown &lt;number-of-minutesM&gt;</c>.

</p>

For Xorg, modify <path>/etc/X11/xorg.conf</path> similar to this:

<p>

To reduce the display's power consumption by blanking the terminal, issue the

following commands: <c>setterm -powersave on</c>, <c>setterm -blank TD</c>

and <c>setterm -powerdown TD</c> (replace 'TD' with a number, representing the

desired time delay (in minutes) before executing the commands. So be sure to

pick a number between 0 and 60. For systems that use the X11 implementation

maintained by the X.Org foundation, modify <path>/etc/X11/xorg.conf</path> as

follows (for systems using XFree86, edit <path>/etc/X11/XF86Config</path>):

This is the same for XFree86 and <path>/etc/X11/XF86Config</path>.

However, dimming the display's backlight is probably more useful than blanking

the terminal. If you have access to a utility with settings to dim the display,

write a small script that dims the display's backlight when the system is

running on battery power. Add this script to the <e>battery</e> runlevel by

placing this script in the <path>/etc/runlevels/battery</path> directory.

Probably more important is the backlight dimming. If you have access to the

The following script should work on most IBM Thinkpads, and is obtained by

dimming settings via a tool, write a small script that dims the backlight in

installing the <c>app-laptop/ibm-acpi</c> package or enabling the appropriate

battery mode and place it in your <e>battery</e> runlevel. The following script

option during the kernel configuration process.

should work on most IBM Thinkpads. It needs the <c>app-laptop/ibm-acpi</c>

package or the appropriate option in your kernel has to be enabled.

Support for setting brightness is marked experimental in ibm-acpi. It accesses

Support for adjusting the display's brightness is marked experimental in

hardware directly and may cause severe harm to your system. Please read the

ibm-acpi. It accesses hardware directly and may cause severe harm to your

system. Please read the

To be able to set the brightness level, the ibm_acpi module has to be loaded

To set or adjust the display's brightness, load the ibm_acpi module with the

with the experimental parameter.

parameter aptly named 'experimental':

<pre caption="automatically loading the ibm_acpi module">

<pre caption="How to load the ibm_acpi module automatically">

module. An init script will take care of choosing the brightness according

module. An init script will take care of adjusting the display's brightness

to the power source.

according to the power source.

When done, make sure brightness is adjusted automatically by adding it to the

Next, ensure the brightness level is adjusted automatically by adding it to the

battery runlevel.

<e>battery</e> runlevel:

<title>Sleep when idle</title>

<title>Sleep when Idle</title>

Let's bring the hard disk to sleep as early as possible whenever it is not

Bringing the hard disk to sleep when the system is idle is a prudent policy.

needed. I'll show you two possibilities to do it. First <c>cpudyn</c> supports

What follows is a presentation of two approaches to this matter.

Disk Power Management. Uncomment the lines in the "Disk Options" section in

</p>

<path>/etc/conf.d/cpudyn</path>. To put your first disk to sleep after 60

seconds of no activity, you would modify it like this:

<p>The first approach is provided by <c>cpudyn</c>, a utility that supports

Disk PM. Open <path>/etc/conf.d/cpudyn</path> for editing, and uncomment the

lines in the section entitled 'Disk Options' that correspond to the utility's

parameters:

# Specified disks to spindown (comma separated devices)

# Specified disks to spin down (comma separated devices)

  ebegin "Activating Power Management for Hard Drives"

  ebegin "Activating PM for Hard Drives"

  ebegin "Deactivating Power Management for Hard Drives"

  ebegin "Deactivating PM for Hard Drives"

See <c>man hdparm</c> for the options. If your script is ready, add it to the

See <c>man hdparm</c> for more information on the options available for this

battery runlevel.

utility.

</p>

<p>

Once the <path>/etc/init.d/pm.hda</path> script is created, add it to the

battery runlevel:

<title>Increasing idle time - laptop-mode</title>

<title>Increasing Idle Time with Laptop Mode</title>

Recent kernels (2.6.6 and greater, recent 2.4 ones and others with patches)

Recent kernels (versions 2.6.6 or greater, recent 2.4 ones and others with

include the so-called <e>laptop-mode</e>. When activated, dirty buffers are

patches) include the <e>laptop-mode</e> utility. When activated, dirty buffers

written to disk on read calls or after 10 minutes (instead of 30 seconds). This

are written to disk on read calls or after 10 minutes (instead of 30 seconds).

minimizes the time the hard disk needs to be spun up.

This reduces the time taken by the hard disk to 'spin up'.

<pre caption="Automated start of laptop-mode">

<pre caption="Installing the Laptop Mode Utility">

<c>laptop-mode-tools</c> has it's configuration file in

The configuration file for the <c>laptop-mode-tools</c> utility is located in

<path>/etc/laptop-mode/laptop-mode.conf</path>. Adjust it the way you like it,

<path>/etc/laptop-mode/laptop-mode.conf</path>. This configuration file is

it's well commented. Run <c>rc-update add laptop_mode battery</c> to start it

extensively commented, so feel free to adjust the parameters as you see fit. To

automatically.

automate the utility's operation, add it to the <e>battery</e> runlevel:

<title>Other tricks</title>

<title>Other Tactics</title>

disk frequently - the syslogd is a good candidate. You probably don't want to

disk frequently — the syslogd utility is an excellent candidate for this

shut it down completely, but it's possible to modify the config file so that

exercise. By configuring the utility to ignore or omit the logging of

"unnecessary" things don't get logged and thus don't create disk traffic. Cups

inconsequential events, disk activity can be reduced without shutting off or

writes to disk periodically, so consider shutting it down and only enable it

disabling the utility.

manually when needed.

</p>

<p>

The <e>cups</e> daemon also writes to disk periodically, so consider shutting

it down and only enable it (manually) when needed:

Another possibility is to deactivate swap in battery mode. Before writing a

Another possibility is to deactivate swap while operating on battery power.

swapon/swapoff switcher, make sure there is enough RAM and swap isn't used

Before writing a swapon/swapoff switcher, confirm that the system has enough

heavily, otherwise you'll be in big problems.

RAM for this effort and that swap space is seldom used. Failure to observe such

precautions could cause critical problems.

If you don't want to use laptop-mode, it's still possible to minimize disk

It is possible to minimize disk access without the laptop-mode utility. This

access by mounting certain directories as <e>tmpfs</e> - write accesses are not

may be achieved by mounting certain directories as temporary file systems, or

stored on a disk, but in main memory and get lost with unmounting. Often it's

<e>tmpfs</e>. Here, write accesses are not stored on a disk, but in main memory

useful to mount <path>/tmp</path> like this - you don't have to pay special

and the information contained by such file systems is lost when the directory

attention as it gets cleared on every reboot regardless whether it was mounted

is unmounted.

on disk or in RAM. Just make sure you have enough RAM and no program (like a

</p>

download client or compress utility) needs extraordinary much space in

<path>/tmp</path>. To activate this, enable tmpfs support in your kernel and

<impo>

add a line to <path>/etc/fstab</path> like this:

If you want to mount <path>/var/log</path> with <e>tmpfs</e>, be sure to merge

the log files to disk before unmounting. The log files are essential for proper

operation of the system.

</impo>

<p>

Oftentimes, it is useful to mount <path>/tmp</path> on such a volatile

file system — data stored in this directory is purged during the boot-up

process, whether or not it was mounted on a disk (or in RAM.) To activate this,

enable tmpfs support in your kernel and add a line to the file system table in

<path>/etc/fstab</path> as follows:

Pay attention to the size parameter and modify it for your system. If you're

Exercise extreme caution when modifying the <c>size</c> parameter. If in doubt,

unsure, don't try this at all, it can become a perfomance bottleneck easily. In

do not adjust this parameter; assigning inappropriate values to the parameter

case you want to mount <path>/var/log</path> like this, make sure to merge the

may lead to performance bottlenecks on the system.

log files to disk before unmounting. They are essential. Don't attempt to mount

</warn>

/var/tmp like this. Portage uses it for compiling...

<p>

Remember to confirm that the system has sufficient RAM, and restrict access to

<path>/tmp</path> by programs that require substantial disk space for proper

operation (e.g. a download client or compress utility.) 

</p>

<warn>

<b>Do not attempt to mount /var/tmp on a volatile file system!</b> The

directory is used by Portage while compiling packages for the system.

<title>Power Management for other devices</title>

<title>Removable Device Power Management</title>

<title>Wireless Power Management</title>

<title>Wireless PM</title>

Wireless LAN cards consume quite a few energy. Put them in Power Management

Wireless LAN cards can consume a fair amount energy. Wireless PM can be

mode in analogy to the pm.hda script.

achieved using a script similar to <e>pm.hda</e>, which is used for Disk PM.

Starting the following script will engage PM for wlan0, which instructs the

device to sleep after three seconds of inactivity:

<pre caption="WLAN Power Management automated">

<pre caption="WLAN PM automated">

  ebegin "Activating Power Management for Wireless LAN"

  ebegin "Activating PM for Wireless LAN"

  ebegin "Deactivating Power Management for Wireless LAN"

  ebegin "Deactivating PM for Wireless LAN"

Starting this script will put wlan0 in Power Management mode, going to sleep at

Save this script as <e>pm.wlan0</e> in <path>/etc/init.d/</path>, and add it to

the latest three seconds after no traffic.

the battery runlevel like the disk script above. See <c>man iwconfig</c> for

Save it as <path>/etc/init.d/pm.wlan0</path> and add it to the battery runlevel

details and more options. If your driver and access point support changing the

like the disk script above. See <c>man iwconfig</c> for details and more

beacon time, this is a good starting point to save even more energy.

options. If your driver and access point support changing the beacon time, this

is a good starting point to save even more energy.

<pre caption="Power Management for WLAN">

<pre caption="PM for WLAN">

<title>USB Power Management</title>

<title>USB PM</title>

plugged in. You cannot avoid this (nevertheless remove them in case they're not

plugged in. This is unavoidable, so connect such devices only when they are

needed). Second, when there are USB devices plugged in, the USB host controller

needed, and remove them in case they are not needed). Second, when USB devices

periodically accesses the bus which in turn prevents the CPU from going into

are plugged in, the USB host controller periodically accesses the bus, which in

C3/4 sleep mode. The OS answer to this problem is the so called "USB selective

turn prevents the CPU from going into C3/4 sleep mode.

suspend", which has not yet been implemented in the kernel. USB selective

</p>

suspend only allows bus accesses in case the device is in use. The cruel

workaround until it's implemented is as following: Compile USB support and

<p>The solution provided by the OS to this problem is the so-called "USB

selective suspend", which has yet to be implemented in the kernel. USB

selective suspend only allows bus accesses when the device is in use. The cruel

workaround until it is implemented is as follows: Compile USB support and

<title>Sleep states: sleep, standby, suspend to disk</title>

<title>ACPI Suspend States</title>

ACPI defines different sleep states. The more important ones are

ACPI defines different sleep states. The more important ones are:

They can be called whenever the system is not in use, but a shutdown is not

Sleep states are preferable to powering down the system. This is because the

wanted due to the long boot time.

time taken to resume from such states is shorter than the boot-up sequence.

<title>Sleep, Standby &amp; Hibernate</title>

<title>Sleep, Standby or Hibernate</title>

reason. APM sleep states seem to be more stable, however you can't use APM and

reason; APM sleep states seem to be more stable. However, enabling APM and ACPI

ACPI together.

simultaneously on the same system produces counterproductive results.

Altough sleep state support is improving much, it's still rather experimental.

Although sleep state support is improving much, it's still rather experimental.

There are currently three implementations for S4. The original one is swsusp,

Currently, there are two primary implementations for S4: Software

then there is swsusp2 which has the nicest interface (including bootsplash

Suspend (swsusp) and Software Suspend 2 (swsusp2). The latter has the preferred

support), but requires manual kernel patching. Last not least we have

interface (including bootsplash support), and may be obtained by installing the

Suspend-to-Disk, a fork of swsusp.

swsusp2-sources package (Gentoo 2005.1 or later) or by manually patching the

kernel sources. The former is part of the kernel source tree as a built-in

interface.

If this confused you, have a look at a <uri

Review the following feature comparison to decide which implementation is most

link="http://softwaresuspend.berlios.de/features.html#compare">feature

suitable for your needs:

comparison</uri>. If you still are confused and don't know which one to choose,

first give swsusp2 a try, it looks most promising.

The kernel part for this is as following:

If in doubt about which utility to deploy, try swsusp2. It is under heavy

development, and may include more features soon. To deploy swsusp2, install the

kernel source tree with support for swsusp2:

<pre caption="Kernel configuration for the various suspend types">

<pre caption="Installing swsusp2-sources">

Power Management Options --->

# emerge swsusp2-sources

</pre>

  <comment>(sleep and standby)</comment>

  ACPI( Advanced Configuration and Power Interface ) Support --->

    [*] ACPI Support

       [*]   Sleep States

  <comment>(hibernate with swsusp)</comment>

<p>

  [*] Software Suspend (EXPERIMENTAL)

The kernel configuration for the utilities is as follows:

</p>

  <comment>(hibernate with swsusp2)</comment>

  Software Suspend 2

    --- Image Storage (you need at least one writer)

    [*]    Swap Writer

    --- Page Transformers

    [*]    LZF image compression

    (/dev/"your-swap-here")    Default resume device name

  <comment>(hibernate with Suspend-to-Disk)</comment>

<pre caption="Kernel configuration for the various suspend types">

  [*] Suspend-to-Disk Suport

PM Options --->

  (/dev/"your-swap-here") Default resume partition

   [*] Power Management support

   <comment>(hibernate with swsusp)</comment>

   [*] Software Suspend

   <comment>(hibernate with swsusp2)</comment>

   [*] Software Suspend 2 --->

      [ ]     File Writer

      [*]     Swap Writer

      ---   Page Transformers? We now use Cryptoapi.

      ---   User Interface Options

      [*]     Userspace user interface support

      <comment>(Text mode console support scheduled for deprecation.)</comment>

      [ ]     Text mode console support

      ---   General Options

      ()      Default resume device name (NEW)

      [ ]     Allow Keep Image Mode (NEW)

      [*]     Warn if possibility of filesystem corruption (NEW)

   <comment>(sleep and standby)</comment>

   ACPI(Advanced Configuration and Power Interface) Support --->

   [*] ACPI Support

   [*] Sleep States

Compile your kernel with the appropriate options enabled and issue <c>cat

Compile your kernel (with the appropriate options enabled), then issue the

/proc/acpi/sleep</c> for 2.4 series respectively <c>cat /sys/power/state</c>

following commands: <c>cat /proc/acpi/sleep</c> (for 2.4.x kernels) or

for 2.6 to find out what is supported. The latter gives me <c>standby mem

<c>cat /sys/power/state</c> (for 2.6.x kernels) to find out what is supported.

disk</c>. For swsusp, the kernel parameter <c>resume=/dev/"your-swap-here"</c>

The output for the latter command with a 2.6.11.10 kernel is

has to be appended. If booting is not possible due to a broken image, use

<c>standby mem disk</c>. For swsusp, the kernel parameter

<c>noresume</c> for swsusp, <c>pmdisk=off</c> for Suspend-to-Disk and

<c>resume=/dev/SWAPFILE</c> has to be appended to the boot loader's

<c>noresume2</c> for swsusp2.

list of arguments (replace SWAPFILE with the actual swap device file.) If

booting is not possible due to a broken image, use <c>noresume</c> for swsusp,

or <c>noresume2</c> for swsusp2.

To put your system in one of the sleep states, use

While the above should be sufficient to get swsusp running (not functional),

swsusp2 needs special care. First, install an appropriate kernel (e.g. 

swsusp2-sources), or enhance a generic kernel with the patches available at

<uri link="http://softwaresuspend.berlios.de/">

http://softwaresuspend.berlios.de/</uri>. Next, emerge <c>hibernate-script</c>.

Once hibernate-script is installed, configure this utility using the script in

<path>/etc/hibernate/hibernate.conf</path>. Finally, issue the <c>hibernate</c>

command:

<pre caption="Activating sleep states">

<pre caption="Configuring (and enabling) hibernation">

<comment>(kernel 2.4 series)</comment>

<i># emerge hibernate-script</i>

# <i>echo 1 &gt; /proc/acpi/sleep</i>          <comment>(standby)</comment>

<i># $EDITOR /etc/hibernate/hibernate.conf</i>

# <i>echo 3 &gt; /proc/acpi/sleep</i>          <comment>(sleep)</comment>

<comment>(Last chance to backup any data)</comment>

<i># hibernate</i>

<comment>(kernel 2.6 series)</comment>

</pre>

# <i>echo -n standby &gt; /sys/power/state</i> <comment>(standby)</comment>

# <i>echo -n mem &gt; /sys/power/state</i>     <comment>(sleep)</comment>

<comment>(swsusp)</comment>

<p>

# <i>echo 4 &gt; /proc/acpi/sleep</i>          <comment>(hibernate)</comment>

To put a system running a 2.4.x kernel in one of the sleep states, issue one of

the following commands:

</p>

<comment>(Suspend-to-Disk)</comment>

<pre caption="Activating sleep states for 2.4.x kernels">

# <i>echo -n disk &gt; /sys/power/state</i>    <comment>(hibernate)</comment>

# <i>echo 1 &gt; /proc/acpi/sleep</i>           <comment>(standby)</comment>

# <i>echo 3 &gt; /proc/acpi/sleep</i>           <comment>(sleep)</comment>

# <i>/usr/sbin/hibernate</i>                   <comment>(hibernate, see below)</comment>

# <i>/usr/sbin/hibernate</i>                 <comment>(hibernate)</comment>

If you experience kernel panics due to uhci or similar, try to compile USB

To put a system running a 2.6.x kernel in one of the sleep states, issue one of

support as module and unload the modules before sending your laptop to sleep

the following commands:

mode.

<p>

<pre caption="Activating sleep states for 2.6.x kernels">

While the above should be sufficient to get swsusp and Suspend-to-Disk running

# <i>echo -n standby &gt; /sys/power/state</i>  <comment>(standby)</comment>

(I didn't say working), swsusp2 needs special care. 

# <i>echo -n mem &gt; /sys/power/state</i>      <comment>(sleep)</comment>

The first thing to do is patching the kernel with the patches provided at <uri

link="http://softwaresuspend.berlios.de/">

http://softwaresuspend.berlios.de/</uri>. Additionally you've got to emerge

<c>hibernate-script</c>. Once it is installed, configure

<path>/etc/hibernate/hibernate.conf</path> and try whether it works:

</p>

<pre caption="Configure hibernation">

<comment>(swsusp)</comment>

<i># emerge hibernate-script</i>

# <i>echo 4 &gt; /proc/acpi/sleep</i>           <comment>(hibernate)</comment>

<i># $EDITOR /etc/hibernate/hibernate.conf</i>

<comment>(Last chance to backup any data)</comment>

<comment>(swsusp2)</comment>

<i># hibernate</i>

# <i>/usr/sbin/hibernate</i>                 <comment>(hibernate)</comment>

kernels had a bug causing this. In that case, run <c>emerge x86info</c>,

kernels had a bug causing this. In that case, install a CPU diagnostic utility

update your kernel as asked and check the current frequency with

by issuing the <c>emerge x86info</c> command. Next, update your kernel and

<c>x86info -mhz</c>.

check the current frequency with <c>x86info -mhz</c>.