Attachment 62956 Details for Bug 98395 – Updated Power Management Guide.

Updated Power Management Guide.

power-management-guide.xml (text/xml), 46.59 KB, created by Jimi A. on 2005-07-08 14:09:12 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jimi A.

Created: 2005-07-08 14:09:12 UTC

Size: 46.59 KB

patch

obsolete

><?xml version='1.0' encoding="UTF-8"?>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
>
><guide link="power-management-guide.xml">
><title>Power Management Guide</title>
>
><author title="Author">
> <mail link="fragfred@gmx.de">Dennis NienhÃ¼ser</mail>
></author>
>
><abstract>
>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.25</version>
><date>2005-07-08</date>
>
><chapter>
><title>Introduction</title>
><section>
><title>Rationale</title>
><body>
>
>
>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>Overview</title>
><body>
>
>
>The layout of this document is outlined below:
>
>
><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>Component Power Distribution</title>
><body>
>
><figure link="/images/energy-budget.png" short="Which component consumes how
>much energy?" caption="Power Budget"/>
>
>
>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>
></section>
></chapter>
>
><chapter>
><title>Prerequisites</title>
>
><section>
><title>First Things First</title>
><body>
>
>
>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>BIOS Configuration</title>
><body>
>
>
>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>Kernel Configuration</title>
><body>
>
>
>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 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
> ACPI (Advanced Configuration and Power Interface) Support --->
> [*] ACPI Support
> <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
> [ ] 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
> &lt;*&gt; 'powersave' governor
> &lt;*&gt; 'ondemand' cpufreq policy governor
> &lt;*&gt; CPU frequency table helpers
> &lt;M&gt; ACPI Processor P-States driver
> <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>
>
><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>
>
>
>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="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 Runlevel</title>
><body>
>
>
>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>
>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>
>
>
>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>
>
>
>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 to ACPI Events</title>
><body>
>
>
>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">
>#!/bin/bash
>
><comment># BEGIN configuration</comment>
>RUNLEVEL_AC="default"
>RUNLEVEL_BATTERY="battery"
><comment># END configuration</comment>
>
>
>if [ ! -d "/etc/runlevels/${RUNLEVEL_AC}" ]
>then
> logger "${0}: Runlevel ${RUNLEVEL_AC} does not exist. Aborting."
> exit 1
>fi
>
>if [ ! -d "/etc/runlevels/${RUNLEVEL_BATTERY}" ]
>then
> logger "${0}: Runlevel ${RUNLEVEL_BATTERY} does not exist. Aborting."
> exit 1
>fi
>
>if on_ac_power
>then
> if [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_AC}" ]]
> then
> logger "Switching to ${RUNLEVEL_AC} runlevel"
> /sbin/rc ${RUNLEVEL_AC}
> fi
>elif [[ "$(cat /var/lib/init.d/softlevel)" != "${RUNLEVEL_BATTERY}" ]]
>then
> logger "Switching to ${RUNLEVEL_BATTERY} runlevel"
> /sbin/rc ${RUNLEVEL_BATTERY}
>fi
></pre>
>
><pre caption="/etc/acpi/events/pmg_ac_adapter">
><comment># replace "ac_adapter" below with the event generated on your laptop</comment>
><comment># See /var/log/acpid</comment>
>event=ac_adapter.*
>action=/etc/acpi/actions/pmg_switch_runlevel.sh %e
></pre>
>
><pre caption="/etc/acpi/events/pmg_battery">
><comment># replace "battery" below with the event generated on your laptop</comment>
><comment># See /var/log/acpid</comment>
>event=battery.*
>action=/etc/acpi/actions/pmg_switch_runlevel.sh %e
></pre>
>
>
>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">
># emerge powermgmt-base
># chmod +x /etc/acpi/actions/pmg_switch_runlevel.sh
># /etc/init.d/acpid restart
></pre>
>
>
>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 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">
><comment># Fake acpi event to switch runlevel if running on batteries</comment>
>/etc/acpi/actions/pmg_switch_runlevel.sh "battery/battery"
></pre>
>
>
>Your system is now prepared to activate PM policies for individual devices.
>
>
></body>
></section>
></chapter>
>
><chapter>
><title>CPU Power Management</title>
><section>
>
><title>Technical Terms</title>
><body>
>
>
>The discussion of CPU frequency scaling involves certain technical terms that
>are explained below:
>
>
>
>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.
>
>
>
>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>Manual Frequency Selection</title>
><body>
>
>
>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">
># emerge cpufrequtils
># cpufreq-info
></pre>
>
>
>Here is an example output:
>
>
><pre caption="Sample output from cpufreq-info">
>cpufrequtils 0.2: cpufreq-info (C) Dominik Brodowski 2004
>Report errors and bugs to linux@brodo.de, please.
>analyzing CPU 0:
> driver: centrino
> CPUs which need to switch frequency at the same time: 0
> hardware limits: 600 MHz - 1.40 GHz
> available frequency steps: 600 MHz, 800 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz
> available cpufreq governors: ondemand, powersave, userspace, performance
> current policy: frequency should be within 924 MHz and 1.40 GHz.
> The governor "performance" may decide which speed to use
> within this range.
> current CPU frequency is 1.40 GHz (asserted by call to hardware).
></pre>
>
>
>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>Dynamic Frequency Selection</title>
><body>
>
>
>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.
>
>
><table>
><tr>
> <th>Name</th>
> <th>Category</th>
> <th>Switch Decision</th>
> <th>Kernel Governors</th>
> <th>Further Governors</th>
> <th>Comments</th>
></tr>
><tr>
> <ti>'ondemand' governor</ti>
> <ti>Kernel</ti>
> <ti>CPU load</ti>
> <ti>N.A.</ti>
> <ti>N.A.</ti>
> <ti>
> Further tuning through files in
> <path>/sys/devices/system/cpu/cpu0/cpufreq/ondemand/</path>. Still requires
> userland tools (programs, scripts) if governor switching or similar is
> desired.
> </ti>
></tr>
><tr>
> <ti><uri link="http://mnm.uib.es/~gallir/cpudyn/">cpudyn</uri></ti>
> <ti>Daemon</ti>
> <ti>CPU load</ti>
> <ti>performance, powersave</ti>
> <ti>Dynamic</ti>
> <ti>
> Also supports disk standby. However, in most cases, greater efficiency is
> achieved using <e>laptop mode</e>.
> </ti>
></tr>
><tr>
> <ti><uri link="http://sourceforge.net/projects/cpufreqd/">cpufreqd</uri></ti>
> <ti>Daemon</ti>
> <ti>Battery state, CPU load, running programs</ti>
> <ti>All available</ti>
> <ti>None</ti>
> <ti>
> 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>
> <ti>
> <uri link="http://www.deater.net/john/powernowd.html">powernowd</uri>
> </ti>
> <ti>Daemon</ti>
> <ti>CPU load</ti>
> <ti>None</ti>
> <ti>Passive, sine, aggressive</ti>
> <ti>
> Supports SMP.
> </ti>
></tr>
><tr>
> <ti><uri link="http://www.goop.org/~jeremy/speedfreq/">speedfreq</uri></ti>
> <ti>Daemon</ti>
> <ti>CPU load</ti>
> <ti>None</ti>
> <ti>Dynamic, powersave, performance, fixed speed</ti>
> <ti>
> Small yet powerful with an useful client/server interface. Requires a 2.6
> kernel. Doesn't seem to be maintained anymore and will be removed from
> Portage in the near future.
> </ti>
></tr>
><tr>
> <ti><uri link="http://cpuspeedy.sourceforge.net/">gtk-cpuspeedy</uri></ti>
> <ti>Graphical</ti>
> <ti>None</ti>
> <ti>None</ti>
> <ti>None</ti>
> <ti>
> Gnome application, a graphical tool to set CPU frequency manually. It does
> not offer any automation.
> </ti>
></tr>
><tr>
> <ti>klaptopdaemon</ti>
> <ti>Graphical</ti>
> <ti>Battery state</ti>
> <ti>All available</ti>
> <ti>None</ti>
> <ti>
> KDE only, 'ondemand' governor required for dynamic frequency scaling.
> </ti>
></tr>
></table>
>
>
>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>
>
>
>If in doubt about which of the utilities to deploy, try <c>cpufreqd</c>:
>
>
><pre caption="Installing cpufreqd">
># emerge cpufreqd
></pre>
>
>
>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">
>[General]
>pidfile=/var/run/cpufreqd.pid
>poll_interval=2
>pm_type=acpi
>verbosity=5
>
>[Profile]
>name=ondemand
>minfreq=0%
>maxfreq=100%
>policy=ondemand
>
>[Profile]
>name=powersave
>minfreq=0%
>maxfreq=100%
>policy=powersave
>
>[Profile]
>name=performance
>minfreq=0%
>maxfreq=100%
>policy=performance
>
>[Rule]
>name=battery
>ac=off
>profile=ondemand
>
>[Rule]
>name=battery_low
>ac=off
>battery_interval=0-10
>profile=powersave
>
>[Rule]
>name=ac
>ac=on
>profile=performance
></pre>
>
>
>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">
>minfreq=600000
>maxfreq=1400000
></pre>
>
>
>The next step is to start the daemon:
>
>
><pre caption="Starting cpufreqd">
># rc-update add cpufreqd default battery
># rc
></pre>
>
></body>
></section>
>
><section>
><title>Verifying CPU Policies</title>
>
><body>
>
>
>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">
># watch grep \"cpu MHz\" /proc/cpuinfo
></pre>
>
>
>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">
># watch x86info -mhz
></pre>
>
>
>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>
></section>
></chapter>
>
><chapter>
><title>LCD Power Management</title>
><section>
><title>Primary Energy Consumer</title>
><body>
>
>
>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, 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">
>Section "ServerLayout"
> Identifier [...]
> [...]
> Option "BlankTime" "5" <comment># Blank the screen after 5 minutes (Fake)</comment>
> Option "StandbyTime" "10" <comment># Turn off screen after 10 minutes (DPMS)</comment>
> Option "SuspendTime" "20" <comment># Full suspend after 20 minutes</comment>
> Option "OffTime" "30" <comment># Turn off after half an hour</comment>
> [...]
>EndSection
>
>[...]
>
>Section "Monitor"
> Identifier [...]
> Option "DPMS" "true"
> [...]
>EndSection
></pre>
>
>
>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.
>
>
>
>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 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 set or adjust the display's brightness, load the ibm_acpi module with the
>parameter aptly named 'experimental':
>
>
><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
># /sbin/modules-update
># echo ibm_acpi >> /etc/modules.autoload.d/kernel-2.6
># modprobe ibm_acpi
></pre>
>
>
>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 adjusting the display's brightness
>according to the power source.
>
>
><pre caption="/etc/init.d/lcd-brightness">
>#!/sbin/runscript
>
>set_brightness() {
> if on_ac_power
> then
> LEVEL=${BRIGHTNESS_AC:-7}
> else
> LEVEL=${BRIGHTNESS_BATTERY:-4}
> fi
>
> if [ -f /proc/acpi/ibm/brightness ]
> then
> ebegin "Setting LCD brightness"
> echo "level ${LEVEL}" > /proc/acpi/ibm/brightness
> eend $?
> else
> ewarn "Setting LCD brightness is not supported."
> ewarn "Check that ibm_acpi is loaded into the kernel"
> fi
>}
>
>start() {
> set_brightness
>}
>
>stop () {
> set_brightness
>}
></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>
>
>
>Next, ensure the brightness level is adjusted automatically by adding it to the
><e>battery</e> runlevel:
>
>
><pre caption="Enabling automatic brightness adjustment">
># chmod +x /etc/init.d/lcd-brightness
># rc-update add lcd-brightness battery
># rc
></pre>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Disk Power Management</title>
><section>
><title>Sleep when Idle</title>
><body>
>
>
>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">
><comment>################################################
># DISK OPTIONS
># (disabled by default)
>################################################
>
>#
># Timeout to put the disk in standby mode if there was no
># io during that period (in seconds)
>#
></comment>
>TIMEOUT=60
><comment>
>#
># 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:
>
>
><pre caption="Using hdparm for disk standby">
>#!/sbin/runscript
>
>depend() {
> after hdparm
>}
>
>start() {
> ebegin "Activating PM for Hard Drives"
> hdparm -q -S12 /dev/hda
> eend $?
>}
>
>stop () {
> ebegin "Deactivating PM for Hard Drives"
> hdparm -q -S253 /dev/hda
> eend $?
>}
></pre>
>
>
>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">
># chmod +x /etc/init.d/pm.hda
># /sbin/depscan.sh
># rc-update add pm.hda battery
></pre>
>
></body>
></section>
><section>
><title>Increasing Idle Time with Laptop Mode</title>
><body>
>
>
>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="Installing the Laptop Mode Utility">
># emerge laptop-mode-tools
></pre>
>
>
>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 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 &#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">
># rc-update del cupsd battery
></pre>
>
>
>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.
>
>
>
>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">
>none /tmp tmpfs size=32m 0 0
></pre>
>
><warn>
>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>
></section>
></chapter>
>
><chapter>
><title>Removable Device Power Management</title>
><section>
><title>Wireless PM</title>
><body>
>
>
>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 PM automated">
>#!/sbin/runscript
>start() {
> ebegin "Activating PM for Wireless LAN"
> iwconfig wlan0 power on power max period 3
> eend $?
>}
>
>stop () {
> ebegin "Deactivating PM for Wireless LAN"
> iwconfig wlan0 power off
> eend $?
>}
></pre>
>
>
>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="PM for WLAN">
># chmod +x /etc/init.d/pm.wlan0
># /sbin/depscan.sh
># rc-update add pm.wlan0 battery
></pre>
>
></body>
></section>
>
><section>
><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. 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).
>
>
></body>
></section>
></chapter>
>
><chapter>
><title>ACPI Suspend States</title>
><section>
><title>Overview</title>
><body>
>
>
>ACPI defines different sleep states. The more important ones are:
>
>
><ul> 
> <li>S1 aka Standby</li>
> <li>S3 aka Suspend to RAM aka Sleep</li>
> <li>S4 aka Suspend to Disk aka Hibernate</li>
></ul>
>
>
>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 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, enabling APM and ACPI
>simultaneously on the same system produces counterproductive results.
>
>
><warn>
>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>
>
>
>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.
>
>
>
>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>
>
>
>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="Installing swsusp2-sources">
># emerge swsusp2-sources
></pre>
>
>
>The kernel configuration for the utilities is as follows:
>
>
><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), 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>
>
>
>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="Configuring (and enabling) hibernation">
># emerge hibernate-script
># $EDITOR /etc/hibernate/hibernate.conf
><comment>(Last chance to backup any data)</comment>
># hibernate
></pre>
>
>
>To put a system running a 2.4.x kernel in one of the sleep states, issue one of
>the following commands:
>
>
><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)</comment>
></pre>
>
>
>To put a system running a 2.6.x kernel in one of the sleep states, issue one of
>the following commands:
>
>
><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>
>
><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>
></chapter>
>
><chapter>
><title>Troubleshooting</title>
><section>
><title>If things go wrong...</title>
><body>
>
>
><e>Q:</e> I'm trying to change the CPU frequency, but
><path>/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor</path> does not
>exist.
>
>
>
><e>A:</e> Make sure your processor supports CPU frequency scaling and you chose
>the right CPUFreq driver for your processor. Here is a list of processors that
>are supported by cpufreq (kernel 2.6.7): ARM Integrator, ARM-SA1100,
>ARM-SA1110, AMD Elan - SC400, SC410, AMD mobile K6-2+, AMD mobile K6-3+, AMD
>mobile Duron, AMD mobile Athlon, AMD Opteron, AMD Athlon 64, Cyrix Media GXm,
>Intel mobile PIII and Intel mobile PIII-M on certain chipsets, Intel Pentium 4,
>Intel Xeon, Intel Pentium M (Centrino), National Semiconductors Geode GX,
>Transmeta Crusoe, VIA Cyrix 3 / C3, UltraSPARC-III, SuperH SH-3, SH-4, several
>"PowerBook" and "iBook2" and various processors on some ACPI 2.0-compatible
>systems (only if "ACPI Processor Performance States" are available to the
>ACPI/BIOS interface).
>
>
>
><e>Q:</e> My laptop supports frequency scaling, but
><path>/sys/devices/system/cpu/cpu0/cpufreq/</path> is empty.
>
>
>
><e>A:</e> Look for ACPI related error messages with <c>dmesg | grep ACPI</c>.
>Try to update the BIOS, especially if a broken DSDT is reported. You can also
>try to fix it yourself (which is beyond the scope of this guide).
>
>
>
><e>Q:</e> My laptop supports frequency scaling, but according to /proc/cpuinfo
>the speed never changes.
>
>
>
><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, 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>.
>
>
>
><e>Q:</e> I can change the CPU frequency, but the range is not as wide as in
>another OS.
>
>
>
><e>A:</e> You can combine frequency scaling with ACPI throttling to get a lower
>minimum frequency. Notice that throttling doesn't save much energy and is
>mainly used for thermal management (keeping your laptop cool and quiet). You
>can read the current throttling state with <c>cat
>/proc/acpi/processor/CPU/throttling</c> and change it with <c>echo -n "0:x" >
>/proc/acpi/processor/CPU/limit</c>, where x is one of the Tx states listed in
><path>/proc/acpi/processor/CPU/throttling</path>.
>
>
>
><e>Q:</e> When configuring the kernel, powersave, performance and userspace
>governors show up, but that ondemand thing is missing. Where do I get it?
>
>
>
><e>A:</e> The ondemand governor is only included in recent kernel sources. Try
>updating them.
>
>
>
><e>Q:</e> Battery life time seems to be worse than before.
>
>
>
><e>A:</e> Check your BIOS settings. Maybe you forgot to re-enable some of the
>settings.
>
>
>
><e>Q:</e> My battery is charged, but KDE reports there would be 0% left and
>immediately shuts down.
>
>
>
><e>A:</e> Check that battery support is compiled into your kernel. If you use
>it as a module, make sure the module is loaded.
>
>
>
><e>Q:</e> I have a Dell Inspiron 51XX and I don't get any ACPI events.
>
>
>
><e>A:</e> This seems to be a kernel bug. Read on <uri
>link="http://bugme.osdl.org/show_bug.cgi?id=1752">here</uri>.
>
>
>
><e>Q:</e> I just bought a brand new battery, but it only lasts for some
>minutes! What am I doing wrong?
>
>
>
><e>A:</e> First follow your manufacturer's advice on how to charge the battery
>correctly. 
>
>
>
><e>Q:</e> The above didn't help. What should I do then?
>
>
>
><e>A:</e> Some batteries sold as "new" are in fact old ones. Try the following:
>
>
><pre caption="Querying battery state">
>$ grep capacity /proc/acpi/battery/BAT0/info
>design capacity: 47520 mWh
>last full capacity: 41830 mWh
></pre>
>
>
>If the "last full capacity" differs significantly from the design capacity,
>your battery is probably broken. Try to claim your warranty.
>
>
>
><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?
>
>
>
><e>A:</e> Don't fear to contact me, <mail link="fragfred@gmx.de">Dennis
>NienhÃ¼ser</mail>, directly.
>
>
></body>
></section>
></chapter>
></guide>

Actions: View

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