Attachment 62957 Details for Bug 98395 – Power Management Guide Patch

[patch] Power Management Guide Patch

power-management-guide.diff (text/plain), 62.61 KB, created by Jimi A. on 2005-07-08 14:21:08 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jimi A.

Created: 2005-07-08 14:21:08 UTC

Size: 62.61 KB

patch

obsolete

>--- power-management-guide.xml?passthru=1	2005-06-20 13:45:31.000000000 +0000
>+++ power-management-guide.xml	2005-07-08 16:57:32.000000000 +0000
>@@ -1,6 +1,7 @@
> <?xml version='1.0' encoding="UTF-8"?>
> <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>-
>+
>+
> <guide link="power-management-guide.xml">
> <title>Power Management Guide</title>
> 
>@@ -9,83 +10,103 @@
> </author>
> 
> <abstract>
>-Power Management is the key to extend battery run time on mobile systems like
>-laptops. This guide assists you setting it up on your laptop.
>+Power Management (PM) is key to extending battery life on mobile systems
>+(e.g. laptop computers.) This guide can help you enable PM for your system.
> </abstract>
> 
> 
> 
> <license/>
> 
>-<version>1.24</version>
>-<date>2005-06-10</date>
>+<version>1.25</version>
>+<date>2005-07-08</date>
> 
> <chapter>
> <title>Introduction</title>
> <section>
>-<title>Why Power Management?</title>
>+<title>Rationale</title>
> <body>
> 
> 
>-Capacity and lifetime of laptop batteries has improved much in the last years.
>-Nevertheless modern processors consume much more energy than older ones and
>-each laptop generation introduces more devices hungry for energy. That's why
>-Power Management is more important than ever. Increasing battery run time
>-doesn't necessarily mean buying another battery. Much can be achieved applying
>-intelligent Power Management policies.
>+Over the last decade, the capacity and lifespan of laptop batteries have
>+increased significantly. Nevertheless, successive generations of mobile systems
>+introduce devices that require more power than ever. Power Management (PM)
>+policies, when applied intelligently, can make the difference between
>+increasing system runtime with an older battery or buying a newer battery
>+for your system.
> 
> 
>+<note>
>+This guide describes PM for <e>laptops</e>, not servers. Please do not apply
>+anything from this guide to a server unless you understand the risk of damage
>+to your server.
>+</note>
>+
> </body>
> </section>
> 
> <section>
>-<title>A quick overview</title>
>+<title>Overview</title>
> <body>
> 
> 
>-Please notice that this guide describes Power Management for <e>laptops</e>.
>-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.
>+The layout of this document is outlined below:
> 
> 
>-
>-As this guide has become rather long, here's a short overview helping you to
>-find your way through it.
>-
>-
>-
>-The <e>Prerequisites</e> chapter talks about some requirements that should be
>-met before any of the following device individual sections will work. This
>-includes BIOS settings, kernel configuration and some simplifications in user
>-land. The following three chapters focus on devices that typically consume most
>-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
>-save a maximum of energy whithout losing too much performance. A few different
>-tricks prevent your hard drive from working unnecessarily often in <e>Disk Power
>-Management</e> (decreasing noise level as a nice side effect). Some notes on
>-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)
>-<e>sleep states</e>. Last not least <e>Troubleshooting</e> lists common
>-pitfalls.
>-
>+<ul>
>+ <li>
>+ The <e>Prerequisites</e> section discusses requirements that the
>+ system must meet before PM for any device can be enabled.
>+ </li>
>+ 
>+ <li>
>+ <e>CPU Power Management</e> discusses PM procedures which adjust the
>+ processor's frequency to save power while minimizing performance loss.
>+ </li>
>+ 
>+ <li>
>+ <e>LCD Power Management</e> discusses PM techniques to reduce power
>+ consumption by the display.
>+ </li>
>+ 
>+ <li>
>+ <e>Disk Power Management</e> examines PM tactics to increase a drive's
>+ operating efficiency, while decreasing the system's noise level.
>+ </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 experimental kernel support for the Advanced
>+ Configuration and Power Interface (ACPI).
>+ </li>
>+ 
>+ <li>
>+ <e>Troubleshooting</e> lists common PM-related pitfalls.
>+ </li>
>+</ul>
> 
> </body>
> </section>
> 
> <section>
>-<title>Power Budget for each component</title>
>+<title>Component Power Distribution</title>
> <body>
> 
> <figure link="/images/energy-budget.png" short="Which component consumes how
>-much energy?" caption="Power budget for each component"/>
>+much energy?" caption="Power Budget"/>
> 
> 
>-Nearly every component can operate in different states - off, sleep, idle,
>-active to name a few - consuming a different amount of energy. Major parts are
>-consumed by the LCD display, CPU, chipset and hard drives. Often one is able to
>-activate OS-independent Power Management in the BIOS, but an intelligent setup
>-in the operating system adapting to different situations can achieve much more.
>+Most components can operate in various states (e.g. <e>off</e>, <e>sleep</e>,
>+<e>idle</e> and <e>active</e>), with each state consuming a different level of
>+energy. Although OS-independent PM can be enabled through the BIOS, a better PM
>+policy is to configure the system to intelligently adapt to various power
>+states. However, any PM policy usually leads to performance loss or increased
>+latency.
> 
> 
> </body>
>@@ -94,70 +115,70 @@
> 
> <chapter>
> <title>Prerequisites</title>
>+
> <section>
>-<title>What has to be done first</title>
>+<title>First Things First</title>
> <body>
> 
> 
>-Before going into the details on making individual devices Power Management
>-aware, make sure certain requirements are met. After controlling the BIOS
>-settings, some kernel options want to be enabled - these are in short ACPI,
>-sleep states and CPU frequency scaling. As power saving most of the time comes
>-along with performance loss or increased latency, it should only be enabled
>-when running on batteries. That's where a new runlevel <e>battery</e> comes in
>-handy.
>+Before making individual devices PM-aware, certain requirements must be met by
>+the system. For example, once the necessary BIOS settings have been selected,
>+certain kernel options &#8212; ACPI and CPU frequency scaling &#8212; must be
>+configured. Also, a new runlevel is created to make the transition between
>+battery power and AC power as seamless as possible.
> 
> 
> </body>
> </section>
>+
> <section>
>-<title>The BIOS part</title>
>+<title>BIOS Configuration</title>
> <body>
> 
> 
>-First have a look into your BIOS Power Management settings. The best way is to
>-combine BIOS and operating system policies, but for the moment it's better to
>-disable most of the BIOS part. This makes sure it doesn't interfere with your
>-policies. Don't forget to re-check BIOS settings after you configured
>-everything else.
>+Ideally, both the BIOS and OS PM policies will be integrated. However, it is
>+best to disable most BIOS PM settings at this stage to prevent interference
>+with your policies. Therefore, the BIOS settings will be configured last.
> 
> 
> </body>
> </section>
>+
> <section>
>-<title>Configuring the kernel</title>
>+<title>Kernel Configuration</title>
> <body>
> 
> 
>-ACPI (Advanced Configuration and Power Interface) support in the kernel is
>-still work in progress. Using a recent kernel will make sure you'll get the
>-most out of it.
>-
>-
>-
>-In kernel config, activate at least these options:
>+Remember, kernel ACPI support is under heavy development. For best results, use
>+the latest kernel available, and enable the following options through kernel
>+configuration:
> 
> 
>-<pre caption="Minimum kernel setup for Power Management (Kernel 2.6)">
>-Power Management Options ---&gt;
>+<pre caption="Minimum kernel setup for PM (Kernel 2.6)">
>+PM Options --->
> [*] Power Management Support
>+ <comment>(For more information on whether or not to enable Software Suspend
>+ option below, please read the chapter on ACPI.)</comment>
> [ ] Software Suspend
>- [ ] Suspend-to-Disk Support
>-
>- ACPI( Advanced Configuration and Power Interface ) Support ---&gt;
>+ ACPI (Advanced Configuration and Power Interface) Support --->
> [*] ACPI Support
>- [ ] Sleep States
>- [*] AC Adapter
>- [*] Battery
>- &lt;M&gt; Button
>- &lt;M&gt; Fan
>- &lt;M&gt; Processor
>- &lt;M&gt; Thermal Zone
>+ <comment>(Read the chapter on ACPI before enabling Sleep States.)</comment>
>+ [ ] Sleep States (EXPERIMENTAL)
>+ &lt;*&gt; AC Adapter
>+ &lt;*&gt; Battery
>+ &lt;*&gt; Button
>+ &lt;*&gt; Fan
>+ &lt;*&gt; Processor
>+ &lt;*&gt; 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>
> &lt; &gt; ASUS/Medion Laptop Extras
>+ &lt; &gt; IBM ThinkPad Laptop Extras
> &lt; &gt; Toshiba Laptop Extras
> [ ] Debug Statements
>- 
>- CPU Frequency Scaling ---&gt;
>+ [ ] Power Management Timer Support
>+ &lt; &gt; ACPI0004,PNP0A05 and PNP0A06 Container Driver (EXPERIMENTAL)
>+ CPU Frequency Scaling --->
> [*] CPU Frequency scaling
> Default CPUFreq governor (userspace)
> &lt;*&gt; 'performance' governor
>@@ -165,80 +186,96 @@
> &lt;*&gt; 'ondemand' cpufreq policy governor
> &lt;*&gt; CPU frequency table helpers
> &lt;M&gt; ACPI Processor P-States driver
>- &lt;*&gt; CPUFreq driver for your processor
>+ <comment>(Selecting the appropriate driver below provides the kernel with
>+ information needed to enable frequency scaling for your CPU.)</comment>
>+ --- CPUFreq processor drivers
>+ &lt; &gt; ACPI Processor P-States driver 
>+ &lt; &gt; AMD Mobile K6-2/K6-3 PowerNow!
>+ &lt; &gt; AMD Mobile Athlon/Duron PowerNow!
>+ &lt; &gt; AMD Opteron/Athlon64 PowerNow!
>+ &lt; &gt; Cyrix MediaGX/NatSemi Geode Suspend Modulation
>+ &lt; &gt; Intel Enhanced SpeedStep
>+ &lt; &gt; Intel Speedstep on ICH-M chipsets (ioport interface)
>+ &lt; &gt; Intel SpeedStep on 440BX/ZX/MX chipsets (SMI interface)
>+ &lt; &gt; Intel Pentium 4 clock modulation
>+ &lt; &gt; nVidia nForce2 FSB changing
>+ &lt; &gt; Transmeta LongRun
>+ &lt; &gt; VIA Cyrix III Longhaul
> </pre>
> 
>-
>-Decide yourself whether you want to enable Software Suspend, Suspend-to-Disk and
>-Sleep States (see below). If you own an ASUS, Medion or Toshiba laptop, enable
>-the appropriate section.
>-
>-
>-
>-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.
>-
>+<impo>
>+Selecting the correct CPUFreq driver for the system during kernel configuration
>+is important, since each CPU has a different interface. Enabling an improper
>+interface (e.g using <e>Intel Pentium 4 clock modulation</e> on a Pentium M
>+system) could prove counterproductive. If in doubt, consult the kernel
>+documentation to decide which CPUFreq driver is appropriate for your system.
>+</impo>
> 
> 
>-Compile your kernel, make sure the right modules get loaded at startup and boot
>-into your new ACPI-enabled kernel. Next run <c>emerge sys-power/acpid</c> to get
>-the acpi daemon. This one informs you about events like switching from AC to
>-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.
>+Once the kernel configuration is complete, compile your new ACPI-enabled kernel
>+that is configured to have applicable modules loaded at startup. Next, install
>+and activate the ACPI daemon (acpid) using the procedure below:
> 
> 
>-<pre caption="Installing acpid">
>+<pre caption="ACPI Daemon Installation Procedure">
> # emerge sys-power/acpid
> # /etc/init.d/acpid start
> # rc-update add acpid default
> </pre>
> 
>+
>+This daemon provides notices about various events (e.g. switching between AC
>+and battery power, closing the system's lid, etc.) The daemon can also execute
>+programs that handle ACPI-related events.
>+
>+
> </body>
> </section>
> <section>
>-<title>Creating a "battery" runlevel</title>
>+<title>Creating a Runlevel</title>
> <body>
> 
> 
>-The default policy will be to enable Power Management only when needed -
>-running on batteries. To make the switch between AC and battery convenient,
>-create a runlevel <e>battery</e> that holds all the scripts starting and
>-stopping Power Management.
>+The default policy is to enable PM only when the system is running on battery
>+power. However, creating a <e>battery</e> runlevel (to hold the scripts which
>+will start and stop PM) eases the transition between AC and battery power.
> 
> 
> <note>
>-You can safely skip this section if you don't like the idea of having another
>-runlevel. However, skipping this step will make the rest a bit trickier to set
>-up. The next sections assume a runlevel <e>battery</e> exists.
>+While creating another runlevel is not an absolute necessity for PM, skipping
>+the runlevel creation procedure makes for a more challenging setup. This is
>+because the rest of this chapter assumes the existence of a runlevel named
>+<e>battery</e>.
> </note>
> 
>-<pre caption="Creating a battery runlevel">
>+
>+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:
>+
>+
>+<pre caption="Runlevel Creation Procedure">
> # cd /etc/runlevels
> # cp -a default battery
> </pre>
> 
> 
>-Finished. Your new runlevel <e>battery</e> contains everything like
>-<e>default</e>, but there is no automatic switch between both yet. Time to
>-change it.
>+The <e>battery</e> and <e>default</e> runlevels now contain identical init
>+scripts. However, there is no mechanism to automatically switch between both
>+runlevels. The next section illustrates how to include this desired automation.
> 
> 
> </body>
> </section>
> <section>
>-<title>Reacting on ACPI events</title>
>+<title>Reacting to ACPI Events</title>
> <body>
> 
> 
>-Typical ACPI events are closing the lid, changing the power source or pressing
>-the sleep button. An important event is changing the power source, which should
>-cause a runlevel switch. Create the following files to switch between
>-<e>default</e> and <e>battery</e> runlevel depending on the power source:
>+An ACPI event (e.g. changing the power source) should trigger a runlevel
>+switch. Installing the following scripts eases the transition between the
>+<e>default</e> and <e>battery</e> runlevels (depending on which power source is
>+used by the system):
> 
> 
> <pre caption="/etc/acpi/actions/pmg_switch_runlevel.sh">
>@@ -291,9 +328,9 @@
> </pre>
> 
> 
>-Additionally you need the package sys-power/powermgmt-base which contains
>-the <c>on_ac_power</c> utility. The file <path>pmg_switch_runlevel.sh</path>
>-must be executable.
>+Next, install the sys-power/powermgmt-base package, which contains the
>+<c>on_ac_power</c> utility. The script <path>pmg_switch_runlevel.sh</path> must
>+be made executable using the <c>chmod</c> command.
> 
> 
> <pre caption="Finishing runlevel switching with acpid">
>@@ -303,19 +340,25 @@
> </pre>
> 
> 
>-Give it a try: Plug AC in and out and watch syslog for the "Switching to AC
>-mode" or "Switching to battery mode" messages. See the Troubleshooting
>-section if the script is not able to detect the power source correctly.
>+Now connect and disconnect the system's AC power supply four or five times, and
>+observe the output of the kernel log utility (e.g. <c>syslog</c>,
>+<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
>-<e>default</e> regardless of the AC/battery state. You can add another entry
>-to the boot loader with <c>softlevel=battery</c>, but it's likely to forget
>-choosing it. A better way is faking an ACPI event in the end of the boot
>-process and let the <path>/etc/acpi/default.sh</path> script decide whether a
>-runlevel change is necessary. Open <path>/etc/conf.d/local.start</path> in your
>-favourite editor and add these lines:
>+Due to the nature of the event mechanism, your laptop will boot into the
>+<e>default</e> runlevel, regardless of the AC/battery state. There are a few
>+ways to have the system determine when a runlevel change is necessary. One way
>+is to pass another argument to the boot loader &#8212; <c>softlevel=battery</c>.
>+This is an ill-advised method as the system may fail to make the necessary
>+runlevel switches as needed. A better approach is to simulate an ACPI event at
>+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:
> 
> 
> <pre caption="Runlevel switch at boot time by editing local.start">
>@@ -324,8 +367,7 @@
> </pre>
> 
> 
>-Prepared like this you can activate Power Management policies for individual 
>-devices.
>+Your system is now prepared to activate PM policies for individual devices.
> 
> 
> </body>
>@@ -335,63 +377,61 @@
> <chapter>
> <title>CPU Power Management</title>
> <section>
>-<title>Some technical terms</title>
>+
>+<title>Technical Terms</title>
> <body>
> 
> 
>-CPU frequency scaling brings up some technical terms that might be unknown to
>-you. Here's a quick introduction.
>+The discussion of CPU frequency scaling involves certain technical terms that
>+are explained below:
> 
> 
> 
>-First of all, the kernel has to be able to change the processor's frequency. The
>-<e>CPUfreq processor driver</e> knows the commands to do it on your CPU. Thus
>-it's important to choose the right one in your kernel. You should already have
>-done it above. Once the kernel knows how to change frequencies, it has to know
>-which frequency it should set. This is done according to the <e>policy</e> which
>-consists of a <e>CPUfreq policy</e> and a <e>governor</e>. A CPUfreq policy are
>-just two numbers which define a range the frequency has to stay between -
>-minimal and maximal frequency. The governor now decides which of the available
>-frequencies in between minimal and maximal frequency to choose. For example, the
>-<e>powersave governor</e> always chooses the lowest frequency available, the
>-<e>performance governor</e> the highest one. The <e>userspace governor</e> makes
>-no decision but chooses whatever the user (or a program in userspace) wants -
>-which means it reads the frequency from
>-<path>/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed</path>.
>+To successfully deploy CPU frequency scaling on a system, the kernel must be
>+provided the instructions (or commands) needed for modifying a processor's
>+frequency. To this end, it is essential to select the appropriate <e>CPUfreq
>+processor driver</e> via the kernel configuration process mentioned earlier.
>+Once the kernel is equipped with the appropriate instructions to change the
>+CPU's frequency, it must be made aware of what CPU frequency values may be
>+selected.
>+
>+
>+<note>
>+Not every laptop supports frequency scaling. If unsure, check the list of
>+supported processors in the <e>Troubleshooting</e> section to see if your CPU
>+is supported.
>+</note>
>+
>+
>+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.
>-Dynamics however can be accomplished with various approaches. For example,
>-the <e>ondemand governor</e> makes its decisions depending on the current CPU
>-load. The same is done by various userland tools like <c>cpudyn</c>,
>-<c>cpufreqd</c>, <c>powernowd</c> and many more. ACPI events can be used to
>-enable or disable dynamic frequency changes depending on power source.
>+There are two interrelated advantages to decreasing CPU speed and voltage.
>+First, less energy is consumed; this leads to thermal improvement as the system
>+runs cooler than it would when the CPU is operating at the maximum speed
>+possible. Unfortunately, the advantages come at the expense of performance as
>+the CPU performs fewer operations.
> 
> 
> </body>
> </section>
> <section>
>-<title>Setting the frequency manually</title>
>+<title>Manual Frequency Selection</title>
> <body>
> 
> 
>-Decreasing CPU speed and voltage has two advantages: On the one hand less
>-energy is consumed, on the other hand there is thermal improvement as your
>-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.
>-
>-
>-<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>
>-
>-
>-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>
>+To verify if CPU frequency selection is operational, install another tool
>+suitable for debugging purposes &#8212; <c>sys-power/cpufrequtils</c>:
> 
> 
> <pre caption="Checking CPU frequency">
>@@ -419,25 +459,26 @@
> </pre>
> 
> 
>-Now play around with <c>cpufreq-set</c> to make sure frequency switching works.
>-Run <c>cpufreq-set -g ondemand</c> for example to activate the ondemand
>-governor and verify the change with <c>cpufreq-info</c>. If it doesn't work as
>-expected, you might find help in the Troubleshooting section in the end of this
>-guide.
>+Tinker with the <c>cpufreq-set</c> utility to verify that frequency selection
>+works. Next, activate the ondemand governor via <c>cpufreq-set -g ondemand</c>
>+and confirm the change with <c>cpufreq-info</c>. The output produced should be
>+similar to the sample output provided above. Otherwise, consult the
>+Troubleshooting section at the end of this guide.
> 
> 
> </body>
> </section>
> <section>
>-<title>Automated frequency adaption</title>
>+<title>Dynamic Frequency Selection</title>
> <body>
> 
> 
>-The above is quite nice, but not doable in daily life. Better let your system
>-set the appropriate frequency automatically. There are many different approaches
>-to do this. The following table gives a quick overview to help you decide on one
>-of them. It's roughly seperated in three categories <e>kernel</e> for approaches
>-that only need kernel support, <e>daemon</e> for programs that run in the
>+Manual frequency selection is simply impractical for daily applications. A
>+better method is to have the system dynamically determine the appropriate
>+frequency using an automated process. The following table provides a quick
>+overview on various approaches to dynamic frequency selection. The different
>+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
> background and <e>graphical</e> for programs that provide a GUI for easy
> configuration and changes.
> 
>@@ -446,9 +487,9 @@
> <tr>
> <th>Name</th>
> <th>Category</th>
>- <th>Switch decision</th>
>- <th>Kernel governors</th>
>- <th>Further governors</th>
>+ <th>Switch Decision</th>
>+ <th>Kernel Governors</th>
>+ <th>Further Governors</th>
> <th>Comments</th>
> </tr>
> <tr>
>@@ -468,11 +509,11 @@
> <ti><uri link="http://mnm.uib.es/~gallir/cpudyn/">cpudyn</uri></ti>
> <ti>Daemon</ti>
> <ti>CPU load</ti>
>- <ti>Performance, powersave</ti>
>+ <ti>performance, powersave</ti>
> <ti>Dynamic</ti>
> <ti>
>- Also supports disk standby - notice however that <e>laptop mode</e> in most
>- cases will do a better job.
>+ Also supports disk standby. However, in most cases, greater efficiency is
>+ achieved using <e>laptop mode</e>.
> </ti>
> </tr>
> <tr>
>@@ -482,7 +523,20 @@
> <ti>All available</ti>
> <ti>None</ti>
> <ti>
>- 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.
> </ti>
> </tr>
> <tr>
>@@ -533,14 +587,21 @@
> </table>
> 
> 
>-While adjusting the frequency to the current load looks simple on the first
>-view, it's not such a trivial task. A bad algorithm can cause switching between
>-two frequencies all the time or wasting energy when setting frequency to an
>-unnecessary high level. 
>+While adjusting the frequency to the current load may appear simplistic at
>+first glance, it is a task that is far from trivial. A flimsy algorithm can
>+cause incessant switching between two frequencies. Worse yet, such an
>+algorithm may unnecessarily select a high frequency &#8212; an undesirable
>+waste of energy.
> 
> 
>+<warn>
>+Do not deploy more than one of the above utilities at any given time. Deploying
>+multiple utilities simultaneously on a single system may yield
>+counterproductive results (e.g. incessant switching between two frequencies.)
>+</warn>
>+
> 
>-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>:
> 
> 
> <pre caption="Installing cpufreqd">
>@@ -548,10 +609,10 @@
> </pre>
> 
> 
>-<c>cpufreqd</c> can be configured by editing <path>/etc/cpufreqd.conf</path>.
>-The default one that ships with cpufreqd may look a bit confusing. I recommend
>-replacing it with the one from Gentoo developer Henrik Brix Andersen (see
>-below).
>+The <c>cpufreqd</c> utility can be configured by editing the
>+<path>/etc/cpufreqd.conf</path> script. If you find default script that ships
>+with cpufreqd confusing, consider replacing it with the script below (provided
>+by Gentoo developer Henrik Brix Andersen):
> 
> 
> <pre caption="/etc/cpufreqd.conf">
>@@ -597,10 +658,14 @@
> </pre>
> 
> 
>-You can't use a percentage value like above for min_freq and max_freq if you
>-are using kernel 2.6 with the sysfs interface (you probably do). Replace it
>-with the lowest and highest frequency as reported by <c>cpufreq-info
>---hwlimits</c>. For example, on my 1.4 GHz Pentium M I put in
>+If you are using a 2.6 kernel with the sysfs interface, percentage values for
>+<e>min_freq</e> and <e>max_freq</e> as in the above example will not work.
>+Replace those entries with the lowest and highest frequency values, as reported
>+by <c>cpufreq-info --hwlimits</c>.
>+
>+
>+
>+Below is a sample entry for a system with a 1.4 GHz Pentium-M processor:
> 
> 
> <pre caption="Sample values for minfreq and maxfreq">
>@@ -609,7 +674,7 @@
> </pre>
> 
> 
>-Last not least start the daemon.
>+The next step is to start the daemon:
> 
> 
> <pre caption="Starting cpufreqd">
>@@ -617,22 +682,18 @@
> # rc
> </pre>
> 
>-<warn>
>-Do not run more than one of the above programs at the same time. It may cause
>-confusion like switching between two frequencies all the time.
>-</warn>
>-
> </body>
> </section>
> 
> <section>
>-<title>Verifying the result</title>
>+<title>Verifying CPU Policies</title>
> 
> <body>
> 
> 
>-The last thing to check is that your new policies do a good job. An easy way to
>-do so is monitoring CPU speed while working with your laptop:
>+The last step to verify that the new policies are providing satisfactory
>+performance. An easy way to achieve this is to monitor the CPU's speed while
>+working on your laptop:
> 
> 
> <pre caption="Monitoring CPU speed">
>@@ -640,8 +701,9 @@
> </pre>
> 
> 
>-If <path>/proc/cpuinfo</path> doesn't get updated (see Troubleshooting),
>-monitor the CPU frequency with:
>+If the information reported by <path>/proc/cpuinfo</path> does not get
>+refreshed or updated, try monitoring the CPU's frequency with the following
>+command:
> 
> 
> <pre caption="Alternative CPU speed monitoring">
>@@ -649,10 +711,10 @@
> </pre>
> 
> 
>-Depending on your setup, CPU speed should increase on heavy load, decrease on
>-no activity or just stay at the same level. When using cpufreqd and verbosity
>-set to 5 or higher in <path>cpufreqd.conf</path> you'll get additional
>-information about what's happening reported to syslog.
>+When using <e>cpufreqd</e> with the verbosity level set to 5 or higher in
>+<path>cpufreqd.conf</path>, you should receive additional information about
>+what events are being reported to the kernel log utility (e.g. syslog, metalog,
>+etc.)
> 
> 
> </body>
>@@ -662,24 +724,32 @@
> <chapter>
> <title>LCD Power Management</title>
> <section>
>-<title>Energy consumer no. 1</title>
>+<title>Primary Energy Consumer</title>
> <body>
> 
> 
>-As you can see in <uri link="#doc_chap1_fig1">figure 1.1</uri>, the LCD display
>-consumes the biggest part of energy (might not be the case for non-mobile
>-CPU's). Thus it's quite important not only to shut the display off when not
>-needed, but also to reduce it's backlight if possible. Most laptops offer the
>-possibility to control the backlight dimming. 
>+As <uri link="#doc_chap1_fig1">Power Budget</uri> chart illustrates, most of
>+the system's graphical display consumes the most energy (this may not hold true
>+for non-mobile processors.) Nevertheless, it is important to shut off the
>+display or lower its backlight level whenever possible. Most laptops are
>+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
>-depends heavily on your windowmanager, I'll let you figure it out yourself.
>-Just two common places: Blanking the terminal can be done with <c>setterm
>--blank &lt;number-of-minutesM&gt;</c>, <c>setterm -powersave on</c> and
>-<c>setterm -powerdown &lt;number-of-minutesM&gt;</c>.
>-For Xorg, modify <path>/etc/X11/xorg.conf</path> similar to this:
>+First, check the standby/suspend/off timings of the display. The procedure for
>+checking display timings is beyond the scope of this guide, as it varies among
>+window managers. Therefore, consult your window manager's documentation for
>+further assistance on this matter.
>+
>+
>+
>+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>):
> 
> 
> <pre caption="LCD suspend settings in Xorg and XFree86">
>@@ -703,29 +773,32 @@
> </pre>
> 
> 
>-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
>-dimming settings via a tool, write a small script that dims the backlight in
>-battery mode and place it in your <e>battery</e> runlevel. The following script
>-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.
>+The following script should work on most IBM Thinkpads, and is obtained by
>+installing the <c>app-laptop/ibm-acpi</c> package or enabling the appropriate
>+option during the kernel configuration process.
> 
> 
> <warn>
>-Support for setting brightness is marked experimental in ibm-acpi. It accesses
>-hardware directly and may cause severe harm to your system. Please read the
>+Support for adjusting the display's brightness is marked experimental in
>+ibm-acpi. It accesses hardware directly and may cause severe harm to your
>+system. Please read the
> <uri link="http://ibm-acpi.sourceforge.net/">ibm-acpi website</uri>
> </warn>
> 
> 
>-To be able to set the brightness level, the ibm_acpi module has to be loaded
>-with the experimental parameter.
>+To set or adjust the display's brightness, load the ibm_acpi module with the
>+parameter aptly named 'experimental':
> 
> 
>-<pre caption="automatically loading the ibm_acpi module">
>+<pre caption="How to load the ibm_acpi module automatically">
> <comment>(Please read the warnings above before doing this!)</comment>
> # emerge ibm-acpi
> # echo "options ibm_acpi experimental=1" >> /etc/modules.d/ibm_acpi
>@@ -737,21 +810,10 @@
> 
> This should work without error messages and a file
> <path>/proc/acpi/ibm/brightness</path> should be created after loading the
>-module. An init script will take care of choosing the brightness according
>-to the power source.
>+module. An init script will take care of adjusting the display's brightness
>+according to the power source.
> 
> 
>-<pre caption="/etc/conf.d/lcd-brightness">
>-<comment># See /proc/acpi/ibm/brightness for available values</comment>
>-<comment># Please read /usr/share/doc/ibm-acpi-*/README.gz</comment>
>-
>-<comment># brigthness level in ac mode. Default is 7.</comment>
>-BRIGHTNESS_AC=7
>-
>-<comment># brightness level in battery mode. Default is 4.</comment>
>-BRIGHTNESS_BATTERY=4
>-</pre>
>-
> <pre caption="/etc/init.d/lcd-brightness">
> #!/sbin/runscript
> 
>@@ -783,9 +845,24 @@
> }
> </pre>
> 
>+Most init scripts have configuration files that may be used to adjust
>+various options; the above init script for the display's brightness level is no
>+exception:
>+
>+<pre caption="/etc/conf.d/lcd-brightness">
>+<comment># See /proc/acpi/ibm/brightness for available values</comment>
>+<comment># Please read /usr/share/doc/ibm-acpi-*/README.gz</comment>
>+
>+<comment># brightness level in ac mode. Default is 7.</comment>
>+BRIGHTNESS_AC=7
>+
>+<comment># brightness level in battery mode. Default is 4.</comment>
>+BRIGHTNESS_BATTERY=4
>+</pre>
>+
> 
>-When done, make sure brightness is adjusted automatically by adding it to the
>-battery runlevel.
>+Next, ensure the brightness level is adjusted automatically by adding it to the
>+<e>battery</e> runlevel:
> 
> 
> <pre caption="Enabling automatic brightness adjustment">
>@@ -801,15 +878,18 @@
> <chapter>
> <title>Disk Power Management</title>
> <section>
>-<title>Sleep when idle</title>
>+<title>Sleep when Idle</title>
> <body>
> 
> 
>-Let's bring the hard disk to sleep as early as possible whenever it is not
>-needed. I'll show you two possibilities to do it. First <c>cpudyn</c> supports
>-Disk Power Management. Uncomment the lines in the "Disk Options" section in
>-<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:
>+Bringing the hard disk to sleep when the system is idle is a prudent policy.
>+What follows is a presentation of two approaches to this matter.
>+
>+
>+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:
> 
> 
> <pre caption="Using cpudyn for disk standby">
>@@ -826,13 +906,23 @@
> TIMEOUT=60
> <comment>
> #
>-# Specified disks to spindown (comma separated devices)
>+# Specified disks to spin down (comma separated devices)
> #
> </comment>
> DISKS=/dev/hda
> </pre>
> 
> 
>+The example above brings the first (IDE) disk in the system to sleep after 60
>+seconds of inactivity.
>+
>+
>+<impo>
>+Be careful with the sleep/spin down settings of your hard drive &#8212; setting
>+it to small values might wear out the drive, and void its warranty.
>+</impo>
>+
>+
> The second possibility is using a small script and hdparm. Create
> <path>/etc/init.d/pm.hda</path> like this:
> 
>@@ -845,21 +935,26 @@
> }
> 
> start() {
>- ebegin "Activating Power Management for Hard Drives"
>+ ebegin "Activating PM for Hard Drives"
> hdparm -q -S12 /dev/hda
> eend $?
> }
> 
> stop () {
>- ebegin "Deactivating Power Management for Hard Drives"
>+ ebegin "Deactivating PM for Hard Drives"
> hdparm -q -S253 /dev/hda
> eend $?
> }
> </pre>
> 
> 
>-See <c>man hdparm</c> for the options. If your script is ready, add it to the
>-battery runlevel.
>+See <c>man hdparm</c> for more information on the options available for this
>+utility.
>+
>+
>+
>+Once the <path>/etc/init.d/pm.hda</path> script is created, add it to the
>+battery runlevel:
> 
> 
> <pre caption="Automate disk standby settings">
>@@ -868,49 +963,52 @@
> # rc-update add pm.hda battery
> </pre>
> 
>-<impo>
>-Be careful with sleep/spin down settings of your hard drive. Setting it to
>-small values might wear out your drive and lose warranty.
>-</impo>
>-
> </body>
> </section>
> <section>
>-<title>Increasing idle time - laptop-mode</title>
>+<title>Increasing Idle Time with Laptop Mode</title>
> <body>
> 
> 
>-Recent kernels (2.6.6 and greater, recent 2.4 ones and others with patches)
>-include the so-called <e>laptop-mode</e>. When activated, dirty buffers are
>-written to disk on read calls or after 10 minutes (instead of 30 seconds). This
>-minimizes the time the hard disk needs to be spun up.
>+Recent kernels (versions 2.6.6 or greater, recent 2.4 ones and others with
>+patches) include the <e>laptop-mode</e> utility. When activated, dirty buffers
>+are written to disk on read calls or after 10 minutes (instead of 30 seconds).
>+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">
> # emerge laptop-mode-tools
> </pre>
> 
> 
>-<c>laptop-mode-tools</c> has it's configuration file in
>-<path>/etc/laptop-mode/laptop-mode.conf</path>. Adjust it the way you like it,
>-it's well commented. Run <c>rc-update add laptop_mode battery</c> to start it
>-automatically.
>+The configuration file for the <c>laptop-mode-tools</c> utility is located in
>+<path>/etc/laptop-mode/laptop-mode.conf</path>. This configuration file is
>+extensively commented, so feel free to adjust the parameters as you see fit. To
>+automate the utility's operation, add it to the <e>battery</e> runlevel:
> 
> 
>+<pre caption="Adding laptop-mode to battery runlevel">
>+# rc-update add laptop_mode battery
>+</pre>
>+
> </body>
> </section>
> <section>
>-<title>Other tricks</title>
>+<title>Other Tactics</title>
> <body>
> 
> 
> Besides putting your disk to sleep state as early as possible, it is a good
> idea to minimize disk accesses. Have a look at processes that write to your
>-disk frequently - the syslogd is a good candidate. You probably don't want to
>-shut it down completely, but it's possible to modify the config file so that
>-"unnecessary" things don't get logged and thus don't create disk traffic. Cups
>-writes to disk periodically, so consider shutting it down and only enable it
>-manually when needed.
>+disk frequently &#8212; the syslogd utility is an excellent candidate for this
>+exercise. By configuring the utility to ignore or omit the logging of
>+inconsequential events, disk activity can be reduced without shutting off or
>+disabling the utility.
>+
>+
>+
>+The <e>cups</e> daemon also writes to disk periodically, so consider shutting
>+it down and only enable it (manually) when needed:
> 
> 
> <pre caption="Disabling cups in battery mode">
>@@ -918,21 +1016,32 @@
> </pre>
> 
> 
>-Another possibility is to deactivate swap in battery mode. Before writing a
>-swapon/swapoff switcher, make sure there is enough RAM and swap isn't used
>-heavily, otherwise you'll be in big problems.
>+Another possibility is to deactivate swap while operating on battery power.
>+Before writing a swapon/swapoff switcher, confirm that the system has enough
>+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
>-access by mounting certain directories as <e>tmpfs</e> - write accesses are not
>-stored on a disk, but in main memory and get lost with unmounting. Often it's
>-useful to mount <path>/tmp</path> like this - you don't have to pay special
>-attention as it gets cleared on every reboot regardless whether it was mounted
>-on disk or in RAM. Just make sure you have enough RAM and no program (like a
>-download client or compress utility) needs extraordinary much space in
>-<path>/tmp</path>. To activate this, enable tmpfs support in your kernel and
>-add a line to <path>/etc/fstab</path> like this:
>+It is possible to minimize disk access without the laptop-mode utility. This
>+may be achieved by mounting certain directories as temporary file systems, or
>+<e>tmpfs</e>. Here, write accesses are not stored on a disk, but in main memory
>+and the information contained by such file systems is lost when the directory
>+is unmounted.
>+
>+
>+<impo>
>+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>
>+
>+
>+Oftentimes, it is useful to mount <path>/tmp</path> on such a volatile
>+file system &#8212; 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:
> 
> 
> <pre caption="Editing /etc/fstab to make /tmp even more volatile">
>@@ -940,11 +1049,20 @@
> </pre>
> 
> <warn>
>-Pay attention to the size parameter and modify it for your system. If you're
>-unsure, don't try this at all, it can become a perfomance bottleneck easily. In
>-case you want to mount <path>/var/log</path> like this, make sure to merge the
>-log files to disk before unmounting. They are essential. Don't attempt to mount
>-/var/tmp like this. Portage uses it for compiling...
>+Exercise extreme caution when modifying the <c>size</c> parameter. If in doubt,
>+do not adjust this parameter; assigning inappropriate values to the parameter
>+may lead to performance bottlenecks on the system.
>+</warn>
>+
>+
>+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.) 
>+
>+
>+<warn>
>+Do not attempt to mount /var/tmp on a volatile file system! The
>+directory is used by Portage while compiling packages for the system.
> </warn>
> 
> </body>
>@@ -952,41 +1070,41 @@
> </chapter>
> 
> <chapter>
>-<title>Power Management for other devices</title>
>+<title>Removable Device Power Management</title>
> <section>
>-<title>Wireless Power Management</title>
>+<title>Wireless PM</title>
> <body>
> 
> 
>-Wireless LAN cards consume quite a few energy. Put them in Power Management
>-mode in analogy to the pm.hda script.
>+Wireless LAN cards can consume a fair amount energy. Wireless PM can be
>+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">
> #!/sbin/runscript
> start() {
>- ebegin "Activating Power Management for Wireless LAN"
>+ ebegin "Activating PM for Wireless LAN"
> iwconfig wlan0 power on power max period 3
> eend $?
> }
> 
> stop () {
>- ebegin "Deactivating Power Management for Wireless LAN"
>+ ebegin "Deactivating PM for Wireless LAN"
> iwconfig wlan0 power off
> eend $?
> }
> </pre>
> 
> 
>-Starting this script will put wlan0 in Power Management mode, going to sleep at
>-the latest three seconds after no traffic.
>-Save it as <path>/etc/init.d/pm.wlan0</path> and add it to the battery runlevel
>-like the disk script above. See <c>man iwconfig</c> for details and more
>-options. If your driver and access point support changing the beacon time, this
>-is a good starting point to save even more energy.
>+Save this script as <e>pm.wlan0</e> in <path>/etc/init.d/</path>, and add it to
>+the battery runlevel like the disk script above. See <c>man iwconfig</c> for
>+details and more 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">
> # chmod +x /etc/init.d/pm.wlan0
> # /sbin/depscan.sh
> # rc-update add pm.wlan0 battery
>@@ -994,20 +1112,47 @@
> 
> </body>
> </section>
>+
> <section>
>-<title>USB Power Management</title>
>+<title>USB PM</title>
> <body>
> 
> 
>+Before discussing USB PM, here are a few words on <e>CPU States</e>:
>+
>+
>+<ul>
>+ <li>
>+ Full-On (C0): This is the only state that runs software.
>+ </li>
>+ <li>
>+ Auto-Halt (C1): This state significantly reduces power consumption by the
>+ CPU, while maintaining cache coherency.
>+ </li>
>+ <li>
>+ Quickstart (C2): This state is rather similar to C1; however CPU power
>+ consumption is even further reduced.
>+ </li>
>+ <li>
>+ Deep Sleep/Deeper Sleep (C3/C4): These states are almost identical; the C4
>+ state consumes even less power the C3, which consumes much less power than
>+ any of the C0-C2 states.
>+ </li>
>+</ul>
>+
>+
> There are two problems with USB devices regarding energy consumption: First,
> devices like USB mice, digital cameras or USB sticks consume energy while
>-plugged in. You cannot avoid this (nevertheless remove them in case they're not
>-needed). Second, when there are USB devices plugged in, the USB host controller
>-periodically accesses the bus which in turn prevents the CPU from going into
>-C3/4 sleep mode. The OS answer to this problem is the so called "USB selective
>-suspend", which has not yet been implemented in the kernel. USB selective
>-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
>+plugged in. This is unavoidable, so connect such devices only when they are
>+needed, and remove them in case they are not needed). Second, when USB devices
>+are plugged in, the USB host controller periodically accesses the bus, which in
>+turn prevents the CPU from going into C3/4 sleep mode.
>+
>+
>+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
> devices as modules and remove them via a script while they are not in use (e.g.
> when closing the lid).
> 
>@@ -1017,13 +1162,13 @@
> </chapter>
> 
> <chapter>
>-<title>Sleep states: sleep, standby, suspend to disk</title>
>+<title>ACPI Suspend States</title>
> <section>
> <title>Overview</title>
> <body>
> 
> 
>-ACPI defines different sleep states. The more important ones are
>+ACPI defines different sleep states. The more important ones are:
> 
> 
> <ul> 
>@@ -1033,131 +1178,256 @@
> </ul>
> 
> 
>-They can be called whenever the system is not in use, but a shutdown is not
>-wanted due to the long boot time.
>+Sleep states are preferable to powering down the system. This is because the
>+time taken to resume from such states is shorter than the boot-up sequence.
> 
> 
> </body>
> </section>
> <section>
>-<title>Sleep, Standby &amp; Hibernate</title>
>+<title>Sleep, Standby or Hibernate</title>
> <body>
> 
> 
> The ACPI support for these sleep states is marked as experimental for good
>-reason. APM sleep states seem to be more stable, however you can't use APM and
>-ACPI together.
>+reason; APM sleep states seem to be more stable. However, enabling APM and ACPI
>+simultaneously on the same system produces counterproductive results.
> 
> 
> <warn>
>-Altough sleep state support is improving much, it's still rather experimental.
>+Although sleep state support is improving much, it's still rather experimental.
> At last I got swsusp2 and suspend to RAM to work, but be warned: This will very
> likely not work but damage your data/system.
> </warn>
> 
> 
>-There are currently three implementations for S4. The original one is swsusp,
>-then there is swsusp2 which has the nicest interface (including bootsplash
>-support), but requires manual kernel patching. Last not least we have
>-Suspend-to-Disk, a fork of swsusp.
>+Currently, there are two primary implementations for S4: Software
>+Suspend (swsusp) and Software Suspend 2 (swsusp2). The latter has the preferred
>+interface (including bootsplash support), and may be obtained by installing the
>+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
>-link="http://softwaresuspend.berlios.de/features.html#compare">feature
>-comparison</uri>. If you still are confused and don't know which one to choose,
>-first give swsusp2 a try, it looks most promising.
>+Review the following feature comparison to decide which implementation is most
>+suitable for your needs:
> 
> 
>+<table>
>+ <tr>
>+ <ti>Name</ti>
>+ <ti>Software Suspend</ti>
>+ <ti>Software Suspend 2</ti>
>+ </tr>
>+ <tr>
>+ <ti>Applicable Kernel Versions</ti>
>+ <ti>2.6.x</ti>
>+ <ti>Install swsusp2-sources, or patch against 2.4.2x, 2.6.x</ti>
>+ </tr>
>+ <tr>
>+ <ti>Kernel Option</ti>
>+ <ti>CONFIG_SOFTWARE_SUSPEND</ti>
>+ <ti>CONFIG_SOFTWARE_SUSPEND2</ti>
>+ </tr>
>+ <tr>
>+ <ti>Author</ti>
>+ <ti>Pavel Machek</ti>
>+ <ti>Nigel Cunningham</ti>
>+ </tr>
>+ <tr>
>+ <ti>PM Subsystem</ti>
>+ <ti>None required</ti>
>+ <ti>None required</ti>
>+ </tr>
>+ <tr>
>+ <ti>Bootloader Arguments</ti>
>+ <ti><c>resume=/dev/hda#</c></ti>
>+ <ti><c>resume2=swap:/dev/hda#</c></ti>
>+ </tr>
>+ <tr>
>+ <ti>System Suspend Command</ti>
>+ <ti><c>echo -n disk > /sys/power/state</c></ti>
>+ <ti><c>echo > /proc/software_suspend/do_suspend</c></ti>
>+ </tr>
>+ <tr>
>+ <ti>'Abandon Resume' Argument</ti>
>+ <ti><c>noresume</c></ti>
>+ <ti><c>noresume2</c></ti>
>+ </tr>
>+ <tr>
>+ <ti>Supported Architectures</ti>
>+ <ti>i386, x86_64, ppc</ti>
>+ <ti>i386, ppc (x86_64 under development)</ti>
>+ </tr>
>+ <tr>
>+ <ti>Highmem</ti>
>+ <ti>Supported (up to 4GB)</ti>
>+ <ti>Supported (up to 4GB)</ti>
>+ </tr>
>+ <tr>
>+ <ti>Discontiguous Memory</ti>
>+ <ti>Supported</ti>
>+ <ti>Not Supported</ti>
>+ </tr>
>+ <tr>
>+ <ti>SMP</ti>
>+ <ti>Supported</ti>
>+ <ti>Supported</ti>
>+ </tr>
>+ <tr>
>+ <ti>Preemption</ti>
>+ <ti>Supported</ti>
>+ <ti>Supported</ti>
>+ </tr>
>+ <tr>
>+ <ti>Compression</ti>
>+ <ti>Not Supported</ti>
>+ <ti>LZF Supported</ti>
>+ </tr>
>+ <tr>
>+ <ti>Suspend-to-Swapfile</ti>
>+ <ti>Not Supported</ti>
>+ <ti>Supported</ti>
>+ </tr>
>+ <tr>
>+ <ti>Suspend-to-File</ti>
>+ <ti>Not Supported</ti>
>+ <ti>Supported</ti>
>+ </tr>
>+ <tr>
>+ <ti>Kernel Modules</ti>
>+ <ti>Unavailable (Built-in)</ti>
>+ <ti>Not Supported</ti>
>+ </tr>
>+ <tr>
>+ <ti>Initrd</ti>
>+ <ti>Supported</ti>
>+ <ti>Supported</ti>
>+ </tr>
>+ <tr>
>+ <ti>UML</ti>
>+ <ti>Not Supported</ti>
>+ <ti>Not Supported (Under Development)</ti>
>+ </tr>
>+ <tr>
>+ <ti>Suspend-over-NFS</ti>
>+ <ti>Not Supported</ti>
>+ <ti>Not Supported (Under Development)</ti>
>+ </tr>
>+</table>
>+
> 
>-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">
>-Power Management Options ---&gt;
>-
>- <comment>(sleep and standby)</comment>
>- ACPI( Advanced Configuration and Power Interface ) Support --->
>- [*] ACPI Support
>- [*] Sleep States
>+<pre caption="Installing swsusp2-sources">
>+# emerge swsusp2-sources
>+</pre>
> 
>- <comment>(hibernate with swsusp)</comment>
>- [*] Software Suspend (EXPERIMENTAL)
>- 
>- <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
>+
>+The kernel configuration for the utilities is as follows:
>+
> 
>- <comment>(hibernate with Suspend-to-Disk)</comment>
>- [*] Suspend-to-Disk Suport
>- (/dev/"your-swap-here") Default resume partition
>+<pre caption="Kernel configuration for the various suspend types">
>+PM Options --->
>+ [*] 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
> </pre>
> 
> 
>-Compile your kernel with the appropriate options enabled and issue <c>cat
>-/proc/acpi/sleep</c> for 2.4 series respectively <c>cat /sys/power/state</c>
>-for 2.6 to find out what is supported. The latter gives me <c>standby mem
>-disk</c>. For swsusp, the kernel parameter <c>resume=/dev/"your-swap-here"</c>
>-has to be appended. If booting is not possible due to a broken image, use
>-<c>noresume</c> for swsusp, <c>pmdisk=off</c> for Suspend-to-Disk and
>-<c>noresume2</c> for swsusp2.
>+Compile your kernel (with the appropriate options enabled), then issue the
>+following commands: <c>cat /proc/acpi/sleep</c> (for 2.4.x kernels) or
>+<c>cat /sys/power/state</c> (for 2.6.x kernels) to find out what is supported.
>+The output for the latter command with a 2.6.11.10 kernel is
>+<c>standby mem disk</c>. For swsusp, the kernel parameter
>+<c>resume=/dev/SWAPFILE</c> has to be appended to the boot loader's
>+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.
> 
> 
>+<warn>
>+Backup your data before activating any sleep states on your system. Issue the
>+<c>sync</c> command to have cached data written to disk. First try this without
>+X running, then with X running, but without being logged into the system.
>+</warn>
>+
> 
>-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">
>-<comment>(kernel 2.4 series)</comment>
>-# echo 1 &gt; /proc/acpi/sleep <comment>(standby)</comment>
>-# echo 3 &gt; /proc/acpi/sleep <comment>(sleep)</comment>
>-
>-<comment>(kernel 2.6 series)</comment>
>-# echo -n standby &gt; /sys/power/state <comment>(standby)</comment>
>-# echo -n mem &gt; /sys/power/state <comment>(sleep)</comment>
>+<pre caption="Configuring (and enabling) hibernation">
>+# emerge hibernate-script
>+# $EDITOR /etc/hibernate/hibernate.conf
>+<comment>(Last chance to backup any data)</comment>
>+# hibernate
>+</pre>
> 
>-<comment>(swsusp)</comment>
>-# echo 4 &gt; /proc/acpi/sleep <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:
>+
> 
>-<comment>(Suspend-to-Disk)</comment>
>-# echo -n disk &gt; /sys/power/state <comment>(hibernate)</comment>
>+<pre caption="Activating sleep states for 2.4.x kernels">
>+# echo 1 &gt; /proc/acpi/sleep <comment>(standby)</comment>
>+# echo 3 &gt; /proc/acpi/sleep <comment>(sleep)</comment>
> 
> <comment>(swsusp2)</comment>
>-# /usr/sbin/hibernate <comment>(hibernate, see below)</comment>
>+# /usr/sbin/hibernate <comment>(hibernate)</comment>
> </pre>
> 
>-<warn>
>-Backup your data before doing this. Run <c>sync</c> before executing one of the
>-commands to have cached data written to disk. First try it outside of X, then
>-with X running, but not logged in.
>-</warn>
>- 
> 
>-If you experience kernel panics due to uhci or similar, try to compile USB
>-support as module and unload the modules before sending your laptop to sleep
>-mode.
>+To put a system running a 2.6.x kernel in one of the sleep states, issue one of
>+the following commands:
> 
> 
>-
>-While the above should be sufficient to get swsusp and Suspend-to-Disk running
>-(I didn't say working), swsusp2 needs special care. 
>-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:
>-
>+<pre caption="Activating sleep states for 2.6.x kernels">
>+# echo -n standby &gt; /sys/power/state <comment>(standby)</comment>
>+# echo -n mem &gt; /sys/power/state <comment>(sleep)</comment>
> 
>-<pre caption="Configure hibernation">
>-# emerge hibernate-script
>-# $EDITOR /etc/hibernate/hibernate.conf
>-<comment>(Last chance to backup any data)</comment>
>-# hibernate
>+<comment>(swsusp)</comment>
>+# echo 4 &gt; /proc/acpi/sleep <comment>(hibernate)</comment>
>+
>+<comment>(swsusp2)</comment>
>+# /usr/sbin/hibernate <comment>(hibernate)</comment>
> </pre>
>+ 
>+
>+If you experience kernel panics due to uhci or similar utilities, try to compile
>+USB support as module and unload the modules before sending your laptop into
>+sleep mode.
>+
> 
> </body>
> </section>
>@@ -1208,9 +1478,9 @@
> 
> <e>A:</e> Probably you have activated symmetric multiprocessing support
> (CONFIG_SMP) in your kernel. Deactivate it and it should work. Some older
>-kernels had a bug causing this. In that case, run <c>emerge x86info</c>,
>-update your kernel as asked and check the current frequency with
>-<c>x86info -mhz</c>.
>+kernels had a bug causing this. In that case, install a CPU diagnostic utility
>+by issuing the <c>emerge x86info</c> command. Next, update your kernel and
>+check the current frequency with <c>x86info -mhz</c>.
> 
> 
> 
>@@ -1296,6 +1566,28 @@
> 
> 
> 
>+<e>Q:</e> The response from the command <c>watch x86info -mhz</c> is:
>+ "/dev/cpu/0/cpuid: No such file or directory." What am I doing wrong?
>+
>+
>+
>+<e>A:</e> It is likely that support for Model Specific Registers (MSR) and CPU
>+information is not enabled in the kernel. To fix the problem, recompile the
>+kernel and include the following options:
>+
>+
>+<pre caption="MSR/CPU information support">
>+ Processor type and features --->
>+ <comment>(MSR support)</comment>
>+ &lt;*&gt; /dev/cpu/*/msr - Model-specific register support
>+ <comment>(CPU information support)</comment>
>+ &lt;*&gt; /dev/cpu/*/cpuid - CPU information support
>+</pre>
>+
>+Be sure to select Y, not M. Selecting M may result in the same problem.
>+
>+
>+
> <e>Q:</e> My problem is not listed above. Where should I go next?
> 
>

Actions: View | Diff

Attachments on bug 98395: 62956 | 62957 | 63140 | 63572 | 63911