Power Management Guide

-Power Budget for each component +Component Power Distribution

+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. off, sleep, +idle and active), 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.

@@ -94,70 +115,70 @@ Prerequisites +

-What has to be done first +First Things First

-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 battery 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 — ACPI and CPU frequency scaling — must be +configured. Also, a new runlevel is created to make the transition between +battery power and AC power as seamless as possible.

-The BIOS part +BIOS Configuration

-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.

-Configuring the kernel +Kernel Configuration

-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:

-Power Management Options --->
++PM Options --->
   [*] Power Management Support
+  (For more information on whether or not to enable Software Suspend
+  option below, please read the chapter on ACPI.)
   [ ] Software Suspend
-  [ ] Suspend-to-Disk Support
-
-  ACPI( Advanced Configuration and Power Interface ) Support --->
+  ACPI (Advanced Configuration and Power Interface) Support --->
     [*] ACPI Support
-    [ ]   Sleep States
-    [*]   AC Adapter
-    [*]   Battery
-    <M>   Button
-    <M>   Fan
-    <M>   Processor
-    <M>     Thermal Zone
+    (Read the chapter on ACPI before enabling Sleep States.)
+    [ ]   Sleep States (EXPERIMENTAL)
+    <*>   AC Adapter
+    <*>   Battery
+    <*>   Button
+    <*>   Fan
+    <*>   Processor
+    <*>     Thermal Zone
+    (If the kernel is being configured for ASUS, Medion, IBM or Toshiba
+    laptops, select the driver appropriate for the system below.)
     < >   ASUS/Medion Laptop Extras
+    < >   IBM ThinkPad Laptop Extras
     < >   Toshiba Laptop Extras
     [ ]   Debug Statements
-    
-  CPU Frequency Scaling --->
+    [ ]   Power Management Timer Support
+    < >   ACPI0004,PNP0A05 and PNP0A06 Container Driver (EXPERIMENTAL)
+  CPU Frequency Scaling --->
     [*] CPU Frequency scaling
           Default CPUFreq governor (userspace)
     <*>   'performance' governor
@@ -165,80 +186,96 @@ 
     <*>   'ondemand' cpufreq policy governor
     <*>   CPU frequency table helpers
     <M> ACPI Processor P-States driver
-    <*> CPUFreq driver for your processor
+    (Selecting the appropriate driver below provides the kernel with
+    information needed to enable frequency scaling for your CPU.)
+    --- 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
 
 
-
-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 Intel Pentium 4 clock
-modulation on a Pentium M system will lead to strange results for example.
-Consult the kernel documentation if you're unsure which one to take.
-
+
+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 Intel Pentium 4 clock modulation 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.
+
 
 
-Compile your kernel, make sure the right modules get loaded at startup and boot
-into your new ACPI-enabled kernel. Next run emerge sys-power/acpid 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
-/etc/init.d/acpid start. Run rc-update add acpid default 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:
 
 
-+ # emerge sys-power/acpid
 # /etc/init.d/acpid start
 # rc-update add acpid default
 
 
+
+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.
+
+

-Creating a "battery" runlevel +Creating a Runlevel

-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 battery 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 battery runlevel (to hold the scripts which +will start and stop PM) eases the transition between AC and battery power.

-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 battery 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 +battery. -

+To add a runlevel, make a new directory in /etc/runlevels, and +populate it with the desired scripts. However, copying an existing (runlevel) +directory may be more efficient, as the procedure below illustrates: +

+ +

 # cd /etc/runlevels
 # cp -a default battery

-Finished. Your new runlevel battery contains everything like -default, but there is no automatic switch between both yet. Time to -change it. +The battery and default 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.

-Reacting on ACPI events +Reacting to ACPI Events

-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 -default and battery 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 +default and battery runlevels (depending on which power source is +used by the system):

@@ -291,9 +328,9 @@

-Additionally you need the package sys-power/powermgmt-base which contains -the on_ac_power utility. The file pmg_switch_runlevel.sh -must be executable. +Next, install the sys-power/powermgmt-base package, which contains the +on_ac_power utility. The script pmg_switch_runlevel.sh must +be made executable using the chmod command.

@@ -303,19 +340,25 @@

-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. syslog, +metalog, etc.) You may be able to view the output of the log utility +in /var/log/kernel/current. 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 -default regardless of the AC/battery state. You can add another entry -to the boot loader with softlevel=battery, 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 /etc/acpi/default.sh script decide whether a -runlevel change is necessary. Open /etc/conf.d/local.start in your -favourite editor and add these lines: +Due to the nature of the event mechanism, your laptop will boot into the +default 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 — softlevel=battery. +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 /etc/acpi/default.sh script +handle runlevel switches. Open /etc/conf.d/local.start in your +favourite text editor, and add the following:

@@ -324,8 +367,7 @@

-Prepared like this you can activate Power Management policies for individual -devices. +Your system is now prepared to activate PM policies for individual devices.

@@ -335,63 +377,61 @@ CPU Power Management

-Some technical terms + +Technical Terms

-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 -CPUfreq processor driver 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 policy which -consists of a CPUfreq policy and a governor. 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 -powersave governor always chooses the lowest frequency available, the -performance governor the highest one. The userspace governor makes -no decision but chooses whatever the user (or a program in userspace) wants - -which means it reads the frequency from -/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed. +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 CPUfreq +processor driver 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. +

+ + +Not every laptop supports frequency scaling. If unsure, check the list of +supported processors in the Troubleshooting section to see if your CPU +is supported. + + +

+Frequency selection is done according to a policy, which includes a +CPUfreq policy and a governor. 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 powersave governor +always chooses the lowest frequency permitted by the policy, while the +performance governor selects the highest frequency permitted by the +policy. The userspace governor simply chooses whatever frequency the +user (or a program in userspace) desires; it reads the frequency from the +/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed 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 ondemand governor makes its decisions depending on the current CPU -load. The same is done by various userland tools like cpudyn, -cpufreqd, powernowd 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.

-Setting the frequency manually +Manual Frequency Selection

-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. -

- - -Not every laptop supports frequency scaling. If unsure, have a look at the list -of supported processors in the Troubleshooting section to verify your's -is supported. - - -

-It's time to test whether CPU frequency changing works. Let's install another -tool which is very handy for debugging purposes: sys-power/cpufrequtils +To verify if CPU frequency selection is operational, install another tool +suitable for debugging purposes — sys-power/cpufrequtils:

@@ -419,25 +459,26 @@

-Now play around with cpufreq-set to make sure frequency switching works. -Run cpufreq-set -g ondemand for example to activate the ondemand -governor and verify the change with cpufreq-info. If it doesn't work as -expected, you might find help in the Troubleshooting section in the end of this -guide. +Tinker with the cpufreq-set utility to verify that frequency selection +works. Next, activate the ondemand governor via cpufreq-set -g ondemand +and confirm the change with cpufreq-info. The output produced should be +similar to the sample output provided above. Otherwise, consult the +Troubleshooting section at the end of this guide.

-Automated frequency adaption +Dynamic Frequency Selection

-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 kernel for approaches -that only need kernel support, daemon 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: kernel for approaches that +only need kernel support, daemon for programs that operate in the background and graphical for programs that provide a GUI for easy configuration and changes.

@@ -446,9 +487,9 @@ Name Category - Switch decision - Kernel governors - Further governors + Switch Decision + Kernel Governors + Further Governors Comments @@ -468,11 +509,11 @@ cpudyn Daemon CPU load - Performance, powersave + performance, powersave Dynamic - Also supports disk standby - notice however that laptop mode in most - cases will do a better job. + Also supports disk standby. However, in most cases, greater efficiency is + achieved using laptop mode. @@ -482,7 +523,20 @@ All available None - Sophisticated (but also complicated) setup. + Sophisticated (but complicated) setup. + + + + ncpufreqd + Daemon + Battery state, processor temperature + performance, powersave + None + + 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. @@ -533,14 +587,21 @@

-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 — an undesirable +waste of energy.

+ +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.) + +

-Which one to choose? If you have no idea about it, try cpufreqd: +If in doubt about which of the utilities to deploy, try cpufreqd:

@@ -548,10 +609,10 @@

-cpufreqd can be configured by editing /etc/cpufreqd.conf. -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 cpufreqd utility can be configured by editing the +/etc/cpufreqd.conf 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):

@@ -597,10 +658,14 @@

-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 cpufreq-info ---hwlimits. 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 +min_freq and max_freq as in the above example will not work. +Replace those entries with the lowest and highest frequency values, as reported +by cpufreq-info --hwlimits. +

+ +

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

@@ -609,7 +674,7 @@

-Last not least start the daemon. +The next step is to start the daemon:

@@ -617,22 +682,18 @@ 
 # rc

- -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. - -

-Verifying the result +Verifying CPU Policies

-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:

@@ -640,8 +701,9 @@

-If /proc/cpuinfo doesn't get updated (see Troubleshooting), -monitor the CPU frequency with: +If the information reported by /proc/cpuinfo does not get +refreshed or updated, try monitoring the CPU's frequency with the following +command:

@@ -649,10 +711,10 @@

-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 cpufreqd.conf you'll get additional -information about what's happening reported to syslog. +When using cpufreqd with the verbosity level set to 5 or higher in +cpufreqd.conf, you should receive additional information about +what events are being reported to the kernel log utility (e.g. syslog, metalog, +etc.)

@@ -662,24 +724,32 @@ LCD Power Management

-Energy consumer no. 1 +Primary Energy Consumer

-As you can see in figure 1.1, 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 Power Budget 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 setterm --blank <number-of-minutesM>, setterm -powersave on and -setterm -powerdown <number-of-minutesM>. -For Xorg, modify /etc/X11/xorg.conf 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: setterm -powersave on, setterm -blank TD +and setterm -powerdown TD (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 /etc/X11/xorg.conf as +follows (for systems using XFree86, edit /etc/X11/XF86Config):

@@ -703,29 +773,32 @@

-This is the same for XFree86 and /etc/X11/XF86Config. +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 battery runlevel by +placing this script in the /etc/runlevels/battery 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 battery runlevel. The following script -should work on most IBM Thinkpads. It needs the app-laptop/ibm-acpi -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 app-laptop/ibm-acpi package or enabling the appropriate +option during the kernel configuration process.

-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 ibm-acpi website

-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':

+ (Please read the warnings above before doing this!)
 # 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
 /proc/acpi/ibm/brightness 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.
 
 
--# See /proc/acpi/ibm/brightness for available values
-# Please read /usr/share/doc/ibm-acpi-*/README.gz
-
-# brigthness level in ac mode. Default is 7.
-BRIGHTNESS_AC=7
-
-# brightness level in battery mode. Default is 4.
-BRIGHTNESS_BATTERY=4
-
-
  #!/sbin/runscript
 
@@ -783,9 +845,24 @@ 
 }
 
 
+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:
+
++# See /proc/acpi/ibm/brightness for available values
+# Please read /usr/share/doc/ibm-acpi-*/README.gz
+
+# brightness level in ac mode. Default is 7.
+BRIGHTNESS_AC=7
+
+# brightness level in battery mode. Default is 4.
+BRIGHTNESS_BATTERY=4
+
+
 
-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
+battery runlevel:
 
 
 @@ -801,15 +878,18 @@ 
 
 Disk Power Management
 
-Sleep when idle
+Sleep when Idle
 
 
 
-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 cpudyn supports
-Disk Power Management. Uncomment the lines in the "Disk Options" section in
-/etc/conf.d/cpudyn. 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 cpudyn, a utility that supports
+Disk PM. Open /etc/conf.d/cpudyn for editing, and uncomment the
+lines in the section entitled 'Disk Options' that correspond to the utility's
+parameters:
 
 
 @@ -826,13 +906,23 @@ 
 TIMEOUT=60
 
 #
-# Specified disks to spindown (comma separated devices)
+# Specified disks to spin down (comma separated devices)
 #
 
 DISKS=/dev/hda
 
 
 
+The example above brings the first (IDE) disk in the system to sleep after 60
+seconds of inactivity.
+
+
+
+Be careful with the sleep/spin down settings of your hard drive — setting
+it to small values might wear out the drive, and void its warranty.
+
+
+
 The second possibility is using a small script and hdparm. Create
 /etc/init.d/pm.hda 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 $?
 }
 
 
 
-See man hdparm for the options. If your script is ready, add it to the
-battery runlevel.
+See man hdparm for more information on the options available for this
+utility.
+
+
+
+Once the /etc/init.d/pm.hda script is created, add it to the
+battery runlevel:
 
 
 @@ -868,49 +963,52 @@ 
 # rc-update add pm.hda battery
 
 
-
-Be careful with sleep/spin down settings of your hard drive. Setting it to
-small values might wear out your drive and lose warranty.
-
-

-Increasing idle time - laptop-mode +Increasing Idle Time with Laptop Mode

-Recent kernels (2.6.6 and greater, recent 2.4 ones and others with patches) -include the so-called laptop-mode. 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 laptop-mode 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'.

 # emerge laptop-mode-tools

-laptop-mode-tools has it's configuration file in -/etc/laptop-mode/laptop-mode.conf. Adjust it the way you like it, -it's well commented. Run rc-update add laptop_mode battery to start it -automatically. +The configuration file for the laptop-mode-tools utility is located in +/etc/laptop-mode/laptop-mode.conf. 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 battery runlevel:

+# rc-update add laptop_mode battery
+

-Other tricks +Other Tactics

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 — 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 cups daemon also writes to disk periodically, so consider shutting +it down and only enable it (manually) when needed:

@@ -918,21 +1016,32 @@

-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 tmpfs - write accesses are not -stored on a disk, but in main memory and get lost with unmounting. Often it's -useful to mount /tmp 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 -/tmp. To activate this, enable tmpfs support in your kernel and -add a line to /etc/fstab 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 +tmpfs. 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. +

+ + +If you want to mount /var/log with tmpfs, be sure to merge +the log files to disk before unmounting. The log files are essential for proper +operation of the system. + + +

+Oftentimes, it is useful to mount /tmp 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 +/etc/fstab as follows:

@@ -940,11 +1049,20 @@

-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 /var/log 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 size parameter. If in doubt, +do not adjust this parameter; assigning inappropriate values to the parameter +may lead to performance bottlenecks on the system. + + +

+Remember to confirm that the system has sufficient RAM, and restrict access to +/tmp by programs that require substantial disk space for proper +operation (e.g. a download client or compress utility.) +

+ + +Do not attempt to mount /var/tmp on a volatile file system! The +directory is used by Portage while compiling packages for the system. @@ -952,41 +1070,41 @@ -Power Management for other devices +Removable Device Power Management

-Wireless Power Management +Wireless PM

-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 pm.hda, 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:

+ #!/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 $?
 }
 
 
 
-Starting this script will put wlan0 in Power Management mode, going to sleep at
-the latest three seconds after no traffic.
-Save it as /etc/init.d/pm.wlan0 and add it to the battery runlevel
-like the disk script above. See man iwconfig 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 pm.wlan0 in /etc/init.d/, and add it to
+the battery runlevel like the disk script above. See man iwconfig 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.
 
 
-+ # chmod +x /etc/init.d/pm.wlan0
 # /sbin/depscan.sh
 # rc-update add pm.wlan0 battery
@@ -994,20 +1112,47 @@

-USB Power Management +USB PM

+Before discussing USB PM, here are a few words on CPU States: +

+ +

+ Full-On (C0): This is the only state that runs software. +
+ Auto-Halt (C1): This state significantly reduces power consumption by the + CPU, while maintaining cache coherency. +
+ Quickstart (C2): This state is rather similar to C1; however CPU power + consumption is even further reduced. +
+ 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. +

+ +

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 @@ -Sleep states: sleep, standby, suspend to disk +ACPI Suspend States

Overview

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

@@ -1033,131 +1178,256 @@

-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.

-Sleep, Standby & Hibernate +Sleep, Standby or Hibernate

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.

-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.

-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 feature -comparison. 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:

+ + + Name + Software Suspend + Software Suspend 2 + + + Applicable Kernel Versions + 2.6.x + Install swsusp2-sources, or patch against 2.4.2x, 2.6.x + + + Kernel Option + CONFIG_SOFTWARE_SUSPEND + CONFIG_SOFTWARE_SUSPEND2 + + + Author + Pavel Machek + Nigel Cunningham + + + PM Subsystem + None required + None required + + + Bootloader Arguments + resume=/dev/hda# + resume2=swap:/dev/hda# + + + System Suspend Command + echo -n disk > /sys/power/state + echo > /proc/software_suspend/do_suspend + + + 'Abandon Resume' Argument + noresume + noresume2 + + + Supported Architectures + i386, x86_64, ppc + i386, ppc (x86_64 under development) + + + Highmem + Supported (up to 4GB) + Supported (up to 4GB) + + + Discontiguous Memory + Supported + Not Supported + + + SMP + Supported + Supported + + + Preemption + Supported + Supported + + + Compression + Not Supported + LZF Supported + + + Suspend-to-Swapfile + Not Supported + Supported + + + Suspend-to-File + Not Supported + Supported + + + Kernel Modules + Unavailable (Built-in) + Not Supported + + + Initrd + Supported + Supported + + + UML + Not Supported + Not Supported (Under Development) + + + Suspend-over-NFS + Not Supported + Not Supported (Under Development) + +

-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:

-Power Management Options --->
-
-  (sleep and standby)
-  ACPI( Advanced Configuration and Power Interface ) Support --->
-    [*] ACPI Support
-       [*]   Sleep States
++# emerge swsusp2-sources
+
 
-  (hibernate with swsusp)
-  [*] Software Suspend (EXPERIMENTAL)
-  
-  (hibernate with swsusp2)
-  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:
+
 
-  (hibernate with Suspend-to-Disk)
-  [*] Suspend-to-Disk Suport
-  (/dev/"your-swap-here") Default resume partition
++PM Options --->
+   [*] Power Management support
+   
+   (hibernate with swsusp)
+   [*] Software Suspend
+   
+   (hibernate with swsusp2)
+   [*] Software Suspend 2 --->
+      [ ]     File Writer
+      [*]     Swap Writer
+      ---   Page Transformers? We now use Cryptoapi.
+      ---   User Interface Options
+      [*]     Userspace user interface support
+      (Text mode console support scheduled for deprecation.)
+      [ ]     Text mode console support
+      ---   General Options
+      ()      Default resume device name (NEW)
+      [ ]     Allow Keep Image Mode (NEW)
+      [*]     Warn if possibility of filesystem corruption (NEW)
+      
+   (sleep and standby)
+   ACPI(Advanced Configuration and Power Interface) Support --->
+   [*] ACPI Support
+   [*] Sleep States
 
 
 
-Compile your kernel with the appropriate options enabled and issue cat
-/proc/acpi/sleep for 2.4 series respectively cat /sys/power/state
-for 2.6 to find out what is supported. The latter gives me standby mem
-disk. For swsusp, the kernel parameter resume=/dev/"your-swap-here"
-has to be appended. If booting is not possible due to a broken image, use
-noresume for swsusp, pmdisk=off for Suspend-to-Disk and
-noresume2 for swsusp2.
+Compile your kernel (with the appropriate options enabled), then issue the
+following commands: cat /proc/acpi/sleep (for 2.4.x kernels) or
+cat /sys/power/state (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
+standby mem disk. For swsusp, the kernel parameter
+resume=/dev/SWAPFILE 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 noresume for swsusp,
+or noresume2 for swsusp2.
 
 
+
+Backup your data before activating any sleep states on your system. Issue the
+sync 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.
+
+
 
-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
+
+http://softwaresuspend.berlios.de/. Next, emerge hibernate-script.
+Once hibernate-script is installed, configure this utility using the script in
+/etc/hibernate/hibernate.conf. Finally, issue the hibernate
+command:
 
 
--(kernel 2.4 series)
-# echo 1 > /proc/acpi/sleep          (standby)
-# echo 3 > /proc/acpi/sleep          (sleep)
-
-(kernel 2.6 series)
-# echo -n standby > /sys/power/state (standby)
-# echo -n mem > /sys/power/state     (sleep)
++# emerge hibernate-script
+# $EDITOR /etc/hibernate/hibernate.conf
+(Last chance to backup any data)
+# hibernate
+
 
-(swsusp)
-# echo 4 > /proc/acpi/sleep          (hibernate)
+
+To put a system running a 2.4.x kernel in one of the sleep states, issue one of
+the following commands:
+
 
-(Suspend-to-Disk)
-# echo -n disk > /sys/power/state    (hibernate)
++# echo 1 > /proc/acpi/sleep           (standby)
+# echo 3 > /proc/acpi/sleep           (sleep)
 
 (swsusp2)
-# /usr/sbin/hibernate                   (hibernate, see below)
+# /usr/sbin/hibernate                 (hibernate)
 
 
-
-Backup your data before doing this. Run sync 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.
-
- 
 
-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 
-http://softwaresuspend.berlios.de/. Additionally you've got to emerge
-hibernate-script. Once it is installed, configure
-/etc/hibernate/hibernate.conf and try whether it works:
-
++# echo -n standby > /sys/power/state  (standby)
+# echo -n mem > /sys/power/state      (sleep)
 
--# emerge hibernate-script
-# $EDITOR /etc/hibernate/hibernate.conf
-(Last chance to backup any data)
-# hibernate
+(swsusp)
+# echo 4 > /proc/acpi/sleep           (hibernate)
+
+(swsusp2)
+# /usr/sbin/hibernate                 (hibernate)
 
+ 
+
+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.
+

@@ -1208,9 +1478,9 @@

A: 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 emerge x86info, -update your kernel as asked and check the current frequency with -x86info -mhz. +kernels had a bug causing this. In that case, install a CPU diagnostic utility +by issuing the emerge x86info command. Next, update your kernel and +check the current frequency with x86info -mhz.

@@ -1296,6 +1566,28 @@

+Q: The response from the command watch x86info -mhz is: + "/dev/cpu/0/cpuid: No such file or directory." What am I doing wrong? +

+ +

+A: 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: +

+ +

+  Processor type and features --->
+  (MSR support)
+    <*> /dev/cpu/*/msr - Model-specific register support
+  (CPU information support)
+    <*> /dev/cpu/*/cpuid - CPU information support
+

+Be sure to select Y, not M. Selecting M may result in the same problem. +

+ +

Q: My problem is not listed above. Where should I go next?