Copia del acpi how to
Nota: Esta página contiene una copia del documento ACPI-HOWTO tomada de su página original por que el mejor enlace de hoy es potencialmente el 404 del mañana
Linux ACPI-HOWTO, The Sequel
Ariel Glenn
<[1]ariel@columbia.edu>
2005-10-19
Revision History
Revision 0.2e Revised by: atg
update [FIXME] list; custom DSDT in kernel and in initrd; initramfs notes;
overview of ACPI tables; lvm corrections
Revision 0.2d Revised by: atg
2.6.14-rc4; Nvidia driver with swsusp2 notes; swsusp3 notes; ACPI4Linux wiki
live again; swsusp* comparison
Revision 0.2c Revised by: atg
Nvidia console switching problem for swsusp1 noted; swsusp2 notes;
2.6.14-rc3; ^T and other typos
Revision 0.2b Revised by: atg
Software Suspend (swsusp1) notes added; Dave Jones in credits
Revision 0.2a Revised by: atg
Clean up markup and typos; update Jens Axboe SATA patch info; 2.6.14-rc2;
video patch not needed
Revision 0.2 Revised by: atg
Get a laptop 4 years later and rewrite the whole fscking thing for kernel
2.6.13
Revision 0.1e Revised by: atg
Fix typos; move full text of GPL to separate document; bug reports now go to
Andy Grover
Revision 0.1d Revised by: atg
Added information about libpopt, required for build of acpictl (included in
acpid)
Revision 0.1c Revised by: atg
describe pmtest util, /proc interface, reduced functionality of new acpid,
changes to driver options
This document provides an overview of the ACPI subsystem in Linux, including
kernel configuration, acpid support daemon, supporting user applications,
and common problems.
_________________________________________________________________
Table of Contents
1. [2]About this document
1.1. [3]Introduction
1.2. [4]Copyright and License
1.3. [5]Disclaimer
1.4. [6]Credits/Contributors
1.5. [7]Feedback
1.6. [8][FIXME]s
2. [9]Overview of ACPI
2.1. [10]What is power management?
2.2. [11]What is ACPI?
2.3. [12]What is the difference between ACPI and APM?
2.4. [13]What ACPI capabilities are supported under Linux?
3. [14]Hardware requirements
3.1. [15]What hardware is supported?
3.2. [16]What devices are supported?
3.3. [17]Which BIOSes are supported?
3.4. [18]How can I tell if my BIOS supports ACPI?
3.5. [19]When will my (unsupported) laptop be supported?
4. [20]Software requirements
4.1. [21]Which kernels are supported?
4.2. [22]What are the latest acpi driver / supporting utilities and
where can I get them?
4.3. [23]Are binary distributions available?
5. [24]Compilation and installation
5.1. [25]Prerequisites and kernel setup
5.2. [26]Useful BIOS settings
5.3. [27]Boot parameters
6. [28]The acpid event handling daemon
6.1. [29]What is acpid and where do I get it?
6.2. [30]How do I build and install acpid?
6.3. [31]How do I use acpid?
6.4. [32]What events will acpid respond to?
6.5. [33]How can I keep track of what acpid thinks it's doing?
6.6. [34]Where can I find other cool acpid scripts?
7. [35]CPU management under ACPI
7.1. [36]CPU management overview
7.2. [37]CPU idle power states
7.3. [38]CPU frequency management
7.4. [39]CPU throttling
8. [40]Thermal management
8.1. [41]Overview of thermal management
8.2. [42]What are thermal zones?
8.3. [43]What are cooling modes and how do I change them?
8.4. [44]What are trip points and how do I set them?
8.5. [45]What are throttling/performance state limits and how do I use
them?
9. [46]ACPI generic hotkey driver
9.1. [47]What is the generic hotkey driver and how do I use it?
9.2. [48]How can I tell if my laptop supports the generic hotkey
driver?
9.3. [49]How can I get the ACPI event number for my hotkey?
9.4. [50]How do I set up a hotkey function?
9.5. [51]What are the hotkey driver event numbers?
9.6. [52]What should acpid do after I press a hotkey?
9.7. [53]Where do I find ACPI bus names and device paths?
10. [54]Suspend to RAM
10.1. [55]How do I suspend to RAM?
10.2. [56]My video isn't working; what now?
10.3. [57]What utilities are there that I can use for this?
10.4. [58]How about suspend to RAM when I close my laptop?
10.5. [59]My usb/pcmcia/other device doesn't work when the system
resumes; what can I do?
10.6. [60]Suspend to RAM just doesn't work after everything I've tried;
what now?
11. [61]Suspend to disk
11.1. [62]How do I suspend to disk?
11.2. [63]Which should I use, swsusp1, swsusp2, or swsusp3?
11.3. [64]What utilities are there that I can use for this?
11.4. [65]My usb///other device doesn't work when the system resumes;
what can I do?
11.5. [66]Suspend to disk just doesn't work after everything I've
tried; what now?
12. [67]Vbetool
12.1. [68]What is vbetool and where do I get it?
12.2. [69]How do I build vbetool?
12.3. [70]How do I use vbetool?
13. [71]Patches
13.1. [72]SATA driver
13.2. [73]Radeonfb patches
13.3. [74]VGA post
13.4. [75]Ethernet cards
13.5. [76]Yenta CardBus socket
14. [77]Debugging tips
14.1. [78]The driver isn't working right for me. How can I figure out
what's wrong?
14.2. [79]DSDT editing
14.3. [80]Last ditch efforts
14.4. [81]Submitting useful bug reports
15. [82]Extracting ACPI tables with pmtools
15.1. [83]Compilation and installation of pmtools
15.2. [84]Using pmtools
16. [85]ASL compiler / AML disassembler iasl
16.1. [86]What is iasl and where do I get it?
16.2. [87]How do I build iasl?
16.3. [88]How do I use iasl?
17. [89]dmidecode
17.1. [90]What is dmidecode and where do I get it?
17.2. [91]How do I compile and install dmidecode?
17.3. [92]How do I use dmidecode?
18. [93]ACPI details
18.1. [94]What are all these power states C1, S4, D3, etc?
18.2. [95]What are all these ACPI tables, DSDT, FADT, and so on?
19. [96]Other information sources
19.1. [97]Mailing lists
19.2. [98]ACPI on Linux laptops
19.3. [99]Other HOWTOS
19.4. [100]Useful papers
19.5. [101]Official specifications
19.6. [102]ACPI on x86_64 and other architectures
20. [103]CPU_FREQ reference
20.1. [104]CPU frequency managers
20.2. [105]CPU frequency drivers
20.3. [106]How do I regulate my CPU frequency?
21. [107]Kernel configuration reference
22. [108]Boot parameter reference
23. [109]Sysfs entries reference
23.1. [110]Overview of /sys entries
23.2. [111]Power entries in /sys
23.3. [112]Hotpluggable devices and /sys entries
23.4. [113]CPU power states (C-States) and /sys entries
23.5. [114]CPU frequency management and /sys entries
23.6. [115]ACPI namespace tree and /sys
24. [116]Proc entries reference
24.1. [117]Overview of /proc entries
24.2. [118]Wake on RTC alarm entry
24.3. [119]ACPI info entry
24.4. [120]DSDT entry
24.5. [121]FADT entry
24.6. [122]Event queue for acpid
24.7. [123]Embedded Controller entry
24.8. [124]Battery info
24.9. [125]Button entries
24.10. [126]Fan control
24.11. [127]Power resources
24.12. [128]CPU entries
24.13. [129]Sleep (deprecated)
24.14. [130]Thermal zone info
24.15. [131]Video adapter and display entries
24.16. [132]Wake capabilities
25. [133]Modified acpixtract
1. About this document
1.1. Introduction
ACPI, which stands for Advanced Configuration and Power Interface, is the
successor to APM (Advanced Power Management). The specification provides for
many functions besides power management, such as thermal management and
plug-and-play events. This document covers those functions supported by
Linux to-date. This document describes how to compile, install, and use the
ACPI driver for Linux and its associated applications.
I test ACPI on a 32-bit x86 system, so this document is biased towards that
hardware. In particular, I do not discuss the ARM or x86_64 implementations
at all, SMP systems, nor ACPI on embedded systems. For information on those
topics, see the links in [134]ACPI on other architectures.
The current Linux kernel is 2.6.14-rc4. This document covers configuration,
installation, patches and problems for2.6.14-rc3 except for swsusp3, which
has been tested only for 2.6.14-rc4. Some options or capabilities discussed
here may not be available in earlier 2.6 or 2.5 series kernels. For
information about the (early) 2.4 kernel series, please check the previous
EXTREMELY old version of this document, at
[135]http://www.columbia.edu/~ariel/acpi/acpi_howto-01e.txt.
The current version of this document can always be found at
[136]http://www.columbia.edu/~ariel/acpi/acpi_howto.html. You can also find
other formats of this document at [137]http://www.columbia.edu/~ariel/acpi/.
_________________________________________________________________
1.2. Copyright and License
This document, ACPI HOWTO, is copyrighted (c) 2005 by Ariel T. Glenn.
Permission is granted to copy, distribute and/or modify this document under
the terms of the GNU Free Documentation License, Version 1.2, or any later
version published by the Free Software Foundation; with no Invariant
Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of
the license is available at [138]http://www.gnu.org/copyleft/fdl.html.
Linux is a registered trademark of Linus Torvalds.
_________________________________________________________________
1.3. Disclaimer
This document is provided ``AS IS'', with no express or implied warranties.
No liability for the contents of this document can be accepted. There may be
errors and inaccuracies that could be damaging to your system. The author(s)
do not take any responsibility; use the concepts, examples and information
at your own risk.
All copyrights are held by their by their respective owners, unless
specifically noted otherwise. Use of a term in this document should not be
regarded as affecting the validity of any trademark or service mark. Naming
of particular products or brands should not be seen as endorsements.
_________________________________________________________________
1.4. Credits/Contributors
I've been paying great attention to the postings of Len Brown, Matthew
Garrett, Pavel Machek, Jon Smirl, Li-Ta Lo, and Carl-Daniel Hailfinger. Dave
Jones' posts got me through swsusp with swap on LVM on Fedora. Emma Jane
Hogbin nagged me last year to get back to work on this stuff so I finally
did. The City of Oakland kindly provided money for this laptop (lawsuit
settlement, that's another story). Greg Michalec is loaning me hardware to
test suspend on ATI Radeon hardware. My housemates endured long days of
obscure rambling about these topics. Thanks to everyone.
_________________________________________________________________
1.5. Feedback
Please send suggestions, complaints or comments about this document to
ariel@columbia.edu. Please do NOT send me bug reports about the driver; see
[139]Submitting useful bug reports for more information on reporting ACPI
bugs.
_________________________________________________________________
1.6. [FIXME]s
This document is a work in progress. Since it's been 4 years since I updated
this, there has been a lot of catching up to do. I have left some sections
blank and they'll get filled in Real Soon Now. Other sections are marked
with the warning [FIXME] which tells me I have more work to do on that
section, and it tells you that you should be extra careful when using
information from that section. Thanks for your patience.
* I heard rumors that the earlier nVidia X drivers, version .6xxx, may
suspend to RAM properly where the .7xxx series does not. I need to test
this.
* I have not worked with the Radeon patches, though a friend of mine has
generously offered to let me borrow his hardware to do some testing.
* If there are utilities for suspend to RAM/disk or additional notes on
suspend on lid close, I should add them, or remove those sections.
* Some kernel CONFIG options have yet to be documented, and explanations
of a few of the boot parameters are incomplete.
* I need to add pointers to information for ACPI on other architectures,
especially 64-bit platforms. First, there needs to be some information.
*sigh*
* The description of the /proc interface for the video driver is almost
nonexistent.
* There should be more examples of acpid event handling scripts.
* Clean up and fill out documentation of how to trigger debugging for
select pieces of acpi/suspend/hotkeys drivers.
* Write up polling method for hotkeys driver.
* Document how to do suspend to disk with raid. [How can I do this without
testing?]
* Fill out the comparison for the various suspend to disk patchsets.
* Detail more steps for debugging when suspend to disk doesn't work.
* Test and document suspend to file with swsusp2.
_________________________________________________________________
2. Overview of ACPI
2.1. What is power management?
Power management is a catch-all term for functionality that lets you
conserve power or use power resources for your computer more efficiently.
For example, you may wish to reduce the brightness of your LCD panel when
you're running your laptop off of batteries, or you may want your CPU to run
in a lower power state if it's idle, or you may want the system to hibernate
after 20 minutes if you haven't been typing. All of these are examples of
power management.
These days, power management includes support for things like automated
system wakeup at a given time, switching video displays, and monitoring fan
speed or chipset temperature. Eventually it will probably grow to replace
the desktop OS. (Just kidding...)
_________________________________________________________________
2.2. What is ACPI?
ACPI, or Advanced Configuration and Power Interface, is a set of
specifications for power management functions of devices and the OS
interface to them. It consists of descriptions of power specifications for
classes of devices that describe which power states and what other
functionality a class of devices must support, the definition of AML, an
interpreted language for describing these various functions, and a
description of how the OS calls these functions and in what context.
You may want ACPI if you are running a laptop and power conservation is a
big concern, or if you want to put your desktop system to sleep during
inactive periods, or if you want to monitor the temperature of various
chipsets and to increase or decrease fan speed depending on those
temperatures. You may want it so that you can shut your laptop lid, take
your laptop to work, and open it up again, ready to go at the touch of the
power button. And your computer vendor may expect you to be using ACPI so
that the OS will take appropriate action if the CPU or other chipsets get
too hot.
But I prefer to think of ACPI not as an optional add-on component but as an
integral part of your system; in today's world, where we are all conscious
of our energy use and we don't think twice about turing off the light switch
when we leave a room, enabling basic ACPI functionality is common sense.
In very specific cases you may be required to enable ACPI for your system to
function properly. 64-bit Itanium platforms require this; you won't get a
choice in the kernel configuration menu to choose it or not, it will just be
done for you. NUMA-enabled systems often require it, and systems with new
Intel processors that support hyperthreading require it because they use
ACPI tables for virtual processor discovery.
_________________________________________________________________
2.3. What is the difference between ACPI and APM?
APM, or Advanced Power Management, is the predecessor to ACPI. It required
the BIOS to handle all power management. Devices were put into lower power
states based on device activity timeouts. Only standby and hibernate system
sleep states were supported. Some power management features such as reducing
power usage of various devices when switching from ac adapter to battery
were not implemented because this would have required building support for
more power states and for various power usage policies directly into the
BIOS. Adoption of the ACPI standard started in 1997 when developers
understood that putting most of the code in the OS would allow for more
features and greater flexibility. Version 3.0, the current ACPI
specification, was released in 2004.
The Linux APM driver is very stable. It supports standby and hibernation,
but some newer systems may not have support for APM in the BIOS at all.
Although APM support in the kernel is very mature, patches still come in
once in a while. ACPI, by contrast, is under furious development. A feature
may be broken in one release, work in the next, and disappear completely in
the next. This is no joke. As I type this, the latest FC4 kernel
(2.6.12-1.1447_FC4) has suddenly made the /proc/acpi/button directory
disappear; acpid relies on this to do the right thing (TM) when you close or
open your laptop, or press the power button on resume. It was there in the
previous version; an overaggressive patch in 2.6.13-rc5 made it go away.
_________________________________________________________________
2.4. What ACPI capabilities are supported under Linux?
As of kernel 2.6.13, you can do the following (if you are lucky):
* Suspend to RAM (S3 power state)
* Suspend to disk (S4 power state)
* Enter standby (S1 power state)
* monitor your battery and set an action to take on low charge
* monitor CPU temperature and set actions to take when it gets too hot
* monitor CPU speed, throttle your CPU, and put your CPU into different
power states
* monitor and turn on or off your fan
* change your video display brightness, or enable an external video
display
* Set an action to take when you close your laptop
* Set an action to take when you press the power or sleep button
* Set your system to wake on a certain event
* And much more to come!
Not all of these may work depending on what your particular hardware/BIOS
setup supports and on the state of linux support for that hardware.
_________________________________________________________________
3. Hardware requirements
3.1. What hardware is supported?
Older systems have only APM support. In general, if you are working with
hardware that is older than 1997, it will not have ACPI support, and if it's
older than 2000, it will have only limited support.
Support for modern ATI and nVidia video chipsets is spotty under Linux.
Older video chipsets tend to have better support. Cards based on the ATI
Radeon have support with workarounds. This is very dependent on the version
of X you happen to be using, and on the version of any X proprietary driver
as well. [FIXME should test with earlier .6xxx nVidia to see if suspend
works, just for shits and grins]
For comprehensive lists of laptops, their configuration, and their
functionality under ACPI in Linux, see [140]ACPI on Linux laptops.
_________________________________________________________________
3.2. What devices are supported?
Suspend/resume for SATA devices is not working well yet. Jens Axboe has a
patch that will help for some users; see the [141]SATA driver section for
more.
Brightness controls for LCD panels is sometimes not controllable by ACPI;
often, the vendor uses some proprietary method, having the BIOS adjust
brightness directly when certain hotkeys are pressed. In this case you are
liable to see odd messages in your log like these:
kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x85 on is
a0060/serio0).
kernel: atkbd.c: Use 'setkeycodes e005 <keycode>' to make it known.
Various ethernet cards have problems, but there are patches. See the
[142]Ethernet cards section for more.
ATI Radeon cards usually need help for suspend to RAM. See the [143]RadeonFB
patches section for more. [FIXME and see if this helps X].
See also the note above about supported hardware for information about other
video devices.
_________________________________________________________________
3.3. Which BIOSes are supported?
Any BIOS that claims to support ACPI can be used under Linux. In practice,
BIOSes older than 2001 that claim to have ACPI support are often broken.
Current BIOSes are often broken too because they have broken DSDT tables or
missing ECDT tables.
If your DSDT is buggy, in the best case, Linux ACPI functionality will be
enabled but some functions will not work; in the worst case, your system may
freeze. Fortunately, there is often a workaround available. See [144]DSDT
editing for more information.
If your ECDT is missing, there's a boot parameter, acpi_fake_ecdt, which can
help you. See [145]Boot parameters reference for more information.
Some BIOSes are known to be broken and they are included in a blacklist in
the ACPI driver. Systems with those BIOSes at this writing are:
* Compaq Presario 1700
* Sony FX120, FX140, FX150M
* Compaq Presario 800, Insyde BIOS
* IBM 600E
* all systems with ASUS P2B-S BIOS
_________________________________________________________________
3.4. How can I tell if my BIOS supports ACPI?
The most reliable way to tell is to boot with an ACPI-enabled kernel and
look for ACPI messages in the log. You should see at least
kernel: ACPI: Interpreter enabled
and messages like this if you have PCI slots:
kernel: ACPI: PCI Interrupt 0000:00:1d.7[A] -> Link [LNKA] -> GSI 11 (l
evel, low) -> IRQ 11
If you see messages like this:
ACPI: System description tables not found
ACPI-0084: *** Error: acpi_load_tables: Could not get RSDP, AE_NOT_FOUN
D
ACPI-0134: *** Error: acpi_load_tables: Could not load tables: AE_NOT_F
OUND
ACPI: Unable to load the System Description Tables
then your BIOS does *not* have ACPI support.
If you want other ways to check your system, you can look at your BIOS
settings; many systems have ACPI-related options in their BIOS menus, though
not all. For example, the Dell XPS Gen 2, while fully ACPI-compliant, has no
mention of ACPI in the BIOS settings at all.
You can also run acpidump, which is packaged with most distributions. To run
it, be root and at the command prompt, type acpidump.
If your system is ACPI-compliant, acpidump should print out a long list of
tables and their contents, including the RSDT and the DSDT. If you don't see
a line something like
DSDT @ [some hex address here]
you may have a problem. If acpidump produces no output, it probably has
failed to find any tables. Check the exit code; if it's 0x0005 then you
(probably) don't have ACPI support at all.
If you want to look through memory yourself, and you have 32-bit hardware
which is not EISA/MCA based, you could try looking for "RSD PTR" in 0e0000h
through 0fffffh by grepping it out of /dev/mem, like this:
# dd if=/dev/mem of=blot bs=64K skip=14 count=2
# od -c -A x blot | grep 'R S D'
01c9b0 R S D P T R 312 D E L L \0
If you see output like this, you know you have the root table stricture for
ACPI, which means that you have at least some degree of support.
Note that none of these methods guarantee that the BIOS support for ACPI is
bug free, just that it exists.
_________________________________________________________________
3.5. When will my (unsupported) laptop be supported?
If the problem is related to the video card, and you're using a proprietary
driver, the outlook is not good. It depends however on your particular card
and BIOS. If posting your video card after resume helps your problem, then
eventually that will be fixed because sooner or later that code will make it
into X or into the kernel. It's also possible that your video card vendor
may provide X drivers that do the proper card reinitialization at some
point.
If the problem is related to hotkey support, some laptops have specific
hotkey drivers, but a generic hotkey driver is available which you should
check out as well. See the [146]Kernel configuration reference for the
CONFIG_ACPI_HOTKEY option.
Detailed bug reports are extremely helpful, as are volunteers to do testing
and debugging on their hardware. See [147]Debugging tips to get started.
_________________________________________________________________
4. Software requirements
4.1. Which kernels are supported?
All Linux 2.6 kernels and the current 2.4 series have ACPI support out of
the box. If you are running one of the 2.2 series, you are out of luck. Not
all new features from 2.6 are backported into the 2.4 series kernels. Your
favorite distribution probably has ACPI support turned on by default.
Checked for: Fedora Core x; Suse 9.x; Debian 3.x, Ubuntu, Gentoo.
If a feature doesn't work for you in one kernel, try the next one, or even
an rc intermediate release, because so much changes from one week to the
next.
For the very latest in ACPI support, however, you should build your own
kernel and look at the most recent ACPI patches, as there is much hard work
being done on this subsystem. The most recent patches can be found at
[148]ftp://ftp.kernel.org/pub/linux/kernel/peple/lenb/acpi/patches/release/.
_________________________________________________________________
4.2. What are the latest acpi driver / supporting utilities and where can I get
them?
Basic ACPI support is included in the linux kernel. You need acpid if you
want to capture ACPI events and take certain actions based on those events.
You do not need to use acpid if you want to do suspend to RAM or suspend to
disk and you are willing to run a script by hand or work directly with the
sysfs interface. If you want to be able to shut down cleanly by pressing the
power button, you should use acpid; in addition, if you want to hibernate or
suspend on laptop lid close, you need acpid. See [149]the acpid event
handling daemon to learn how to build and use it.
Here are some of the userspace utilities for ACPI power management. You
don't have to use any of them to get ACPI functioning, but they can be much
more convenient than accessing /proc/acpi or sysfs directly. This is not
meant to be a comprehensive list. However, if you know of an application
that is currently maintained and that you think should be on this list,
[150]let me know.
* acpitool -- command line utility to get battery/fan/temperature/cpu
information or to suspend to RAM/disk, turn on/off fans, and control
wakeup capable devices
* battstat-applet-2, bbacpi, wmacpi -- battery monitoring
* wmpower, yacpi -- battery, temperature and other monitoring
* powersave, with front ends kpowersave, gkrellm-powersave, wmpowersave --
all purpose utility covering APM, ACPI and other power management
features
* xrg -- all purpose monitor that watches everything from CPU activity and
battery status to the weather and stock market data
*
_________________________________________________________________
4.3. Are binary distributions available?
All major distributions come with ACPI support built into the kernel by
default. Fedora ships out of the box with acpid and battstat-applet-2,
Debian has acpid and wmacpi, Suse has acpid and powersave, and Gentoo has
acpid and quite a number of monitoring/power management utilities. Check
your distribution's documentation to see what prepackaged options you have.
_________________________________________________________________
5. Compilation and installation
5.1. Prerequisites and kernel setup
To build your own kernel with ACPI support, you need the following:
Make sure that you're building with the appropriate version of gcc (at this
writing, at least version 3.2).
Turn on these configuration options for base ACPI support: CONFIG_PM,
CONFIG_ACPI and CONFIG_PNPACPI.
For ACPI control of some basic devices, set these: CONFIG_ACPI_AC,
CONFIG_ACPI_BATTERY,CONFIG_ACPI_BUTTON,CONFIG_ACPI_VIDEO,CONFIG_ACPI_FAN,
CONFIG_ACPI_PROCESSOR, and CONFIG_ACPI_THERMAL.
For suspend to RAM, set CONFIG_ACPI_SLEEP, and for suspend to disk, set
CONFIG_SOFTWARE_SUSPEND, and also supply the name of the partition reserved
for writing suspend data to CONFIG_PM_STD_PARTITION. NOTE: if you are
suspending from something other than a standard swap partition, read the
[151]Suspend to disk section because you may want to set
CONFIG_PM_STD_PARTITION to "".
For more details on these config options or for the other kernel
configuration options for ACPI, see the [152]Kernel configuration reference.
_________________________________________________________________
5.2. Useful BIOS settings
Most ACPI-capable BIOSes have settings that the user can tweak for power
management. For example, recent versions of the AMI BIOS have an entire
section for ACPI settings, including ACPI-Aware OS, ACPI 2.0 compliance,
BIOS->AML ACPI table, all of which should be enabled; Suspend to RAM
support, and Repost video on S3 resume which may be useful if your video
doesn't come back after resume from suspend to RAM. Check your BIOS to see
what power management features it offers you.
If you see APM settings in your BIOS you can ignore those. As long as you
have ACPI built into your kernel and enabled, the APM settings will not be
used.
_________________________________________________________________
5.3. Boot parameters
You should not need to pass any special boot parameters once ACPI is built
into the kernel. If you run into problems, or you have special requirements,
check the [153]Boot parameters reference for a comprehensive list.
_________________________________________________________________
6. The acpid event handling daemon
6.1. What is acpid and where do I get it?
Older versions of acpid used to act as an intermediary between the kernel
and the BIOS, looking up hex values that could be used to invoke certain
sleep types and installing sleep methods; it also used to provide battery
information and it had the entire AML interpreter in it. But it didn't
support suspend to disk or suspend to RAM.
These days, the entire interpreter for AML now lives in the kernel. I
stopped maintaining this document shortly after that patch
[154](http://www.linuxhq.com/kernel/v2.4/3-ac8/acpi-20010413.diff) got
accepted about 4 years ago. It singlehandedly added around 72000 lines of
code to the kernel. One developer [fn1] is pretty sure that ACPI was
designed by a bunch of monkeys on LSD, but if it had, it would at least be
visually appealing. And this ain't.
OTOH, the acpid daemon has become much simpler. It now watches for all
acpi-generated events and allows the user to define the appropriate action
to take on receiving those events.
Most distributions come with acpid out of the box. If you want to build your
own, you'll find the latest version at
[155]http://sourceforge.net/projects/acpid/
[fn1] See [156]http://lkml.org/lkml/2005/7/31/219.
_________________________________________________________________
6.2. How do I build and install acpid?
Make yourself a build directory and untar the file: zcat acpid-1.0.4.tar.gz
| tar xvfp - cd into the directory: cd acpid-1.0.4
If you download the tarball, edit the Makefile if you're using gcc 4.x:
change the line CFLAGS = -Wall -Werror -g $(DEFS) to read CFLAGS = -Wall -g
$(DEFS) (This is fixed in cvs.)
build it: make install it: make install This puts acpid in /usr/sbin and
acpi_listen in /usr/bin It also installs the man pages.
These programs use /proc/acpi/events (boo). When will they use /sys?
_________________________________________________________________
6.3. How do I use acpid?
Linux sees ACPI events, in some cases takes an action, and then writes a
description of the event to /proc/acpi/events so that userspace applications
can take actions as well. Acpid watches /proc/acpi/events and, for every
event logged there, looks at its set of rules to see what action(s) to take.
These actions are specified by you, the user.
Acpid looks for its rules by default in /etc/acpi/events at all files in
that directory (no subdirectory walking though). Each file in there is
expected to contain rules that tell acpid what to do on each event.
Each file may have blank lines or comments starting with # Then you must
include at least one line defining an event and one line defining an action.
Here's an example:
# This is a sample ACPID configuration
event=button/power.*
action=/sbin/shutdown -h now
That file ships with Fedora Core 4 and tells acpid to shut down when the
power button is pressed (so you don't have to give the three-finger salute).
%e and %% are special strings; if you use %e in the event description or in
the action description, the full text of the event as described in the
previous section will be substituted into the string, and if you use %% in
either description, the character % will be substituted in. If you use % in
any other combination, you'll get an error.
You can define multiple actions for the same event, but they won't
necessarily be processed in the order you list them in the file.
You can also put multiple event lines in one file and use the same action
for all of them. [FIXME examples would be nice]
If you have acpid source from CVS or tarball, you can look at more
interesting examples such as the battery.sh script which is intended to be
used from one of these rule files. It reacts on any battery event, checks to
see whether the system is on AC or battery, and sets or disables hard drive
spindown time appropriately. Note that this script may not work for you out
of the box, as your AC adapter may have a different name (mine is called
/proc/acpi/ac_adapter/AC); it's here as an example only.
On FC4 you are expected to put all your fancy scripts into /etc/acpi/actions
but nothing in the acpid code requires this. Put them where you want.
_________________________________________________________________
6.4. What events will acpid respond to?
It is not possible to provide a comprehensive list, because the list of
events depends on your vendor's hardware and their ACPI implementation.
However, it is possible for you to figure out what events will be issued on
your hardware by looking at /sys/firmware/acpi and collecting some
information.
First, let's see what an event looks like. If you are running acpid, and you
are running ACPI with any applet to monitor battery status of control cpu
speed, you can look in /var/log/acpid at events it has received. You may see
messages like this:
completed event "processor CPU0 00000080 00000004"
received event "ac_adapter AC 00000080 00000001"
received event "battery BAT0 00000080 00000001"
received event "button/power PBTN 00000080 00000001"
Each event as logged consists of the device class name, the bus id name, the
event type, and the event data. Device class names are standardized, and you
can get the list by looking for all #defines of "CLASS" in the kernel code
in drivers/acpi. My list is:
ac_adapter, battery, button, container, embedded_controller, fan, Hotkey
(because the asus driver got the word "hotkey"), lid, memory, pci_bridge,
pci_irq_routing, power, power_resource, processor, sleep, system_bus,
system, thermal_zone, video
Note that some of these are subclasses; power, sleep and lid are subclasses
of button, and they'll get written as button/lid, button/power and
button/sleep in the log.
Bus IDs are not standardized; they are defined in a vendor's implementation.
Fortunately, the names vendors use are similar and usually recognizable.
You can find out which Bus IDs your vendor is using on your current hardware
by looking in /sys/firmware/acpi/namespace/ACPI/. My system shows
ls /sys/firmware/acpi/namespace/ACPI/
CPU0 CPU1 _SB _TZ
ls /sys/firmware/acpi/namespace/ACPI/_SB
AC BAT0 LID MB1 PBTN PCI0 SBTN
ls /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/
AGP AUD IDE0 ISAB LNKA LNKB LNKC LNKD LNKE LNKF LNKH MB2 MB3
MODM PCIE USB0 USB1 USB2 USB3 USB4
You may decide you don't need to know what the event type is; for example,
if you get a battery event, you might look at /proc/acpi/battery/BAT0/info
(or BAT1/state, or whatever your battery device is called), check the
remaining capacity and take any appropriate actions.
However, there is a list of event types in the ACPI specification. Here's
the summary:
For all devices, 0 = bus check (time to rescan the bus); 2 = device removed
or added; 3 = device awakened; 4 = device eject, 5 = device removed or added
("device check light", don't ask me what the difference between this and 2
is); and some other events that you probably won't care about as a user. See
page 142 of the specification if you want the rest.
For specific devices:
Battery: 0x80 = battery status changed, 0x81 = battery information has
changed (i.e. you have a different battery in there now); 0x82 = check
battery maintenance flags.
Power source: 0x80 = power source status changed. (Think AC adapter.)
Thermal zone: 0x80 = thermal zone temperature changed; 0x81 = thermal zone
trip points changed; 0x82 = thermal zone device lists changed; 0x83 = values
in thermal relationship table changed
Power button: 0x80 = power button pressed. Warning: If the power button is
pressed with the system in S1 through S4, you will not see this event;
instead you will see a Device Wake (0x02)!
Sleep button: 0x80 = sleep button pressed. Warning: If the sleep button is
pressed with the system in S1 through S4, you will not see this event;
instead you will see a Device Wake (0x02)!
Lid: 0x80 = Lid status changed (either open or closed).
Processor: 0x80 = number of supported processor performance states (P
states) has changed; 0x81 = number or type of supported power states (C
states) has changed; 0x82 = number of supported throttling states has
changed.
video (part 1): 0x80 = state of one of the displays attached to the graphics
adapter has been toggled; 0x81 = re-enumerate all devices on the adapter
(i.e. a device has been added or removed); 0x82 = cycle display output (next
display activated and if the last one was active then the first one now is);
0x83 = next display activated; 0x84 = previous display activated. Note: for
these events, when a new display is activated, Linux deactivates the
previously active one. If you want more than one display to be active, you
should activate them by using the /proc/acpi/video/VID/*/state interface.
See [157]Proc entries reference for the /proc entries. Also, I'm unsure if
cycling the display output really should put you back to the first device if
you are at the end of the list; at least, Linux doesn't appear to do this,
from a quick scan of the code.
video (part 2): 0x85 = display brightness increased one level and if it was
at max, it got set to min level; 0x86 = display brightness increased one
level and if it was at max, it stayed there; 0x87 = display brightness
decreased one level and if it was at min, it stayed there; 0x88 = display
backlight turned off; 0x89 = display off WARNING: these values are right out
of the ACPI 3.0 spec. But they are not the values Linux uses! It uses: 0x82,
0x83, 0x84, 0x85, 0x86 for each of these things in order. Uh oh... I don't
have (ACPI) brightness control support, so I can't test this to see what
should happen. Anybody?
Some events that Linux passes on are not defined in the spec; that is, I
can't find a table with numbers for these. I got the values by looking for
invocations of acpi_bus_generate_event() in the kernel acpi driver code, and
checking the event passed in that function.
thermal zone: 0xf0 = critical temperature trip point is being passed which
requires immediate shutdown; at this point Linux will shut down by calling
/sbin/poweroff. You don't really have much time to process this event. :-)
0xf1 = critical temperature trip point is being passed which requires the OS
to put the system into S4 (hibernate) if that state is supported. The Linux
kernel does not yet do this. It has a comment placeholder where the code
ought to go.
If you use the generic hotkey driver (CONFIG_ACPI_HOTKEY), then when you
press an authorized hotkey, you'll get an event sent to /proc/acpi/events
for it. That list is described in [158]How do I use the hotkey driver?
No, I'm not documenting the state data; look it up your own darn self :-)
_________________________________________________________________
6.5. How can I keep track of what acpid thinks it's doing?
Acpid logs all of its activity to /var/log/acpid by default. Check your init
scripts to see where your distribution directs its logging.
You can also run acpi_listen. This command will connect to acpid and write
every event that acpid sees to stdout, in exactly the format the event
appears in /var/log/acpid, but without the extra commentary.
_________________________________________________________________
6.6. Where can I find other cool acpid scripts?
A few nice Thinkpad scripts can be found at
[159]http://www.thinkwiki.org/wiki/Category:Scripts
Unfortunately, scripts are very dependent on your particular hardware
configuration.
Some folks have put up acpid scripts on their pages describing the
installation of some distribution on their laptop. Check [160]these
resources for more information.
_________________________________________________________________
7. CPU management under ACPI
7.1. CPU management overview
ACPI gives you unprecedented control over your CPU's power consumption. You
can control power usage in three different ways: setting idling power
states, changing cpu frequency, and throttling the CPU.
_________________________________________________________________
7.2. CPU idle power states
First, the CPU can enter different idle power states, C1 through Cn (usually
C1 through C4). If a processor is in state C0, it is working normally; in
any other state, it is idle (doing no work). Lower power states use less
power but the CPU will take longer to transition to a higher power state. So
if your CPU is in C4 it will use less power than in C3 but it will take
longer to come out of idle than from C3.
You don't have to do anything to make the CPU go into the appropriate idle
state; the kernel will place the CPU into a lower power state automatically
when it is not busy. However, you do need to build this capacity into the
kernel by enabling CONFIG_ACPI_PROCESSOR. See the [161]kernel configuration
reference for the CONFIG options.
You can look at the /proc/acpi/processor/power file to see how long your CPU
spends in each state; see [162]Proc entries reference for more on this file.
You can also look at /sys/module/processor/parameters/max_cstate to see what
the lowest power state the kernel will give you is; see [163]Sysfs entries
reference for more on that.
And you can adjust max_cstate by using the processor.max_cstate boot
parameter. In some cases machines that enter C3 or C4 produce a loud whine,
and you may want to limit your system to C1 and C2. In some cases you may
want your system to enter C3 or C4 but it's been blacklisted by the kernel
and limited to C2; you can use this same parameter to override the
blacklist. See [164]Boot parameter reference for details.
_________________________________________________________________
7.3. CPU frequency management
Second, you can also run the CPU at lower frequencies when it isn't doing so
much work. If you're spending most of your time typing text instead of
compiling, this can be very useful for power savings. In ACPI lingo, the CPU
enters various P-States, P0 through Pn, where at P0, the CPU is running at
its highest frequency and at Pn it runs at a lower frequency the greater the
value of n. These performance states are only valid when the CPU is in power
state C0; the rest of the time the CPU is in some idle state and so
adjusting its clock frequency doesn't make any sense.
To benefit from this, you'll need to enable CPU frequency control by setting
CONFIG_CPU_FREQ. Then you can choose which of several performance managers
to build in; these adjust the frequency based on different criteria. Then
you can choose which hardware-level driver to build in. Only certain of
these drivers support ACPI P-States; the rest use a proprietary method of
regulating CPU frequency and are not discussed further in this document.
Further, of those that use the designated P-States, only the ACPI P-States
driver (CONFIG_X86_ACPI_CPUFREQ) actually notifies the ACPI subsystem of
P-State changes. If you think this is confusing, you're right.
After your kernel is set up, you can either use one of several userspace
applications to automatically set your CPU to a lower frequency depending on
the load, or you can use an applet that lets you set the frequency manually
as you desire, or you can use one of the performance managers that adjusts
frequency for you in kernel space. For all the details, see [165]CPU_FREQ
reference.
_________________________________________________________________
7.4. CPU throttling
Third, you can throttle your CPU. This means that you force the cpu to be
idle a fixed percentage of its cycles per second. Throttling states are
called T1 through Tn, where in T1 the CPU has no forced idle cycles, and the
percentage goes up the greater n is. For example, on my system, T4 forces
the CPU to be idle for half of the cycles.
This is different from changing the frequency, which makes the cpu have
fewer cycles per second, and it's different from running in a C state other
than C1, because those are states where the CPU is idle for all cycles.
If you have a certain amount of work to get done, then throttling the CPU
will cause the work to take longer to get done. However, if temperature is a
concern, then this will keep your CPU running cooler.
Note that this does not reduce voltage, and since all tasks will take longer
(since the CPU is forced idle part of the time), you actually use more power
to get any given task done. This is in contrast to CPU frequency management;
when the CPU frequency is lowered, voltage is lowered too, and any given
task should draw less power unless it requires the CPU to run full out for
the duration of the task.
You can check which throttling states are supported by your CPU by looking
at /proc/acpi/processor/CPU*/throttling. This file will also show you what
percentage of idle time each state enforces. You can set the current
throttling state for your CPU by writing the state number to
/proc/acpi/processor/CPU*/throttling. Read it back to make sure the change
works; if it doesn't, you may have a bug in your DSDT or elsewhere.
Note that throttling states only work when the CPU is in the power state C0.
But they work for any performance state (P-state); this means that no matter
what frequency the CPU is running at, you can still do throttling. For
information on how to do this, see [166]Thermal management.
_________________________________________________________________
8. Thermal management
8.1. Overview of thermal management
ACPI provides several means for monitoring and controlling system
temperature. Via thermal zones, you can adjust the system cooling mode when
it's too hot, you can turn on and off fans when you reach certain
temperatures, and you can throttle your CPU when it gets too hot, taking
into account the performance state it's running in. Not all platforms
support all of these features, but the ACPI 3.0 specification provides all
of these mechanisms.
_________________________________________________________________
8.2. What are thermal zones?
If your vendor's implementation of ACPI supports thermal management, you'll
have one or more thermal zones, which you can monitor by checking
/proc/acpi/thermal_zone for these devices. They'll be called something like
THM or THRM0.
I haven't seen a system with multiple thermal zones. Typically a system has
one big thermal zone which includes the entire interior region of the case.
Practically speaking, it must be connected to a sensor somewhere, probably
by the CPU.
Linux should poll the temperature every so many seconds. In practice,
however, Linux tries to figure out how often to poll by invoking the _TZP
method, which many vendors don't provide. When that fails, Linux disables
polling altogether. Fortunately, you can enable it by echoing a number to
the file, for example, echo 30 >
/proc/acpi/thermal_zone/*/polling_frequency, to have Linux check the
temperature every 30 seconds.
You can monitor the temperature for each thermal zone yourself by reading
the file /proc/acpi/thermal_zone/*/temperature.
_________________________________________________________________
8.3. What are cooling modes and how do I change them?
A cooling mode is a description of how your system is cooled in a certain
temperature range. Your cooling mode can be critical, passive, or active.
Active cooling means that a fan or other cooling device can be turned on
when the temperature passes a critical point. Passive cooling means that
devices can be put into a lower power state when the temperature is too hot.
Critical cooling means that when the temperature passes one trip point, the
so-called "hot point", the OS will transition into S4 (suspend to disk) if
possible, and if the temperature passes a second trip point, called the
"critical point", the OS will shut down the system.
If your platform supports it, Linux will set the cooling mode to active by
default. If this isn't successful, but both active and passive modes are
supported, then the cooling mode which supports the lowest trip point is the
one in use. If only one of passive or active cooling modes is supported,
Linux will use that. Failing that, it will fall back to critical cooling
mode, which must be supported by your vendor.
Some platforms allow you to change the cooling mode. You can do this by
echoing 1 to /proc/acpi/thermal_zone/*/cooling_mode to set passive cooling,
or 0 to /proc/acpi/thermal_zone/*/cooling_mode to set active cooling.
Critical cooling will always be active, in case your system heats up so much
that drastic measures must be taken, even with fan use or power reduction.
_________________________________________________________________
8.4. What are trip points and how do I set them?
Trip points are set temperatures that, when the system temperature reaches
them, trigger some sort of action. Typically this can be a change in cooling
mode, or something more drastic. The critical cooling mode has two
predefined trip points. If the system reaches the first one, called the "hot
point", Linux will try to put the system into S4 (suspend to disk) if
possible, and if the temperature passes the second one, called the "critical
point", Linux will call /sbin/shutdown -h now.
You can define multiple trip points each with their own cooling policy. If
you do, they'll show up in /proc/acpi/thermal_zone/*/trip_points like this:
critical (S5): 100 C
passive: 97 C: tc1=4 tc2=3 tsp=40 devices=0xcf6b6d80
You can set critical, hot, passive, and up to 9 active trip points. Here's
how you do it: echo a string of numbers to
/proc/acpi/thermal_zone/*/trip_points separated by a colon. These numbers
are the various trip points in Celsius. NOT IN Fahrenheit! So you *can* echo
99:80:35:75:60:55:50:45 > /proc/acpi/thermal_zone/*/trip_points to set the
critical trip point at 99C, the "too hot, suspend now" trip point at 80C,
the passive trip point at 35C, the first active trip point at 75C, the next
one at 60C, and so on through the fifth active trip point at 45C, but in
practice that's a lot of trip points. You probably only need one or two;
after all, how many extra fans do you have? However, Linux expects to see at
least 5 values, and if it doesn't see them it throws an error and refuses to
process the change. So even if your system only does passive cooling, you
must supply values for active[0] and active[1]. Just set them to 0 if they
don't make sense for your platform.
Unfortunately, if you write values to trip_points (at least 5) and these
other cooling methods are not supported, Linux will not inform you about it.
It will silently accept the values and move on. On my system I can't even
reset the lone critical trip point permitted me; but no errors are
generated; the only way I can tell is to read the trip_points file again and
see that it hasn't changed.
_________________________________________________________________
8.5. What are throttling/performance state limits and how do I use them?
These limits set the highest (highest frequency) P-State, and highest (least
throttling) T-state your platform is permitted to use under certain
circumstances, where P0 is a higher P-State than P1, and T0 is a higher
T-state than T1. Sorry for the lousy terminology.
You can see what the current throttling/p-state limit is, by looking at the
file /proc/acpi/processor/limit. Look at the active limit, which will show a
performance state, like P0, and then a throttling state, like T0.
To set a limit, write two numbers separated by a colon, like "0:0" into
limit. The first number is the processor performance state, and the next
number is the processor throttling state. This will set the user limit,
which you also see when you read that file. The active limit is chosen as
the maximum of the user and thermal limit T-state numbers; i.e. if the user
limit is T2 and the thermal limit is T3 then the active limit will be T3.
Unfortunately, Linux does not seem to use the first number for anything. It
always uses the value of 0 to update its internal copy of what it thinks the
P-State is for display in the limit file. Maybe that's ok, since it never
actually sets the P-State from that value :-(
Warning, esoterica: Only the ACPI P-States cpufreq driver updates the CPU's
P-States. This file could either show the actual P-State (and update it on
demand) for that one driver, or it could map frequency changes from all
drivers into P-States by name, and reflect the change by changing frequency
according to the registered cpufreq driver. Right now it just leaves the Px
value around in the limits file to be confusing to the user, the worst of
both worlds.
In any case, the second value does get stuffed into the user limit thermal
value, and you can verify that by reading the file. It takes effect
immediately. Note that the user limit can never be a higher (less
throttling) state than the thermal limit; for example, if the thermal limit
is T1, then the user limit cannot be T0.
_________________________________________________________________
9. ACPI generic hotkey driver
9.1. What is the generic hotkey driver and how do I use it?
The generic hotkey driver allows you to make those nifty hotkeys on your
laptop work. The concept is simple; your laptop has a hotkey that Linux
doesn't understand and that has no effect. You expect it to actually set the
brightness of your LCD to max, for example. So, you define a function that
includes the ACPI event number generated by your hotkey, the hotkey driver
event number that corresponds to the function you want the key to do (here,
increase brightness), information required to find the right video device,
and the ACPI method name for increasing brightness. Once the function is set
up, any time you press the hotkey, an event will be generated that acpid can
pick up, and once you define the right rule for acpid, you'll have your
hotkey working.
_________________________________________________________________
9.2. How can I tell if my laptop supports the generic hotkey driver?
This does not work for all laptops; your laptop must generate an ACPI event
when you press the particular hotkey you want to use. This means that in
your DSDT, you will have something like \_SB.PCI0.LPC.EC.HKEY.BTIN () (IBM
laptops), or Name (_HID, "ATK0100") (ASUS), or Device (HKEY) (Panasonic).
If you want to know if your hotkeys generate ACPI events, one way you may
test this is to turn on debugging (CONFIG_ACPI_DEBUG = y) in your kernel,
boot up, echo '0xffffffff' to both /proc/acpi/debug_level and
/proc/acpi/debug_layer, and then press a hotkey. Just one! Once! This will
either generate a lot of error messages in your log, or none at all. If it
generates none, you are out of luck. Otherwise, you should be able to use
this driver. [FIXME see which parts of the debug layer we can minimally turn
on to get useful messages.]
_________________________________________________________________
9.3. How can I get the ACPI event number for my hotkey?
You can try just pressing the key and see if anything shows up in
/var/log/messages. If not, you'll have to resort to the method described
above, i.e. build in ACPI debugging, turn on all debugging bits, and then
slog through the log.
The event number that your hotkey generates can then be retrieved by looking
for lines in your log like "ev_queue_notify_reques: Dispatching Notify(80)".
_________________________________________________________________
9.4. How do I set up a hotkey function?
Let's take our earlier example. Say your laptop has a hotkey that should set
the brightness of your LCD to max. So, you define a function that includes
the event number generated by your hotkey (which you must determine by
looking at log output after pressing the hotkey), the appropriate hotkey
driver event number, in this case 0x86, the ACPI bus name on your platform,
the ACPI full path name for your LCD, and the AML method you are going to
call, which in this case is _BCM, the AML method to control the brightness
level.
On my system, if Dell actually had hotkeys implemented through ACPI, which
it doesn't, I'd do the following:
echo '0:_SB::_SB.PCI0.AGP.VID.LCD:_BCM:128:136' > /proc/acpi/hotkey/eve
nt_config
I've used a made-up value for the event number generated by pressing the
hotkey, since Dell hotkeys don't generate ACPI events, but the rest is
correct for my platform. I could then verify that the setup worked by
looking in the log for errors and by reading /proc/acpi/hotkey/event_config,
which would give me
_SB_:LDD_:_DSS:128:136
Let's look at that in a little more detail. In the example above, we have 7
arguments, which you must always provide to add a new key. The first
argument must be 0 which indicates that this is a new key definition. The
second argument is the name of the bus on which your device sits that you're
going to affect; the LCD panel on my system is on the _SB bus. The third
argument must be omitted for event-based key definitions. The fourth
argument is the full ACPI namespace path name of the device, and the fifth
argument is the AML method you are going to call. The sixth argument is the
event number that your key press sends to the ACPI driver, and the seventh
argument is the hotkey driver event number which the driver will use to look
up the event in its tables. For the seventh argument, you can use any hotkey
event number you like (as long as it's known to the driver), but you may
kick yourself later when you have to read your script and understand what it
does.
You can also set up keys to use a polling method; I'll cover that in a
future version of this document. [FIXME]
Fun fact: you don't have to map the hotkey to a method that has anything to
do with the intended function of the hotkey, or with the intended meaning of
the event number you chose from the hotkey driver event list. So you could
map your wireless activation hotkey to turn of your fan via the _OFF control
method, if your fan supports that control method. I'm not saying you should;
I'm just saying you *could*.
To remove the key definition, just do echo '1:::::128:136' >
/proc/acpi/hotkey/event_config where the 128 should be replaced with the
actual ACPI event generated by the key press, and the 136 should be replaced
with the hotkey driver event number you actually used.
To change the definition, just put the new definition to
/proc/acpi/hotkey/event_config but use '2' as the first argument, which
indicates that the key definition already exists and should be updated with
the new values.
_________________________________________________________________
9.5. What are the hotkey driver event numbers?
The list, grabbed from hotkey.c, is
video (see video events above for more on what these do):
* 0x80, cycle output device hotkey pressed;
* 0x81, output device status change hotkey pressed (maybe it disconnects
one of the devices);
* 0x82, cycle display output hotkey pressed;
* 0x83, activate next display output hotkey pressed;
* 0x84, activate previous display output hotkey pressed;
* 0x85, cycle display brightness hotkey pressed;
* 0x86, increase display brightness hotkey pressed;
* 0x87, decrease display brightness hotkey pressed;
* 0x88, set display brightness to zero hotkey pressed;
* 0x89, turn display off hotkey pressed
sound (why are these here? they aren't ACPI related):
* 0x8a, volume mute hotkey pressed;
* 0x8b, volume increase hotkey pressed;
* 0x8c, volume decrease hotkey pressed
sleep states buttons:
* 0x8d, Suspend to Ram hotkey pressed,
* 0x8e, Suspend to disk hotkey pressed,
* 0x8f, Soft power off hotkey pressed
_________________________________________________________________
9.6. What should acpid do after I press a hotkey?
Once the definition is set up, if I pressed the hotkey, an event of type
"Hotkey Hotkey 0x00000086 0" would be generated, and acpid could pick it up
and do the right thing with it. The right thing is already almost
predefined: it should echo "136:1::100" > /proc/acpi/action where 136 is the
event code that acpid was given in /proc/acpi/events converted to decimal,
the "1" means it is event based rather than poll-based, i.e. the event was
read from /proc/acpi/events, the third missing argument is only needed for
poll-based hotkeys, and the 100 is the argument to _BCM to set the
brightness to the maximum level.
The trick is that most of these methods actually don't do exactly what you
want the hotkey to do. Here's a summary of the relevant AML methods from the
ACPI spec.
_BCM controls brightness. Pass the number (percent of 100) to set the level
to. Supported brightness levels can be retrieved by reading the file
/proc/acpi/video/VID/*/LCD/brightness (or CRT, or whatever device you are
checking). That means that if you have a hotkey for increasing brightness,
mapping it to this method will not be enough. You should use a script that
gets the current brightness, checks the supported levels, and sets the next
one. That script can use /proc/acpi/action, but it will have to have figured
out the right brightness level as the argument to _BCM first.
_DSS makes the display active or inactive. Pass 0x80000000 to inactivate,
and 0x80000001 to activate. You can see the state of each device by reading
the file /proc/acpi/video/*/LCD/state (or CRT, or whatever device you are
checking). That means that if you have a hotkey to switch between CRT and
LCD, mapping it to this method will not be enough. You should use a script
that gets the current active device, inactivates it, and sets the other one
as active.
There are no methods for sound control in ACPI; that's not really a power
management feature. In order to get the sound-related hotkeys to work, you
may have to have acpid run alsamixer or some such to do the right thing.
The sleep state hotkeys are another bit of a kludge. What you want to do
here is to have acpid do any prep work for the suspend or power off; for
suspend, you may have modules you want to remove, and so on. Then you want
to actually do the suspend by echoing the right state into /sys/power/state,
and finally do the right thing on wakeup, by reinserting modules and so on.
For poweroff, you can have acpid call /sbin/shutdown -h now, or whatever
other shutdown mechanism seems good to you. Once again, these hotkeys must
be set up with placeholder bus names, device paths, and AML method names;
these items are only there so that the hotkey driver will register the key
definition and not throw an error.
So what this means is that in all of these cases you are going to use a
script to handle the event. There is perhaps one exception: if you have a
hotkey that turns off the display, or turns the brightness down to zero, you
can map that directly to the appropriate method with a fixed argument. In
the rest of these cases, you still have to pass a valid bus name, device
path, and AML method name, so choose something harmless and then don't ever
use /proc/acpi/action with it. I recommend _SB for the bus name, _SB.PBTN
(or whatever your power button is called) for the device name, and _PSW for
the method name, since you won't need these for anything else. This assumes
your power button supports _PSW; if not you may have to look around in your
DSDT yourself for some ideas.
_________________________________________________________________
9.7. Where do I find ACPI bus names and device paths?
Bus names are easy; see the discussion of bus names as part of events in
[167]How do I use acpid? Device paths are not easy, because device names are
set by the vendor and vary from one platform to the next. You can get valid
device paths for your system out of the ACPI namespace by looking at
/sys/firmware/acpi/namespace/. Find the device you're going to affect
somewhere in the directory tree, say LCD, and grab the full name, starting
with _SB and ending in the device name. You need to put a "." instead of a
"/" between directory names, so that you get something like
_SB/PCI0/AGP/VID/LCD converted to _SB.PCI0.AGP.VID.LCD as the device path.
Again, this is only useful in the rare case where you have a hotkey that
does a fixed action (not increasing the brightness, but setting it to
max/min; not switching the active display but turning one off or on).
_________________________________________________________________
10. Suspend to RAM
10.1. How do I suspend to RAM?
Suspend to RAM is part of the kernel. Make sure you have ACPI enabled in the
BIOS and the kernel, and that you have the CONFIG_ACPI_SLEEP option set.
It's a good idea to remove all usb devices and modules, as well as any
firewire devices and modules. If your suspend works well without them, try
adding them back in.
Then echo mem > /sys/power/state You'll see some messages on the console
about suspension, ending with
hwsleep-0296 [08] acpi_enter_sleep_state: Entering sleep state [S3]
Then your system should go to sleep.
Pressing the power button should bring the system back, starting with some
hard disk activity.
_________________________________________________________________
10.2. My video isn't working; what now?
* Type an innocuous command such as ls and press <Enter>; some folks
report that their display comes back on the first <Enter> key press.
* If your laptop supports display brightness adjustment, and that works on
your system before suspend, try using that after suspend and see if your
video comes back.
* See if switching your video display from your internal LCD to an
external CRT and back brings back your video. You can do this even if
you don't have an external CRT hooked up. See [] on how to do this.
* If none of those things work, see if your system responds to keypresses.
Does pressing the Caps Lock key turn the Caps Lock LED on? If not, wait
about 5 minutes, and try the same activity again. Sometimes the kernel
has gone out to a short snack instead of out to lunch. This works for
me.
* If you have Caps Lock responsiveness, try suspension with networking
enabled, and see if your computer is pingable (again, wait 5 minutes if
there is no initial response).
* If it is, you might try again with sshd and see if you can log into the
system. Then you can try some vbetool tricks to muck with the display.
See [168]Vbetool for vbetool usage and tricks.
* If you don't have network access, see if typing sync gives you disk
activity. If so, you can try the vbetool tricks mentioned above. Set up
a script ahead of time so that you can minimize typing mistakes while
typing blind.
* If none of those things work, you can try a few specialized boot
parameters: acpi=s3_sleep, acpi=s3_mode, or pci=routeirq. See [169]Boot
parameters reference for more information.
*
*
_________________________________________________________________
10.3. What utilities are there that I can use for this?
[FIXME]
_________________________________________________________________
10.4. How about suspend to RAM when I close my laptop?
[FIXME]
_________________________________________________________________
10.5. My usb/pcmcia/other device doesn't work when the system resumes; what can
I do?
Build usb support and the specific driver support for those devices as
modules and write an acpid script that removes these modules before
suspension and reinserts them afterwards. Here's an example, adapted from
Gentoo's wiki page on the Samsung X20 at
[170]http://gentoo-wiki.com/HARDWARE_Samsung_X20#ACPI_hotkeys:
#!/bin/sh
if [ -e /tmp/lidclose ]
then
echo "[" `date` "] Wakeup from standby (lid opened)" >> /var/log/ac
pi_events
rm /tmp/lidclose
else
echo "[" `date` "] Go to standby (lid closed)" >> /var/log/acpi_eve
nts
touch /tmp/lidclose
# USB Module
rmmod uhci_hcd
rmmod ehci_hcd
/sbin/hwclock --systohc
echo mem > /sys/power/state
/sbin/hwclock --hctosys
modprobe uhci_hcd
modprobe ehci_hcd
fi
_________________________________________________________________
10.6. Suspend to RAM just doesn't work after everything I've tried; what now?
Help us debug the problem. Here are some steps to take:
Rebuild your kernel with support for as few devices as possible, preferably
no usb, and no pcmcia unless your network is pcmcia and you have network
after you resume.
Turn off optional devices in your BIOS; my Dell laptop lets me turn off the
modem and wireless devices.
Turn off the framebuffer device.
Boot as single user, turn on networking and sshd if your machine is pingable
after resume, turn on syslogging, and try suspend/resume from there.
Turn off networking for good measure and try that, just to see if that has
an impact.
Make sure your BIOS is the most recent possible.
Check your DSDT; see [171]DSDT editing for instructions.
If you are running an old distribution, in particular an old version of X,
update it/them. If you are using proprietary drivers, make sure you are
using the most recent version.
Try suspend from X as well; video drivers don't live in the kernel except
for framebuffer drivers, and the X drivers sometimes know how to
reinitialize recent video cards.
Look also at Documentation/video/blot.txt for more things you can try.
If you still can't resume, get what you can from the logs and submit a bug
report.
_________________________________________________________________
11. Suspend to disk
11.1. How do I suspend to disk?
11.1.1. Suspend to disk methods
Note: Suspend to disk is entirely independent of the ACPI subsystem. But
it's included in this document because, hey, what the heck.
There are three different patches around for suspend to disk. As of this
writing, the kernel has a set of patches inline, which are called swsusp and
which in this document I will refer to as swsusp1. Software Suspend 2 is a
set of patches not yet merged into the kernel; Software Suspend 3 is a
user-space implementation still in the works. Pm-disk, which used to be yet
another fork from swsusp1, was combined with swsusp1 in mid-2004.
_________________________________________________________________
11.1.2. How do I use Suspend to disk 1?
Make sure you have a swap partition, not a swap file, that it's on a
separate physical partition, and that it's at least as big as your memory.
If your swap partition is on an LVM partition, read the later part of this
section; if it's on raid, there is support also [FIXME].
Back up your data before your first test. No joke! If you happen to have an
unsupported driver, bad things can happen.
Get a few patches first: the data free patch at
[172]http://lkml.org/lkml/2005/9/25/86; the pagedir patch at
[173]http://lkml.org/lkml/2005/9/26/190; and the memory leak patch at
[174]http://lkml.org/lkml/2005/9/25/89. These apply to 2.6.14-rc2 cleanly.
Now, build your kernel with CONFIG_SOFTWARE_SUSPEND=y. According to gossip
on the Linux kernel mailing list, CONFIG_PM_STD_PARTITION is going to be
removed someday; the approved method of specifying the resume partition is
to pass it as an argument at boot time. For Grub users, this means appending
the argument "resume=/dev/something" to your kernel boot line, where
"/dev/something" should be replaced with the full name of your swap
partition.
Boot into the new kernel. If you are watching closely, or if you check
/var/log/messages, you'll see that the kernel attempts to resume from your
swap partition even though there's nothing to resume from (yet). This is
normal behavior; your kernel will do this every time. If you see this
message: swsusp: Error -6 check for resume file, it means that your swap is
not on a physical partition or that you have underlying modules that need to
be loaded before the partition can be found. Check that IDE and/or SCSI
support is built in directly to the kernel, and try again until this message
goes away.
For the first test, you might want to be root and init 3 so that X isn't
running. It's also a good idea to unload usb modules, PCMCIA modules, and
network/wireless modules.
Now give the following command: echo shutdown > /sys/power/disk; echo disk >
/sys/power/state You will see all devices suspend and then resume again
briefly; at this point the swap image will get written and you'll see a
progress count. After the image is written, devices will be suspended again
and then your system should power off.
If you have mice or removable devices or other hardware attached to your
system, LEAVE THEM ALL AS IS. Don't change the hardware configuration at
all; resume expects to resume to a system that is identical to the one it
suspended to. Forbidden hardware configuration changes include plugging the
the laptop when it was unplugged!
Press the power button briefly, and you will go through the normal boot
sequence. Choose the same kernel from the boot menu, with exactly the same
kernel arguments you gave before; if you change this, you could lose all of
your data.
Once you boot, the system should resume from the image it wrote out earlier,
and you'll be returned to the exact state you were in before suspension.
One thing that you may do, without disturbing the resume process at all, is
to boot into a different OS, as long as you don't touch the swap partition
or the other partitions that were mounted when you did the suspend. You
cannot mount them from somewhere else, even if you don't touch anything
after the mount. So for example, you could boot into your 64-bit version of
Linux on some other disk, do work there, then reboot into the kernel from
which you suspended, using the same kernel arguments as for the suspend, and
you'll be back where you were at the point of suspension. Don't forget that
your hardware configuration must not have changed!
On a system where your swap partition is an LVM partition, you must take a
different approach. You must use initrd/initramfs. It doesn't matter whether
your distribution supports the old initrd format or the new cpio format
(initramfs); in either case you make the same changes, but for the old
format you look at the file linuxrc in the image, and for the new format you
look at the file init in the image, to add commands that enable LVM.
Build your kernel with CONFIG_SOFTWARE_SUSPEND=y. For
CONFIG_PM_STD_PARTITION, set the value to "". DO NOT pass any resume=
argument to the kernel at boot time or in your grub.conf. At suspend time,
this will cause the kernel to look for the first swap partition it can see
and use it to write the memory image. It will also cause the kernel to write
this message to /var/log/messages: resume= option should be used to set
suspend device. Ignore that error.
Now you must get several supporting utilities or patches to them. [FIXME
other distros...]
For RedHat/Fedora, you need mkinitrd version 4.2.22-1 or later; utils-linux
2.13-0.3.pre2 or later (for updated swapon); and e2fsprogs 1.38-1 or later.
You can either build these from source or get the binary rpms and install
them. At this writing, these updates are only available from the rawhide
(unstable) release tree, and installing the binary rpms requires
installation of glibc*2.3.90-12 or later.
If you are using RH/Fedora, you can use mkinitrd to create an initrd that
will support lvm and resume from your swap partition. Just run mkinitrd
--allow-missing -f /boot/initrd-2.6.14-rc3.img 2.6.14-rc3, substituting the
actual name of your kernel for 2.6.14-rc3, such as 2.6.13-1.1588_FC5 or
whatever uname -r shows you. Mkinitrd will look for the first enabled swap
partition and write the commands to make it available and resume from it
into the init file in the new initrd.
If you are using another distribution which includes mkinitrd, you should
check to see whether they have an updated version which supports lvm and
resume from swap on a logical volume. You must use the new mkinitrd to build
an initrd image that will be used when you suspend/resume.
If you don't want to use your distribution's mkinitrd or your distribution
doesn't provide one, then you can build one yourself. At a minimum, it
should have a statically linked version of /bin/lvm. Your init or linuxrc
script should create /dev/mapper/control, run lvm vgscan
--ignorelockingfailure, run lvm vgchange -ay --ignorelockingfailure
VolGroup00 (you should include the volume groups that contain your rootfs
and your swap partition), find the major and minor numbers of your swap
partition, and echo them into /sys/power/resume. For example, if your swap
were on /dev/mapper/VolGroup00-LogVol01 which showed
brw-rw---- 1 root disk 253, 1 Oct 2 03:31 /dev/mapper/VolGroup00-Lo
gVol01
then you would echo 253:1 > /sys/power/resume. All of this must be done
before any filesystems are mounted. If you wait until afterwards, you are
almost guaranteed to have data corruption. It should also have a fallback
present in case the resume fails (i.e. the next line after the echo into
/sys/power/resume should handle resume failure). [FIXME provide something
here that's more useful!]
Once you've got your initrd in place, make sure you edit your grub.conf or
other boot configuration file to use the new initrd image file: add a line
initrd /initrd-2.6.14-rc3.img (or whatever your kernel name is) to the
stanza for booting your new kernel. Example:
title Testing (2.6.14-rc3)
root (hd0,2)
kernel /vmlinuz-2.6.14-rc3 ro root=/dev/VolGroup00/LogVol00 rhgb quie
t
initrd /initrd-2.6.14-rc3.img
To suspend, issue the following command, just as in the discussion above for
non-initrd-based suspend: echo shutdown > /sys/power/disk; echo disk >
/sys/power/state and observe the same caveats; no hardware changes, don't
touch any partition that was mounted when you suspended, don't touch the
swap partition.
When you press the power button to resume, the init or linuxrc script in
your initrd will start up LVM for you, check for the suspend image on your
swap partition, and resume from it. For those who want to know more than
they should, the resume works by writing the device name as major:minor
device numbers into /sys/power/resume, which causes the kernel to try to
resume from the swap on that device. (It bypasses the normal kernel resume
path which would use the swap partition name -- something like
/dev/mapper/VolGroup00-LogVol01 -- to try to find an underlying physical
partition and would fail to find it and fail to resume.) This leads to one
last caveat: never write into /sys/power/resume yourself, or you will cause
the kernel to try to resume from whatever device you specify, right then and
there. That is a sure recipe for disaster!
Using Nvidia drivers with swsusp1 is easy. This document describes the
procedure for driver release 7676. Unpack the driver, edit nv.c to change
this stanza:
case PM_SUSPEND_MEM:
nv_printf(NV_DBG_ERRORS, "NVRM: ACPI: received suspend event\n");
status = rm_power_management(nv, 0, NV_PM_ACPI_STANDBY);
break;
to read
case PM_SUSPEND_MEM:
case PM_SUSPEND_STANDBY: /* HACK */
nv_printf(NV_DBG_ERRORS, "NVRM: ACPI: received suspend event\n");
status = rm_power_management(nv, 0, NV_PM_ACPI_STANDBY);
break;
Rebuild your module and you're ready to go. If you are using the intel_agp
module, you may need to use the
Option "NvAgp" "0"
line in the "Device" section of your X configuration file; other than that,
no special tweaks should be needed. In some cases, your X display may come
back fine but switching to other consoles may give you garbage; I find this
to be true on my hardware.
[FIXME put info about ATI drivers here, as needed.]
_________________________________________________________________
11.1.3. Swsusp1 Resume failed; now what?
If resume fails after a successful suspend, you have a suspend image written
to your swap and you'll have to deal with it.
Add the boot parameter "noresume" to your kernel boot arguments, boot up,
and this will cause the kernel to boot normally. If you have the modified
swapon, then your swap partition will automatically be set be usable for
swap again. If you don't, you'll need to make the partition available for
use as swap; do this by mkswap /dev/where-your-swap-is and then swapon -a.
Now you are back to normal.
_________________________________________________________________
11.1.4. How do I use Suspend to disk 2?
Note: the official name of this code is "Software Suspend 2". In this
document, it is usually referred to as swsusp2, even though that's not the
preferred name. With three different suspend to disks floating around, it
helps me to keep them all straight.
Since Suspend to disk 2 has not been merged into the kernel, you'll have to
download the patchset from [175]http://www.suspend2.net/. Version 2.2-rc8
has been released for 2.6.14-rc3 and it applies cleanly. This document only
describes working with this version of the patchset. To apply the patch,
unpack it, cd into the root of your kernel source tree, and run
/path/to/patch-unpacked/apply /path/to/patch-unpacked (the name of the
script is apply, and you must tell it where the unpacked patch tree is).
You must also download the hibernate script which goes with it, from the
same place. Make sure the hibernate script version goes with the kernel
patches. Both rpms and tarballs are available. Assuming you retrieved the
hibernate tarball, unpack it, change into the directory where you unpacked
it, be root and then run ./install.sh. This puts the scripts and config file
in appropriate places. You may want to check /etc/hibernate/hibernate.conf,
and the list of modules that hibernate will attempt to unload before
suspending, in /etc/hibernate/blacklisted-modules. The defaults are usually
ok to test with.
You can either use a swap partition or a file for saving your suspend image.
Using a file will be covered in a later version of this document. [FIXME]
Make sure you have a swap partition that is at least twice as big as your
memory. If your swap is on an LVM partition, read the later part of this
section; if it's on raid, there is support also [FIXME].
Back up your data before your first test. No joke! If you happen to have an
unsupported driver, bad things can happen.
Now, build your kernel with CONFIG_SUSPEND2=y, CONFIG_SUSPEND2_SWAPWRITER=y,
CONFIG_SUSPEND2_CRYPTO=y, CONFIG_SUSPEND2_USERSPACE_UI=y, and
CONFIG_SUSPEND2_DEFAULT_RESUME2="". You should specify your resume partition
by passing an argument at boot time. Of course, to avoid typos, edit your
boot configuration. For Grub users, this means appending the argument
"resume2=swap:/dev/something" to your kernel boot line, where
"/dev/something" should be replaced with the full name of your swap
partition.
If you want to use compression, you should build LZF capability into the
kernel, by setting CONFIG_CRYPTO=y and CONFIG_CRYPTO_LZF=y. You can make
them into modules but then you must use an initrd image to supply these
modules at boot time.
Boot into the new kernel. If you are watching closely, or if you check
/var/log/messages, you'll see that the kernel attempts to resume from your
swap partition even though there's nothing to resume from (yet). This is
normal behavior; your kernel will do this every time. If you see this
message: Can't translate "/dev/..." into a device id yet., it means that
your swap is not on a physical partition or that you have underlying modules
that need to be loaded before the partition can be found. Check that IDE
and/or SCSI support is built in directly to the kernel, and try again until
this message goes away.
For the first test, you might want to be root and init 3 so that X isn't
running. It's also a good idea to unload usb modules, PCMCIA modules, and
network/wireless modules.
Now give the following command: /usr/local/sbin/hibernate You will see all
devices suspend and then resume again briefly; at this point the swap image
will get written and you'll see a progress count. After the image is
written, devices will be suspended again and then your system should power
off. It's really fast, much faster (in my experience) than swsusp1.
If you have mice or removable devices or other hardware attached to your
system, LEAVE THEM ALL AS IS. Don't change the hardware configuration at
all; resume expects to resume to a system that is identical to the one it
suspended to. Forbidden hardware configuration changes include plugging the
the laptop when it was unplugged!
Press the power button briefly, and you will go through the normal boot
sequence. Choose the same kernel from the boot menu, with exactly the same
kernel arguments you gave before; if you change this, you could lose all of
your data.
Once you boot, the system should resume from the image it wrote out earlier,
and you'll be returned to the exact state you were in before suspension.
One thing that you may do, without disturbing the resume process at all, is
to boot into a different OS, as long as you don't touch the swap partition
or the other partitions that were mounted when you did the suspend. You
cannot mount them from somewhere else, even if you don't touch anything
after the mount. So for example, you could boot into your 64-bit version of
Linux on some other disk, do work there, then reboot into the kernel from
which you suspended, using the same kernel arguments as for the suspend, and
you'll be back where you were at the point of suspension. Don't forget that
your hardware configuration must not have changed!
Many other useful entries for swsusp2 are available under /proc/suspend2/.
Warning: please note that this location is only valid for swsusp2 versions
2.2-rc8 and later! For earlier versions, you must look in the directory
/proc/software_suspend/ instead.
On a system where your swap partition is an LVM partition, you must take a
different approach. You must use initrd/initramfs.
Build your kernel with the same configuration options as before.
Now you must get several supporting utilities or patches to them. [FIXME
other distros...]
For RedHat/Fedora, you need mkinitrd version 4.2.22-1 or later; utils-linux
2.13-0.3.pre2 or later (for updated swapon); and e2fsprogs 1.38-1 or later.
You can either build these from source or get the binary rpms and install
them. At this writing, these updates are only available from the rawhide
(unstable) release tree, and installing the binary rpms requires
installation of glibc*2.3.90-12 or later.
If you are using RH/Fedora, you can use mkinitrd to create an initrd that
will support lvm and resume from your swap partition, with some hacking.
Change the line
echo "resume $swsuspdev" >> $RCFILE
to
echo "echo > /proc/suspend2/do_resume" >> $RCFILE
. Warning: please note that this location is only valid for swsusp2 versions
2.2-rc8 and later! For earlier versions, you must use the file
/proc/software_suspend/do_resume instead. Then you can run mkinitrd
--allow-missing -f /boot/initrd-2.6.14-rc3.img 2.6.14-rc3, substituting the
actual name of your kernel for 2.6.14-rc3, such as 2.6.13-1.1588_FC5 or
whatever uname -r shows you. Mkinitrd will look for the first enabled swap
partition and write the commands to make it available and resume from it
into the init file in the new initrd.
If you are using another distribution which includes mkinitrd, you should
check to see whether they have an updated version which supports lvm and
resume from swap on a logical volume. You must use the new mkinitrd to build
an initrd image that will be used when you suspend/resume.
It doesn't matter whether your distribution supports the old initrd format
or the new cpio format (initramfs); in either case you make the same
changes, but for the old format you look at the file linuxrc in the image,
and for the new format you look at the file init in the image, to add
commands that do the resume.
If you don't want to use your distribution's mkinitrd or your distribution
doesn't provide one, then you can build one yourself. At a minimum, it
should have a statically linked version of /bin/lvm. Your init or linuxrc
script should create /dev/mapper/control, run lvm vgscan
--ignorelockingfailure, run lvm vgchange -ay --ignorelockingfailure
VolGroup00 (you should include the volume groups that contain your rootfs
and your swap partition), and echo *gt; /proc/suspend2/do_resume. All of
this must be done before any filesystems are mounted. If you wait until
afterwards, you are almost guaranteed to have data corruption. It should
also have a fallback present in case the resume fails (i.e. the next line
after the echo into /proc/suspend2/do_resume should handle resume failure).
[FIXME provide something here that's more useful!]
Once you've got your initrd in place, make sure you edit your grub.conf or
other boot configuration file to use the new initrd image file: add a line
initrd /initrd-2.6.14-rc3.img (or whatever your kernel name is) to the
stanza for booting your new kernel. Example:
title Testing (2.6.14-rc3)
root (hd0,2)
kernel /vmlinuz-2.6.14-rc3 ro root=/dev/VolGroup00/LogVol00 rhgb quie
t resume2=swap:/dev/mapper/VolGroup00-LogVol01
initrd /initrd-2.6.14-rc3.img
To suspend, issue the following command, just as in the discussion above for
non-initrd/initramfs-based suspend: /usr/local/sbin/hibernate and observe
the same caveats; no hardware changes, don't touch any partition that was
mounted when you suspended, don't touch the swap partition.
When you press the power button to resume, the init or linuxrc script in
your initrd will start up LVM for you, check for the suspend image on your
swap partition, and resume from it. And if you haven't realized it yet,
never write into /proc/suspend2/do_resume yourself, or you will cause the
kernel to try to resume from whatever device you specify, right then and
there. That is a sure recipe for disaster!
Using Nvidia drivers with swsusp2 may take a little work. You'll have to
rebuild your nvidia module as described above for swsusp1, and install it.
Change any settings in your xorg.conf file as well, as described above.
Then try the suspend. If it doesn't work, what may happen is that you see
some disk activity, the screen goes blank, there's more disk activity, and
then the machine stays on. If this happens to you, see if Ctl-Alt-Delete
will let you reboot your machine. If it does, then check your logs to see if
there is a complaint like "Pageset1 has grown by 381 pages. Only 100 growth
is allowed for!". If there is, you can (probably) change one line and get
swsusp2 to run.
If in your log you instead see a lot of lines like
scheduling while atomic: hibernate/0x00000002/3313
[<c01037d7>] dump_stack+0x17/0x20
[<c036fdf7>] schedule+0x557/0x620
[<c037075e>] io_schedule+0xe/0x20
[<c0141a59>] do_bio_wait+0x19/0x30
[<c0141bea>] wait_on_one_page+0x1a/0x30
[<c0142389>] suspend_do_io+0x39/0x40
[<c01423bf>] suspend_bdev_page_io+0x2f/0x40
[<c0143e3d>] swapwriter_invalidate_image+0x5d/0x110
[<c013cc80>] suspend2_main+0xe0/0x1d0
[<c013f1fa>] suspend2_write_proc+0xba/0x270
[<c01a63e4>] proc_file_write+0x34/0x50
[<c016bc61>] vfs_write+0xb1/0x170
[<c016bdcd>] sys_write+0x3d/0x70
[<c01031d5>] syscall_call+0x7/0xb
there may be so many of them that they overflow the message buffer and you
don't see all the steps for suspend/resume logged. To turn these off for the
moment, you'll need to edit kernel/sched.c, and in the schedule() function,
edit this bit:
if (likely(!current->exit_state)) {
if (unlikely(in_atomic())) {
printk(KERN_ERR "scheduling while atomic: "
"%s/0x%08x/%d\n",
current->comm, preempt_count(), current->pid)
;
dump_stack();
}
}
to comment out the
printk()
and the
dump_stack()
lines. Then run the suspend again; you should be able to see the real
suspend/resume errors and check what's wrong. When you are done, uncomment
these lines and rebuild your kernel again, because these catch other errors
than those just in swsusp2.
In your linux kernel source tree with the suspend2 patches applied, edit
kernel/power/prepare_image.h: and change the line
#define EXTRA_PD1_PAGES_ALLOWANCE 100
to read
prepare_image.h:#define EXTRA_PD1_PAGES_ALLOWANCE 500
. This assumes that the pageset1 growth is < 500 pages. If it's much more
than that, this may be a sign of some other problem.
In some cases, your X display may come back fine but switching to other
consoles may give you garbage; I find this to be true on my hardware.
[FIXME put info about ATI drivers here, as needed.]
Note: If you are using Fedora Core 3 or 4, Matthias Hensler maintains kernel
rpms and special versions of mkinitrd at [176]http://mhensler.de/swsusp/
which you can use. Rpms for the hibernate script are also available for
download there.
_________________________________________________________________
11.1.5. Swsusp2 Resume failed; now what?
If resume fails after a successful suspend, you have a suspend image written
to your swap and you'll have to deal with it.
Add the boot parameter "noresume2" to your kernel boot arguments, boot up,
and this will cause the kernel to boot normally. If you have the modified
swapon, then your swap partition will automatically be set be usable for
swap again. If you don't, you'll need to make the partition available for
use as swap; do this by mkswap /dev/where-your-swap-is and then swapon -a.
Now you are back to normal.
_________________________________________________________________
11.1.6. Suspend to disk 3
Note: there is no official name for this version of suspend to disk. It's
referred to as swsusp3 in this document because that name has been used in a
couple of postings (and rejected, too :-)) And it is the third set of code
in current development.
Swsusp3 is a set of very preliminary patches that Pavel Machek is cooking
up. Don't use these unless you like being on the very bleeding edge and
don't mind restoring all of your data. These patches were first introduced
on the Linux kernel mailing list and linux-pm in mid-September; see
[177]http://lkml.org/lkml/2005/9/14/377 and
[178]http://lists.osdl.org/pipermail/linux-pm/2005-September/001358.htmlfor
the patches and discussions on both lists.
So you really really shouldn't do this at home, kids.
But if you just have to try it anyways, first, back up all of your data.
Really. Not like you pretended to back it up for swsusp1 or swsusp2 and you
went ahead and built the kernel and crossed your fingers and hoped. Go Do It
Now.
Make sure you have a swap partition, not a swap file, that it's on a
separate physical partition, and that it's at least as big as your memory.
If your swap partition is on an LVM partition, read the later part of this
section; if it's on raid, you're on your own.
The patches on the linux kernel mailing list are a bit older. I have a patch
generated from Pavel Machek's git tree which almost applies cleanly to
2.6.14-rc4, and the one piece that doesn't, doesn't matter right now (it's a
comment and one line of code).
You can get the patch from
[179]http://www.columbia.edu/~ariel/acpi/swsusp3-2.6.14-rc4.txt for the
moment. Or you can pull his tree for yourself and generate your own bleepin'
patch.
Now, build your kernel with CONFIG_SOFTWARE_SUSPEND=y. Build your kernel
with CONFIG_SOFTWARE_SUSPEND=y. For CONFIG_PM_STD_PARTITION, set the value
to "". DO NOT pass any resume= argument to the kernel at boot time or in
your grub.conf. At suspend time, this will cause the kernel to look for the
first swap partition it can see and use it to write the memory image.
Boot into the new kernel. If you are watching closely, or if you check
/var/log/messages, you'll see that the kernel attempts to resume from your
swap partition even though there's nothing to resume from (yet). This is
normal behavior; your kernel will do this every time. Swsusp3 will complain
if it can't find your swap partition; if so, check that your swap is on a
physical partition and that any underlying modules that need to be loaded
before the partition can be found. Check that IDE and/or SCSI support is
built in directly to the kernel, and try again until the message goes away.
You have a little bit of prep to do first before using this suspend. Go to
the root of your linux kernel tree and cd into usr/. Edit the file swsusp.c,
changing the lines
#include "/data/l/linux-sw3/include/linux/suspend.h" */
#include "/data/l/linux-sw3/include/linux/reboot.h" */
to
#include "linux/suspend.h"
#include "linux/reboot.h"
Build the program swsusp.c by running gcc -g -Wall usr/swsusp.c -o
usr/swsusp-bin -static -I. You need this to be statically built because it's
going to go into your initrd image which you are going to have to build and
use.
Now you must get several supporting utilities or patches to them. [FIXME
other distros...]
For RedHat/Fedora, you need mkinitrd version 4.2.22-1 or later; util-linux
2.13-0.3.pre2 or later (for updated swapon); and e2fsprogs 1.38-1 or later.
You can either build these from source or get the binary rpms and install
them. At this writing, these updates are only available from the rawhide
(unstable) release tree, and installing the binary rpms requires
installation of glibc*2.3.90-12 or later.
Because swsusp3 clears the special suspend signature ("swsusp3") in the swap
file and sets the signature area to zeros, there is not an easy patch or
even a hard one to e2fsprogs/swapon to write the swap signature back in. You
are going to have to run mkswap on your swap partition after every
successful resume instead.
Now it's time to work on the initrd/initramfs image. It doesn't matter
whether your distribution supports the old initrd format or the new cpio
format (initramfs); in either case you make the same changes, but for the
old format you look at the file linuxrc in the image, and for the new format
you look at the file init in the image, to add commands that do the resume.
Make sure that the newly compiled swsusp binary is in your initrd/initramfs
image somewhere useful, say in /bin. In Fedora Core 4 you can just add the
line inst /src/kernel/swsusp-bin "$MNTIMAGE/bin/swsusp" just before the
write of the init file, i.e. before the line echo "#!/bin/nash" >| $RCFILE.
Now you must add commands that create /dev/kmem and that do the resume, to
your init or linuxrc script in your initrd. In Fedora Core 4, if you look at
the init file that is generated by mkinitrd, you can see a section where
there is a series of mknod commands; mknod /dev/console, mknod /dev/null,
and so on, that are getting stuffed into the init file. Add the line mknod
/dev/kmem c 1 2 at the end of that list. For other distributions, your
method may vary.
Now make sure the resume will happen: the line resume
/dev/swap-partition-name must also be written into the init file so that it
will happen before any file systems are mounted. In Fedora Core 4, you can
comment out the line # echo "resume $swsuspdev" >> $RCFILE and add the line
echo "swsusp $swsuspdev -r" >> $RCFILE right after it. It should also have a
fallback present in case the resume fails (i.e. the next line after the
swsusp command should handle resume failure).
Once you've got your initrd in place, make sure you edit your grub.conf or
other boot configuration file to use the new initrd image file: add a line
initrd /initrd-2.6.14-rc4.img (or whatever your kernel name is) to the
stanza for booting your new kernel. Example:
title Testing (2.6.14-rc4)
root (hd0,2)
kernel /vmlinuz-2.6.14-rc4 ro root=/dev/VolGroup00/LogVol00 rhgb quie
t
initrd /initrd-2.6.14-rc4.img
Finally, put the swsusp-bin file somewhere on your root filesystem in your
path, so you can run it from userspace to do the actual suspend. I have it
in /tmp/swsusp for testing. For the first test, you might want to be root
and init 3 so that X isn't running. It's also a good idea to unload usb
modules, PCMCIA modules, and network/wireless modules.
Now give the following command: echo shutdown > /sys/power/disk; /tmp/swsusp
/dev/swap-partition-name -s -o You will see all devices suspend and then
resume again briefly; at this point the swap image will get written and
you'll see a progress count. After the image is written, devices will be
suspended again and then your system should power off.
If you have mice or removable devices or other hardware attached to your
system, LEAVE THEM ALL AS IS. Don't change the hardware configuration at
all; resume expects to resume to a system that is identical to the one it
suspended to. Forbidden hardware configuration changes include plugging the
the laptop when it was unplugged!
Press the power button briefly, and you will go through the normal boot
sequence. Choose the same kernel from the boot menu, with exactly the same
kernel arguments you gave before; if you change this, you could lose all of
your data.
Once you boot, the system should resume from the image it wrote out earlier,
and you'll be returned to the exact state you were in before suspension.
On a system where your swap partition is an LVM partition, you must add yet
more things to your initrd. If you are using Fedora Core 4 and you got the
updated version of mkinitrd as described above, then you don't have to add
anything; mkinitrd has been updated to get your logical volumes set up
already.
Otherwise, you can build one yourself. At a minimum, it should have a
statically linked version of /bin/lvm. Your init or linuxrc script should
create /dev/mapper/control, run lvm vgscan --ignorelockingfailure, and run
lvm vgchange -ay --ignorelockingfailure VolGroup00. (you should include the
volume groups that contain your rootfs and your swap partition). It must, of
course, do this before trying to resume.
To suspend, do exactly the same as before, but provide
/dev/mapper/where-to-find-your-swap as the first argument to swsusp, and
observe the same caveats; no hardware changes, don't touch any partition
that was mounted when you suspended, don't touch the swap partition.
Don't even think about Nvidia or ATI drivers with this. Don't even think
about using X. Be happy if you don't have to reinstall your OS afterwards.
:-)
_________________________________________________________________
11.1.7. Swsusp3 Resume failed; now what?
"I told you so." Ok, seriously: if you can boot your system ok, then you may
be able to recover gracefully.
If resume fails after a successful suspend, you have a suspend image written
to your swap and you'll have to deal with it.
Add the boot parameter "noresume" to your kernel boot arguments, boot up,
and this will cause the kernel to boot normally. If you have the modified
swapon, then your swap partition will automatically be set be usable for
swap again. If you don't, you'll need to make the partition available for
use as swap; do this by mkswap /dev/where-your-swap-is and then swapon -a.
Now you are back to normal.
_________________________________________________________________
11.2. Which should I use, swsusp1, swsusp2, or swsusp3?
[FIXME give more details in this comparison.] Swsusp1 worked for me with the
least fidgeting. It took a while to figure out that I had to build in
CONFIG_PM_STD_PARTITION="" with LVM. That was frustrating. But after that it
was smooth sailing. Swsusp1 is bare bones but gets the job done.
OTOH swsusp2 has many more configuration options for the hapless user, and
given the state that suspend support is currently in, this is a good thing.
I had to get around the "scheduling while atomic" error messages on resume
failure, but after that it was very easy to debug and use. It was also
faster to suspend and resume than swsusp1. I hear there is eye candy for it
but since I don't/can't use that (no text consoles during or after suspend),
I don't include it in this comparison. There's a wiki, a mailing list, and
all kinds of documentation, too. (See [180]http://wiki.suspend2.net/ for the
wiki,and[181]http://lists.suspend2.net/lurker/list/suspend2-users.htmlfor
the users mailing list.) For people who want to suspend to a file rather
than a partition, swsusp2 is the only patchset that permits this. You can
also write to a file over the network. (!)
So, if you want a lot of user support and configuration options, go with
swsusp2, or if you want to suspend to something other than a swap partition.
If you don't want to build your own kernel (and your distribution comes with
the right configuration options built in), use swsusp1. Maybe we'll get the
best of both in some version in the future.
Swsusp3? Surely you jest. But if you have to be able to boast about using
something that's so cutting edge there's no release of it yet, then, this is
the version for you. Urk!
_________________________________________________________________
11.3. What utilities are there that I can use for this?
[FIXME]
_________________________________________________________________
11.4. My usb///other device doesn't work when the system resumes; what can I
do?
Try building in support for these as modules, and unload them before
suspending. Swsusp2 has support for this in its configuration files. Some
folks have acpid suspend on lid close and unload the modules just before
suspension. If you use a script to suspend, unload the modules in there, and
reload them after resume.
Additionally, USB has suspend support available. You can try enabling that
vis CONFIG_USB_SUSPEND to see if USB devices work better for you.
For 2.6.14-rc4, there are several patches for usb you can add, as well. Try
them in this order: first, Greg KH's patches as one giant file, at
[182]http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-
all-2.6.14-rc4.patch; then the suspend/resume patch for usb storage, at
[183]http://bugzilla.kernel.org/attachment.cgi?id=6276&action=view; and
finally, one more tweak for these patches, at
[184]http://bugzilla.kernel.org/attachment.cgi?id=6293&action=view.
_________________________________________________________________
11.5. Suspend to disk just doesn't work after everything I've tried; what now?
Help us debug the problem. Here are some steps to take:
Rebuild your kernel with support for as few devices as possible. Turn off
usb, pcmcia and networking support. Turn off firewire and wireless too.
Turn off the framebuffer device.
Turn off optional devices in your BIOS; my Dell laptop lets me turn off the
modem and wireless devices.
Boot as single user and try to suspend/resume from there. If it works, try
building in support for the things you removed as modules, and insmod them
one at a time to test with suspend/resume to see if you can find out which
driver is causing the problem.
If you still can't resume, turn on any debugging level logging available,
get what you can from the logs, and submit a bug report.
[FIXME get more specific here]
_________________________________________________________________
12. Vbetool
12.1. What is vbetool and where do I get it?
Vbetool is a set of userspace tools for controlling your display by
communicating directly with your graphics adapter. This tool bypasses the
BIOS. It is safer to use than the same techniques in the kernel which could
send the kernel into a hung state.
Most distributions come with vbetool. If you want the latest version, you
can find it at [185]http://www.srcf.ucam.org/~mjg59/vbetool/. The file with
"orig" in the name will build on any linux platform; the patches are for a
Debian package.
_________________________________________________________________
12.2. How do I build vbetool?
To build it, unpack the tarball, cd into the directory where you unpacked
it, ./configure, and then you may have to edit the Makefile. If you try
make, and you get these errors:
/home/ariel/acpi/vbetool/vbetool-0.2/vbetool.c:180: undefined reference
to `pci_scan_bus'
vbetool.o(.text+0x1b9):/home/ariel/acpi/vbetool/vbetool-0.2/vbetool.c:1
83: undefined reference to `pci_read_word'
vbetool.o(.text+0x518): In function `main':
/home/ariel/acpi/vbetool/vbetool-0.2/vbetool.c:47: undefined reference
to `pci_alloc'
vbetool.o(.text+0x52c):/home/ariel/acpi/vbetool/vbetool-0.2/vbetool.c:4
9: undefined reference to `pci_init'
collect2: ...
then you need to edit the Makefile to change the line
LIBS =
to
LIBS = -lpci
. Then make should produce the executable vbetool. Do make install to
install it into /usr/sbin and to install the man page.
_________________________________________________________________
12.3. How do I use vbetool?
12.3.1. What is the vbestate option?
Vbetool will use the VESA 4Fh call to save or restore hardware state. This
includes the hardware state, the video BIOS data state, the video DAC state,
and the Super VGA state. The state information is requested directly from
the video BIOS of the graphics adapter.
Save it into a file just before you suspend and then read it back from that
file after the resume: vbetool vbestate save > video-state suspend, resume,
and then vbetool vbestate restore < video-state
_________________________________________________________________
12.3.2. What is the dpms option?
DPMS stands for Display Power Management Signaling. DPMS compliant monitors
use Hsync and Vsync to put the display into normal, standby, suspend and
power off modes. LCD panels don't use the same method but they support these
same four states.
vbetool dpms off turns the display off and vbetool dpms on turns it on. This
is reported to work for some people to re-enable the video, sometimes in
combination with other options.
_________________________________________________________________
12.3.3. What is the post option?
The post option reinitializes the video adapter by executing the code at the
3rd byte of the expansion ROM in the card. Strictly speaking, it jumps to
the third byte of a copy of the ROM which Linux has placed into c000:0000h.
This approach can fail; the expansion ROM can later jump to someplace in the
system BIOS code, expecting system BIOS functions to be available to
vbetool, and they won't be. Or, it can jump somewhere which has zeros; this
can happen because video adapter initialization code is typically thrown
away by the BIOS after boot, and sometimes not made available again after
suspend/resume.
I have heard rumors that some laptops have expansion ROM that contains
compressed data which is both the video rom and the system bios; these may
not get uncompressed and stuffed back into the shadow rom memory area after
suspend/resume.
Use this option by typing vbetool post.
_________________________________________________________________
13. Patches
13.1. SATA driver
Suspend to RAM/Resume for the SATA subsystem is incomplete. Jens Axboe has a
patch that has worked for some people including me. If you have a laptop
with a device that is recognized as SATA (this includes devices that are
PATA but have a PATA->SATA bridge, like the Dell XPS Gen 2), you should
consider using this patch. You can find it at
[186]http://lkml.org/lkml/diff/2005/9/23/97/1 and it applies cleanly to this
kernel. SUSE, Ubuntu, and some other distributions have this patch already
applied. A secondary patch that is needed sometimes on SUSE kernels is at
[187]http://lkml.org/lkml/diff/2005/9/23/129/1. Fortunately, there is some
discussion of getting this patch merged real soon now; see
[188]http://lkml.org/lkml/2005/9/21/11 for the full thread.
Symptoms of the problem include a message in your logs like
kernel: hda: status timeout: status=0xd0 { Busy }
kernel: hda: no DRQ after issuing MULTWRITE_EXT
or having the hard drive LED remain on continuously and your system lock up
after resume.
_________________________________________________________________
13.2. Radeonfb patches
There is a series of patches for the radeonfb driver which... [FIXME]
_________________________________________________________________
13.3. VGA post
There is a kernel patch that allows you to specify that your graphics
adapter should be reinitialized during resume. [Where in the process does
the reinit happen?] You can try using this if you have no video after
reboot, though it's not clear that this will do anything for you that
vbetool won't do.
_________________________________________________________________
13.4. Ethernet cards
tgs had some problems, go look them up. I think they are fixed.
_________________________________________________________________
13.5. Yenta CardBus socket
Problems have been reported with the IRQ reassignment after suspend/resume.
One fix is [HERE] though it has not yet made it into the kernel. Here's
why...
Symptoms of this problem are:...
_________________________________________________________________
14. Debugging tips
14.1. The driver isn't working right for me. How can I figure out what's wrong?
Turn on debugging in your kernel. Here are the debugging options that
produce useful messages in the log:
CONFIG_PM_DEBUG
CONFIG_ACPI_DEBUG
CONFIG_PCI_DEBUG
CONFIG_DEBUG_DRIVER
CONFIG_DEBUG_KERNEL
CONFIG_DEBUG_BUGVERBOSE
CONFIG_DEBUG_INFO
Try the [189]hwsleep suspend simulation patch. This skips the final step in
suspend, i.e. change to power state. If your system does not come back after
this, but hangs somewhere weird, you might be able to recover everything out
of the logs up to the failure [FIXME is this true?]. And if it works well,
you may have a problem with BIOS/hardware/initialization issues. You
probably have to apply this patch manually, right after the lines
PM1Acontrol |= (acpi_gbl_sleep_type_a << sleep_type_reg_info->bit_posit
ion);
PM1Bcontrol |= (acpi_gbl_sleep_type_b << sleep_type_reg_info->bit_posit
ion);
and right after the lines
/*
* We split the writes of SLP_TYP and SLP_EN to workaround
* poorly implemented hardware.
*/
Look at your DSDT (see below).
_________________________________________________________________
14.2. DSDT editing
14.2.1. What is the DSDT?
DSDT stands for Differentiated System Description Table. This is a pile of
code which defines all of the devices that ACPI is going to interact with,
and all of the methods used to interact with them.
The ACPI specification requires some functions such as _WAK (wake from
suspend) to be implemented, and it requires so many arguments, certain
return values, and so on. If your system's DSDT does not meet these
specifications, some functions may not be recognized or enabled.
_________________________________________________________________
14.2.2. How do I check my DSDT?
There are three quick ways you can check your DSDT. First, you can look at
linux-laptops.net (or acpi4linux) at the list of laptops and see what they
say about yours.
Second, you can use acpidump to extract your dsdt. See [190]Extracting ACPI
tables with pmtools for information about getting and building acpidump. To
get at the dsdt table, do the following:
acpidump > mytables.all
cat mytables.all | ./acpixtract DSDT > mydsdt.bin
Now you have the DSDT table in binary form. To disassemble it, get iasl (see
[191]ASL compiler / AML disassembler iasl for how to do this), build it, and
then do
iasl -d mydsdt.bn
and it will create the output in mydsdt.dsl
Alternatively you can cat /proc/acpi/dsdt into a file, then and then run
iasl on that file.
To see if your DSDT is broken, you recompile it: iasl -tc mydsdt.dsl
You'll get output like this:
Intel ACPI Component Architecture
ASL Optimizing Compiler / AML Disassembler version 20050624 [Aug 11 2
005]
Copyright (C) 2000 - 2005 Intel Corporation
Supports ACPI Specification Revision 3.0
dell-xpsgen2-dsdt.dsl 496: Method (\_WAK, 1, NotSerialized)
Warning 2026 - ^ Reserved method must r
eturn a value (_WAK)
dell-xpsgen2-dsdt.dsl 1262: Method (_S0D, 0, NotSeri
alized)
Warning 2033 - Unknown reserved name ^ (_S0D)
Warnings can generally be ignored; errors must be fixed.
_________________________________________________________________
14.2.3. How do I fix my DSDT?
Look at the resources in [192]ACPI on Linux laptops to see if your errors
are documented. If not, check the [193]ACPI specification. Edit the
disassembled file, run iasl on it again and see if you have eliminated the
errors. An example: [FIXME put one!]
_________________________________________________________________
14.2.4. How do I use my newly fixed DSDT?
You need to build it into your kernel or add it to initrd. Here's how to do
either of those:
To build it into your kernel, first you must get it into the correct form.
You need to convert it to the human-readable hex format that the kernel
expects. This file will have a line near the beginning which reads
unsigned char AmlCode[] =
To convert your DSDT source file into this format, use the command ./iasl
-tc mydsdt.dsl, where mydsdt.dsl should be the name of the file containing
your disassembled dsdt file that you edited. You'll get an output file with
the same naming ending in .hex. You'll also get a file called DSDT.aml which
you can get rid of.
Put this new file someplace convenient for building into your kernels; say,
/usr/src/dsdts/mydsdt.hex. Now you can rebuild your kernel; set
CONFIG_STANDALONE=n first, so that you get the other options to show up in
your config file. Then set CONFIG_ACPI_CUSTOM_DSDT=y and
CONFIG_ACPI_CUSTOM_DSDT_FILE="/usr/src/dsdts/mydsdt.hex" (substitute the
full name of your file here). Make and install, and your new DSDT table will
be used in place of the old buggy one. You can check this by catting
/proc/acpi/dsdt to a file, using iasl to disassemble it, and checking that
your changes are there.
If you don't want to build your DSDT into your kernel every time you upgrade
it, you can use an initrd/initramfs image and put it there. Some
distributions come with support for DSDT in the initrd already; Fedora Core
4 does not.
You'll need to get the appropriate patch first, from
[194]http://gaugusch.at/kernel.shtml; choose the one that goes with your
kernel version or close to it. For 2.6.14-rc4 there is the
acpi-dsdt-initrd-v0.7e-2.6.14.patch which applies cleanly. This patch also
includes the cleanup for initramfs, in case your distribution uses an initrd
that is an initramfs image (a initrd image that is in cpio format, with init
as the script that runs, rather than linuxrc).
Now build your kernel with CONFIG_ACPI_CUSTOM_DSDT *off* and with
CONFIG_ACPI_CUSTOM_DSDT_INITRD=y. If you turn on CONFIG_ACPI_CUSTOM_DSDT by
mistake, then this will override the CONFIG_ACPI_CUSTOM_DSDT_INITRD option,
which is not what you want. Make and install your kernel.
Now you need to add your DSDT to your initrd/initramfs image. You can just
tack it on at the end, instead of using mkinitrd to shove it in there. Do
the following:
echo -n "INITRDDSDT123DSDT123" >> path-to-your-initrd-image
cat DSDT.aml >> path-to-your-initrd-image
The INITRDDSDT123DSDT123 string marks the next piece as the DSDT; this is
why the table can go anywhere in the initrd image. Note that this patch
needs the Aml (i.e. binary) form of the DSDT, not the hex version that gets
built directly into the kernel. If you ran iasl -tc mydsdt.dsl earlier after
fixing your DSDT, you now have the file DSDT.aml which can be used exactly
for this purpose.
On reboot with your new kernel and image, you should be using the new
non-buggy DSDT. You can check this by catting /proc/acpi/dsdt to a file,
using iasl to disassemble it, and checking that your changes are there.
_________________________________________________________________
14.3. Last ditch efforts
First, be sure you have read the appropriate sections of this HOWTO and
tried all of the workarounds documented there.
If you are trying Suspend-to-RAM, have you tried the various boot
parameters? Have you tried all of the vbetool options? Did you try
suspending after booting single user and removing all unnecessary modules?
If you are trying suspend to disk, have you...??
Are you using the most current BIOS, acpid, kernel included with your
distribution or vanilla kernel, and X for your system?
Second, read Documentation/power/video.txt and make sure that you have tried
everything listed there. Also read Documentation/power/tricks.txt and try
those too.
Third, search the existing bug reports at bugzilla.kernel.org under
component ACPI to see if your problem has been reported for your hardware.
If it hasn't, continue on to the next section to see what to put in your bug
report.
_________________________________________________________________
14.4. Submitting useful bug reports
Please submit all bugs to bugzilla.kernel.org under the component ACPI.
You should include the following information:
* Name and version of the distribution you are using
* Version of the kernel you are using and whether it is provided by your
linux distribution or whether it is a vanilla kernel
* Description of any patches you have applied to your kernel
* The full output of acpidump (See [195]The acpid events handling daemon.)
* The output of dmidecode (See [196]dmidecode for more information on this
utility.)
* Output from dmesg
* Output from /var/log/messages
* /sbin/lspci -vvxxxx output from before and after suspend/resume
* List of any boot options you used
* Your .config file for your kernel build
* The contents of any script you use for suspend/resume
* Step by step description of what you did from boot through
suspend/resume and what the outcome was
* Whether you are using proprietary X drivers, if you are suspending from
X
_________________________________________________________________
15. Extracting ACPI tables with pmtools
15.1. Compilation and installation of pmtools
Download pmtools from
[197]http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/.The
most recent version as of this writing is pmtools-20050823.
Unpack the tarball, cd into the directory where you unpacked it, and type
make to build acpidump. Also included are the scripts acpixtract and
acpitbl. These three files should now be copied into a useful location like
/usr/local/bin.
_________________________________________________________________
15.2. Using pmtools
To run acpidump, be root and at the command prompt, type acpidump.
If your system is ACPI-compliant, acpidump should print out a long list of
tables and their contents, including the RSDT and the DSDT.
You can use acpixtract to extract your dsdt or any specific table. To get at
the dsdt table, do the following:
acpidump > mytables.all
cat mytables.all | acpixtract DSDT > mydsdt.bin
This also works for any other table name including the FACP, SSDT, and RSDT.
If you need to extract a table which has more than one instance, such as the
SSDT on my platform, you can use a slightly different version of acpixtract
which I changed to allow you to specify a count after the table name. So if
you do
cat mytables.all | acpixtract SSDT 3 > ssdt3
then you'll get the third instance of the SSDT table. If you have no such
instance, you'll get an empty file. If you leave off the count, you'll get
the default behavior, a dump of the first table instance. The [198]code for
the modified acpixtract is at the end of this HOWTO.
_________________________________________________________________
16. ASL compiler / AML disassembler iasl
16.1. What is iasl and where do I get it?
Iasl is a compiler for ASL, ACPI Source Language, defined in the ACPI
specification. It is also a disassembler for AML, the ACPI Machine Language,
also defined in the ACPI specification. It will disassemble AML into ASL.
You can use this tool on various ACPI tables, in particular, the DSDT, so
that you can edit it, compile it, and use the edited version instead of the
buggy one your vendor may have provided in the BIOS.
You can find the most recent version at Intel's ACPI downloads page, at
[199]http://developer.intel.com/technology/iapc/acpi/downloads.htm.Scroll
down to the "Source Code" section and look for the "ACPI CA - Unix Build
Environment" link. The most recent version at this writing is
acpica-unix-20050902.
_________________________________________________________________
16.2. How do I build iasl?
Unpack the tarball, cd into the directory where you unpacked it, cd
compiler, and make. This will produce the executable iasl which you can put
in some useful location like /usr/local/bin/.
_________________________________________________________________
16.3. How do I use iasl?
To disassemble a table, first get the table in binary form, for example,
acpidump | acpixtract DSDT > mydsdt.bin, and then do iasl -d mydsdt.bin.
This will produce an output file called mydsdt.dsl which you can now edit.
To compile a table into AML, simply do iasl -tc mytable.dsl where
mytable.dsl is the table in ASL.
Although these options will probably get you through the uses of iasl
described in this document, there are many others; type iasl --help to se
them all.
_________________________________________________________________
17. dmidecode
17.1. What is dmidecode and where do I get it?
Dmidecode queries your BIOS about your system's hardware details. This
includes, according to the dmidecode project page at
[200]http://www.nongnu.org/dmidecode/, the system manufacturer, model name,
serial number, BIOS version, and often information about expansion slots and
I/O ports. This information is useful in conjunction with bug reports about
ACPI, when someone is trying to decipher what is going wrong on your
hardware.
Most distributions come with it prepacked. Fedora Core 4, Gentoo, and Debian
ship with it. It may be in /usr/sbin rather than your normal path, so poke
around.
You can download the sources from
[201]http://savannah.nongnu.org/download/dmidecode/. At this writing, the
most recent version is dmidecode-2.7.
_________________________________________________________________
17.2. How do I compile and install dmidecode?
Uncompress the tarball, cd into the directory where you unpacked it, and
type make to build it. This will give you the executables dmidecode,
biosdecode, ownership, and vpddecode. You can install these into
/usr/local/sbin by typing make install. This will also install the man pages
and other documentation.
_________________________________________________________________
17.3. How do I use dmidecode?
Be root, and at the command prompt, just type dmidecode >
lots-of-output.txt. Volumes of information should now be present in the
output file.
_________________________________________________________________
18. ACPI details
18.1. What are all these power states C1, S4, D3, etc?
There are 6 system power states, S0 through S5; 5 device states, D0 through
D4; and a number of CPU power states, depending on your processor; my Dothan
Pentium M supports states C0 through C4.
S0 is when the system is functioning normally, with all devices in their
highest power state, S5 is when the system is in "soft off", powered off but
AC or some other power source is still connected, and the other states are
in between. In particular, S3 is suspend to RAM, and S4 is suspend to disk
(also called hibernation). The idea is that a given state Sn is closer to S0
(fully awake) the smaller n is; it will use more power in that state but
take less time to wake. So in S3, you can resume pretty fast compared to S4,
but you use more power staying in S3 for a given length of time than in S4.
If a device is in D0, it is completely functional, and if it is in D4, it is
powered off. The other states are in between; in particular, D3-hot is when
the device has lost all context but still has power; the OS should have
saved any context that needs to be restored when the device becomes
operational again. D3-cold is when the device has lost all context and no
power is applied. Devices coming back from D3-cold to D0 are expected to be
uninitialized but D3-hot devices may or may not require initialization upon
waking. Many devices do not support D1 or D2 states. As with S0-S5, a device
in Dn for smaller n should consume less power but have lower wake latency
than for a larger n.
When your system is in S0, some devices may not be in D0 because your power
management profile suspends them if they are not in use.
If a processor is in state C0, it is fully functional; in any other state,
it is idle (doing no work). Lower power states use less power but the CPU
will take longer to transition to a higher power state. So if your PCU is in
C4 it will use less power than in C3 but it will take longer to transition
to C0 than from C3. The kernel will place the CPU into a lower power state
automatically when it is not busy, if you enabled CONFIG_ACPI_PROCESSOR. See
the [202]kernel configuration reference for the CONFIG options.
_________________________________________________________________
18.2. What are all these ACPI tables, DSDT, FADT, and so on?
Let's start with the Root System Description Pointer (RSDP) which lets you
know how to find everything else. This pointer tells you where to find the
Root System Description Table (RSDT) and/or the Extended System Description
Table (XSDT). The RSDT is a holder from the 1.0 ACPI spec; the XSDT has the
same information but allows the use of 64-bit addresses. This table contains
pointers to the Fixed ACPI Description table (FADT) and other tables.
The FADT describes various ACPI registers, information about the SCI
interrupt used by the ACPI subsystem, and information about legacy power
management support (SMI). it also contains a pointer to the Firmware ACPI
Control Structure (FACS) and the Differentiated System Description Table
(DSDT). The DSDT contains descriptions of various functions that allow you
to retrieve information about fan, temperature, button status, and so on, as
well as to control various devices through the ACPI interface.
The Secondary System Description Table (SSDT) is an extension of the DSDT.
Your platform may have more than one such table. A pointer to it is located
in the RSDT. These are meant to be add-on tables that describe various
optional features that your vendor may supply depending on your particular
hardware configuration.
A full description of these tables is in section 5 of the ACPI 3.0
specification.
_________________________________________________________________
19. Other information sources
19.1. Mailing lists
You should be reading the acpi-devel mailing list at
[203]http://sourceforge.net/mailarchive/forum.php?forum=acpi-devel, the
linux-pm mailing list at [204]http://lists.osdl.org/pipermail/linux-pm/,
and, unfortunately, the linux kernel mailing list at
[205]http://www.lkml.org. You can also have a look at linux-pm-devel at
[206]http://sourceforge.net/mailarchive/forum.php?forum=linux-pm-devel,
which is much lower traffic. That ought to about cover the reading material.
You can also monitor the bug reports at
[207]http://sourceforge.net/mailarchive/forum.php?forum=acpi-bugzillafor
the very latest news.
_________________________________________________________________
19.2. ACPI on Linux laptops
Linux on Laptops ([208]http://www.linux-laptop.net/) entries for specific
laptops often contain ACPI related configuration information. This is a
great place to start.
TuxMobil ([209]http://tuxmobil.org/mylaptops.html) collects Linux
installation reports which also have great information.
Ubuntu has a good list of test results for suspend for various laptops at
[210]https://wiki.ubuntu.com//HoaryPMResults.
If you are looking for a fix for your laptop's DSDT, please check the
ACPI4Linux DSDT repository at
[211]http://acpi.sourceforge.net/dsdt/view.php. If you don't see it there,
and you add fixes yourself, please add the new DSDT to the repository so
others can use it.
_________________________________________________________________
19.3. Other HOWTOS
In no particular order, here are some HOWTOs I have found helpful.
* Emma Jane Hogbin's ACPI HOWTO (August 2004), at
[212]http://www.tldp.org/HOWTO/ACPI-HOWTO/
* Gentoo Forum -- HOWTO: Fix Common ACPI Problems (DSDT, ECDT, etc.)
(February2004),at[213]http://forums.gentoo.org/viewtopic.php?t=122145
* ThinkWiki -- Ho w to ma ke AC PI wo rk (S eptember 20 05), at
[214]http://www.thinkwiki.org/wiki/How_to_make_ACPI_work
* SuseWiki -- Suspend NVidia HOWTO (September 2005), at
[215]http://www.susewiki.org/index.php?title=Suspend_NVidia_HOWTO
* Richard Black's Linux ACPI Howto (February 2004), at
[216]http://www.cpqlinux.com/acpi-howto.html
* Powersave Documentation (June 2005), at
[217]http://powersave.sourceforge.net/powersave_doku.html a
* Battery Powered Linux Mini-HOWTO (July 2003), at
[218]http://www.tldp.org/HOWTO/Battery-Powered/index.html
* Gentoo's Power Management Guide (June 2005), at
[219]http://www.gentoo.org/doc/en/power-management-guide.xml
* The ACPI4Linux Wiki (September 2005), at
[220]http://acpi.sourceforge.net/wiki/index.php
* The Software Suspend 2 HOWTO (July 2005), at
[221]http://www.suspend2.net/HOWTO
* The Software Suspend 2 Wiki (October 2005), at
[222]http://wiki.suspend2.net/
_________________________________________________________________
19.4. Useful papers
In no particular order, here are some papers I've found useful:
* Takanori Watanabe, ACPI implementation on FreeBSD, at
[223]http://www.usenix.org/events/usenix02/tech/freenix/full_papers/wata
nabe/watanabe_html/
* Pramode C.E., Dissecting the ACPI Button Driver in Kernel 2.6, at
[224]http://linuxgazette.net/106/pramode.html
* Dominik Brodowski, Current Trends in Linux Kernel Power Management, at
[225]http://www.brodo.de/linux/lt05/presentation.pdf
* Srivatsa Vaddagiri, Power Management in Linux-Based Systems, at
[226]http://www.linuxjournal.com/article/6699
* Len Brown, July 2004, The State of ACPI in the Linux Kernel, at
[227]www.finux.org/Reprints/Reprint-Brown-OLS2004.pdf
_________________________________________________________________
19.5. Official specifications
The main source for official documentation is [228]www.acpi.info. They have
the most recent specification, ACPI 3.0, available at
[229]http://www.acpi.info/spec.htm. Microsoft has class specifications for
devices at
[230]http://www.microsoft.com/whdc/resources/respec/specs/pmref/download.msp
x which describe each class of device does in a given power state -- which
parts of the device are powered off, and what functionality it has in the
given state. Intel's ACPI page at
[231]http://developer.intel.com/technology/iapc/acpi/downloads.htmhasgood
information too.
If you spend much time looking at the driver, you are going to want the PCI
specifications, but you can't just download them. Check the PCI SIG website
at [232]http://www.pcisig.com/specifications/conventional/ to get them.
Fortunately, chapter 12 of the Linux Device Drivers book version 3 at
[233]http://www.oreilly.com/catalog/linuxdrive3/book/ch12.pdf can get you
through some of the code. A good deal of Linux-specific information about
PCI devices and drivers is covered in David A Rusling's The Linux Kernel at
[234]http://www.science.unitn.it/~fiorella/guidelinux/tlk/node65.html,
although it was written eight years ago. You can also look at
/usr/src/linux/include/linux/pci.h for a list of every register and bit that
Linux knows about in the PCI configuration space.
You may want the VESA BIOS extension specs at
[235]http://www.vesa.org/Public/VBE/vbecore3.pdf too if you read through the
vbetool or ACPI video code.
_________________________________________________________________
19.6. ACPI on x86_64 and other architectures
[FIXME put some info here]
_________________________________________________________________
20. CPU_FREQ reference
20.1. CPU frequency managers
You can build in a number of kernel-based cpu frequency managers. Each of
these has a different policy for what frequencies it sets the CPU to under
which conditions.
To build in support for the "performance" CPU frequency manager, select
CPU_FREQ_GOV_PERFORMANCE. Under this manager, the CPU frequency is set to
the maximum possible at all times.
To build in support for the "powersave" CPU frequency manager, select.
CPU_FREQ_GOV_POWERSAVE. Under this manager, the CPU frequency is set to the
minimum possible.
To build in support for the user to control CPU frequency directly, via an
entry in sysfs, select CPU_FREQ_GOV_USERSPACE. Most userspace applications
that control CPU frequency such as cpuspeed or powernowd require this.
To build in support for the "ondemand" policy CPU frequency manager, select
CPU_FREQ_GOV_ONDEMAND. Under this manager, the CPU frequency is changed
depending on usage. Your CPU should be able to make very fast frequency
changes for this manager to be effective.
To build in support for the "conservative" policy CPU frequency manager,
select CPU_FREQ_GOV_CONSERVATIVE. Under this manager, the CPU frequency is
changed depending on usage. However, it changes speed more slowly than the
"ondemand" manager. This is a better manager to use when your CPU has a
higher latency for switching frequencies, as laptop CPUs often do.
Of course there's no reason you should have to choose just one of these; at
least one userspace application for frequency management expects you to have
built in both the "performance" and "powersave" managers, and it switches
between them depending on the load.
Once you have built in the managers you want, you must also set the default
frequency manager; choose one of CPU_FREQ_DEFAULT_GOV_PERFORMANCE or
CPU_FREQ_DEFAULT_GOV_USERSPACE which sets the default CPU frequency manager
to the "performance" or "userspace" manager, respectively. Currently these
are the only defaults supported, but you can always change the manager after
boot.
_________________________________________________________________
20.2. CPU frequency drivers
Once you enable CONFIG_CPU_FREQ, you can choose a CPU frequency driver. Only
certain drivers have an ACPI interface option; those are the only ones
discussed here.
If you have a mobile AMD K7 (AMD Mobile Athlon/Duron), you should select
CONFIG_X86_POWERNOW_K7 and CONFIG_X86_POWERNOW_K7_ACPI. If you have an AMD
K8 (AMD Opteron/Athlon64), you should select CONFIG_X86_POWERNOW_K8 and
CONFIG_X86_POWERNOW_K8_ACPI. If you have the Centrino chipset (Intel Pentium
M), you should select CONFIG_X86_SPEEDSTEP_CENTRINO and
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI.
If you have none of these, you can select CONFIG_X86_ACPI_CPUFREQ to build
in the generic ACPI P-states driver. You can only use this if your system
supports CPU performance states; in particular, your CPU must support the
ACPI _PSS method. If it does not, you'll get an error when you try to load
the module or initialize the driver. Most ACPI 2.0 compliant platforms
should support this.
_________________________________________________________________
20.3. How do I regulate my CPU frequency?
Now that you have some cpu frequency managers and the appropriate driver
built into your kernel, you'll probably want a userspace application that
you can configure to change the CPU frequency depending on your needs. It
might regulate frequency only when you're not on AC, or it might step
through various frequencies depending on load, or it might switch between
max and min performance. There are a number of such applications, which
include cpudyn, cpufreq (formerly cpuspeed), powernowd, and cpufreq-applet.
A discussion of how to build, configure and run these is beyond the scope of
this document. Many Linux distributions supply them as packages, however,
with some reasonable default configuration.
If you want to change your CPU frequency manually, you can write the new
frequency, in kHz, into
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed. This means that if
you want 800MHz, you do echo 800000 >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed. Don't worry; if you
forget and put 800, the driver will find the lowest supported frequency for
you and use that instead. You can check those supported frequencies by
looking at
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies.
_________________________________________________________________
21. Kernel configuration reference
Turn on these configuration options for base ACPI support:
CONFIG_PM
turns on power management
CONFIG_ACPI
turns on ACPI
If you build into your kernel both APM and ACPI, and an ACPI-compliant BIOS
is found, ACPI will be used and the APM-related functions will be disabled.
So it's safe to enable both, if you are concerned that your system might not
support ACPI.
Turn on these options for specific functionality:
* Plug and Play devices
CONFIG_PNPACPI
If you have plug and play devices, setting this option will
enable the use of ACPI to detect and allocate resources for
those devices rather than using the PnPBIOS. In almost all
cases it's safe to enable this.
* Suspend-to-RAM:
CONFIG_ACPI_SLEEP
enable suspend to RAM
* suspend to disk:
CONFIG_SOFTWARE_SUSPEND
enables suspend to disk
CONFIG_PM_STD_PARTITION
sets the partition to be used for suspend to disk
* Control over various devices:
CONFIG_ACPI_AC
Allows you to be notified when you switch to or from using an
adapter as your system's power source, so that you can specify
an action to take
CONFIG_ACPI_BATTERY
Allows you to retrieve information about your battery,
including how much capacity it has left, and be notified when
battery charge drops below a certain level, so that you can
specify an action to take
CONFIG_ACPI_BUTTON
Allows you to be notified the sleep or power button is pressed
or you close your laptop lid, so that you can specify an action
to take
CONFIG_ACPI_VIDEO
Allows you to control brightness, set which video display you
use, get the EDID (extended display identification data) from a
video display, and set which video adapter will be POSTed at
next boot if you have more than one video device.
CONFIG_ACPI_FAN
Allows you to turn your fans on or off or check their status
CONFIG_ACPI_PROCESSOR
Allows the kernel to put your CPU in a lower power state when
it's idle; allows you to throttle the cpu by forcing the cpu to
be idle in a percentage of its total clock cycles, when you are
actually doing computation and you don't want to run the cpu at
full load; allows you to limit CPU cycle usage when CPU
temperature is too hot; required for system thermal management
described below (CONFIG_ACPI_THERMAL). You should really set
this item, even if thermal management is the only feature that
gets used.
CONFIG_ACPI_THERMAL
Unless you have a very good reason, set this. Most modern
systems have temperature sensing, and when the temperature of
certain chipsets or the CPU reaches a critical point, the
system shuts down, or other actions can be taken, such as
turning on additional coolers. This requires
CONFIG_ACPI_PROCESSOR.
CONFIG_X86_ACPI_CPUFREQ
This driver adds a CPUFreq driver which utilizes the ACPI
Processor Performance States. To use this, you must have
earlier set CONFIG_CPU_FREQ. It has the advantage of allowing
you later to link CPU throttling limits to changes in CPU
frequency, but it has the disadvantage of being slower in
comparison to hardware-specific drivers. But newer BIOSes will
conform to ACPI 3.0 which uses MSRs instead of IO ports to
change states, and then this driver will kick *ss. There is a
patch in the works to take care of these new features. [FIXME
test and see if centrino really is slower to change freq than
p-state.]
CONFIG_X86_ACPI_CPUFREQ_PROC_INTF
Don't use this; it's deprecated. It creates the entry
/proc/acpi/processor/../performance, but you should use the sys
entries /sys/devices/system/cpu/.../cpufreq/ instead.
* Specific laptop extras:
CONFIG_ACPI_ASUS
If you have an ASUS laptop with ACPI supported, say yes to get
support for the extra keys, control over the notification LEDs,
and for some laptops, backlight and brightness control.
CONFIG_ACPI_IBM
If you have an IBM Thinkpad with ACPI supported, say yes to get
support for hotkeys, Bluetooth enable/disable, video display
switching, UltraBay eject, docking and undocking, and several
other features. An up to date list of these features is
available in [236]Documentation/ibm-acpi.txt.
CONFIG_ACPI_TOSHIBA
If you have a Toshiba laptop which has no BIOS menu settings
and no APM support, you probably want this option. The Toshiba
Libretto is one of these laptops. This driver will give you
access to some Toshiba-specific features that are only now
being integrated into the generic ACPI driver. Those include
turning on/off the fan, switching the video display device,
brightness control, and hotkey support. [FIXME What about
so-called development plans from June 2005? More about how
there is an "experimental" toshiba driver now with more
features.]
* Misc:
CONFIG_ACPI_HOTKEY
New, lets you map a hotkey to a specific ACPI event which acpid
can handle. This driver is useful because vendors do not have
standard event numbers mapped to hotkeys, and this driver lets
you convert vendor numbers to a standardized list. Note that
you must use the boot parameter acpi_generic_hotkey to enable
this driver even after building it into the kernel.
CONFIG_ACPI_BLACKLIST_YEAR
If you set this option in your kernel, and your BIOS is before
the year specified, ACPI will be disabled by default. Some
distributions default this to 2001. If you are building a
kernel to be used on many systems such as a kernel for a Linux
distribution, this is a useful option.
* Debugging/fixing broken implementations
CONFIG_ACPI_CUSTOM_DSDT
Don't use this right away unless you know in advance that your
laptop has a broken DSDT and that you need to compile in a
fixed one. See [237]ACPI on Linux laptops for lists of laptops
with their DSDT fixes, and [238]DSDT editing for a discussion
of DSDT tables.
CONFIG_ACPI_CUSTOM_DSDT_FILE
If you need to compile n a custom DSDT (see previous option),
you must enable this option and give the full pathname to the
DSDT file, compiled into AML code. See [239]DSDT editing for
how to compile DSDT tables.
CONFIG_ACPI_DEBUG
If you are trying to debug problems with the ACPI subsystem,
this will produce some useful debugging messages in your log.
* memory (NUMA)
CONFIG_ACPI_NUMA
SRAT and SLIT tables are defined if you set this. These tables
permit the system to determine which memory modules ought to be
assigned to which nodes. [FIXME get a better description.] If
you have a system which has NUMA enabled, set this option.
* Hotpluggable memory and cpu
CONFIG_ACPI_CONTAINER
FIXME
CONFIG_ACPI_HOTPLUG_MEMORY
FIXME
CONFIG_ACPI_HOTPLUG_IO
FIXME
CONFIG_ACPI_HOTPLUG_CPU
If you have an SMP box with a hotpluggable CPU, and you need to
be able to swap in a new CPU on failure, set this.
* DSDT (Differentiated System Description Table) options To get these, you
must choose STANDALONE under "Generic Driver Options".
CONFIG_ACPI_CUSTOM_DSDT
Allows you to use your own edited and fixed DSDT in case your
BIOS has a broken one. See [240]DSDT editing for more
information on this.
CONFIG_ACPI_CUSTOM_DSDT_FILE
Specify the full path to the file that contains your fixed
DSDT, so the build system can read the file and build the
contents right into the kernel
* Don't enable this, because it's deprecated:
CONFIG_ACPI_SLEEP_PROC_SLEEP
Creates the entry /proc/acpi/sleep, which can be used to put
the system into various suspend states, but this is deprecated
in favor of the sysfs entry /sys/power/state.
still missing:
X86_PM_TIMER [ ] Power Management Timer Support
_________________________________________________________________
22. Boot parameter reference
acpi=force
If you built your kernel with acpi disabled, you can use this option
to force its use.
acpi=off
If you built your kernel with ACPI enabled, you can use this option
to turn it off (in case you'd rather use APM, it interferes with
something else, or it's just plain broken).
acpi=ht
Enable ACPI only to the degree needed to support hyperthreading. If
you don't want to use most of the ACPI driver, but you want
hyperthreading working, use this option so that the ACPI tables will
be used for virtual processor discovery.
acpi=strict
Be anal about syntax and method requirements in ACPI tables provided
by the vendor; if you turn this on, you can find potential problems
with your DSDT that may not show up by other means.
acpi_sleep=s3_bios
If this boot parameter is passed, upon wake from suspend, the kernel
will try to initialize your video adapter by calling code at
c000:0003h. In practice, this code may no longer be available after
power on, so your system may crash. But for some people, this is the
only way to get suspend to RAM to work. Use with caution.
acpi_sleep=s3_mode
Upon wake from suspend, the kernel will set the video adapter mode to
the mode it was in before suspend, using the VESA BIOS mode set call
(0x4f02). Use this if your system can get back to VGA text mode from
suspend, i.e. it suspends ok from a text console, but doesn't work
from X. This could crash your system so use with caution.
acpi_sleep=s3_bios,s3_mode
On some systems that require acpi_sleep=s3_bios, the system will be
left in VGA text mode and so you'll need to do s3_mode as well.
acpi_sci=level|edge|high|low
Set ACPI System Control Interrupt trigger mode; it's very unlikely
that you'll need this, as SCI handling has been stable for some time.
However, if you have a prerelease BIOS, and you see messages in your
log about unrecognized SCIs, try using one of these settings. [If
someone who has to use this option would contact me, I'll add a
better description.]
acpi_irq_balance
ACPI will balance active IRQs to minimize sharing. This is the
default in APIC mode.
acpi_irq_nobalance
ACPI will not move active IRQs around (the opposite of
acpi_irq_balance). This is the default in PIC mode.
acpi_irq_pci=...
If you have set acpi_irq_balance, you have to reserve some IRQs for
for use by PCI or else ACPI may use them all; list them here. Format:
<irq>,<irq>...
acpi_irq_isa
If you have set acpi_irq_balance, you have to reserve some IRQs for
for use by ISA or else ACPI may use them all; list them here. Don't
do this unless you have ISA devices. Format: <irq>,<irq>...
acpi_osi=
By default, the _OSI method in ACPI will tell the BIOS that we are
running Microsoft Windows NT. But if you use this option with an
empty parameter, it disables the _OSI method. (What does the BIOS do
then?)
acpi_os_name=
By default, the _OSI method in ACPI will tell the BIOS that we are
running Microsoft Windows NT. But if you specify a name here, that OS
name will be reported to the BIOS instead. This may enable or disable
some methods in your DSDT depending on the OS string you choose.
acpi_serialize
If you see errors in your log which include things like
Error: Looking up [some-device-id] in namespace, AE_ALREADY_EXISTS
then try setting this option. It forces serialization of AML methods
in case a method creates namespace objects, fails to complete
cleanly, and leaves its debris around; this may allow us to track
down the specific problem.
acpi_skip_timer_override
This option is specific to certain versions of the nForce2 BIOS which
map IRQ0 to pin 2 and result in the timer being XT-PIC instead of
IO-APIC-edge. This isn't really an ACPI issue but it's called
acpi_skip_timer_override so it's in this document. See kernel bug
1203 at [241]http://bugme.osdl.org/show_bug.cgi?id=1203 for more
info.
acpi_dbg_layer=
Format: <int> ; Turn on or off debugging of a or several acpi debug
layers. Each bit of the <int> indicates a separate layer. Starting
from the rightmost bit, you can turn on debugging for the layers:
UTILITIES, HARDWARE, EVENTS, TABLES, NAMESPACE, PARSER, DISPATCHER,
EXECUTER, RESOURCES, CA_DEBUGGER, OS_SERVICES, CA_DISASSEMBLER,
COMPILER, and TOOLS. If you don't do this at boot time you can still
enable this by writing to /proc/acpi/debug_layer.
acpi_dbg_level=
Format: <int> ; Turn on or off debugging of a or several acpi debug
levels. Each bit of the <int> indicates a separate level. Starting
from the rightmost bit, you can turn on debugging for messages logged
at the level: ERROR, WARN, INIT, DEBUG_OBJECT, INFO, INIT_NAMES,
PARSE, LOAD, DISPATCH, EXEC, NAMES, OPREGION, BFIELD, TABLES, VALUES,
OBJECTS, RESOURCES, USER_REQUESTS, PACKAGE, ALLOCATIONS, FUNCTIONS,
OPTIMIZATIONS, MUTEX, THREADS, IO, INTERRUPTS, AML_DISASSEMBLE,
VERBOSE_INFO, FULL_TABLES, and EVENTS. If you don't do this at boot
time you can still enable this by writing to /proc/acpi/debug_level.
ec_burst=
use burst mode instead of polling mode for embedded controller; this
mode is better in the long run than polling mode but not ready for
prime time yet. Use it, however, if you see problems with button
failure or battery status failure or other ACPI events just
disappearing and not being handled; see kernel bug 3851 at
[242]http://bugzilla.kernel.org/show_bug.cgi?id=3851 for more
information.
acpi_generic_hotkey
There is a generic hotkey driver which will let you map hotkey codes
to specific acpi methods. It's not at all user friendly. Nonetheless,
it may be useful for you if your laptop has hotkeys that use the ACPI
interface. If you compile in the generic hotkey driver, using
CONFIG_ACPI_HOTKEY, you must use this boot option for the driver to
be enabled.
Some laptops have specific hotkey drivers for their setups; see the
CONFIG options above for the list. If you set this option and you
have compiled in both the generic hotkey driver and a specific driver
for one of those laptops, only the generic hotkey driver will be
used.
acpi_fake_ecdt
Workaround failure due to BIOS lacking ECDT; use this if you see
errors in your log early on about the battery, adapter or the
embedded controller. Setting this option lets the kernel ignore the
missing ECDT, and come back to complete initialization of those
devices later when it has pulled more complete information from the
DSDT.
acpi_wake_gpes_always_on
If your system seems not to be generating ACPI events, try setting
this option. Here's the explanation, taken right from the kernel
code:
Wake and Run-Time GPES are expected to be separate. We disable
wake-GPEs at run-time to prevent spurious interrupts. However, if a
system exists that shares Wake and Run-time events on the same GPE
this flag is available to tell Linux to keep the wake-time GPEs
enabled at run-time.
pci=noacpi
Do not use ACPI for IRQ routing. ACPI looks at _PRT packages to
figure out which interrupt goes with which PCI interrupt link device
and then looks up the resources that device uses. Instead, use the
PCI IRQ routing table. If your kernel hangs during boot, you may have
serious IRQ problems; try this option.
pci=routeirq
Do IRQ routing for all PCI devices. Each device should call
pci_enable_device(), which will do this IRQ routing, but some drivers
may be broken and not call it, so this option makes sure it gets
called for each device outside of the driver. If you have problems
with a particular device, try this option. Someday this option should
go away. I wonder about proprietary drivers though... Maybe this
option is here to stay.
pnpacpi=off
Try this option if you are having trouble with PNP devices under
ACPI; this will disable use of PNPACPI and will use PNPBIOS instead.
processor.max_cstate
Limit processor to maximum C-state; if you enabled
CONFIG_ACPI_PROCESSOR so that the CPU is placed in different power
states when it is idle, you may want this. Various IBM Thinkpad
systems emit a high-pitched whine when the CPU enters C3 or C4, so
passing C2 as a parameter will prevent that. See ThinkWiki at
[243]http://www.thinkwiki.org/wiki/Problem_with_high_pitch_noisesto
check your specific model.
If you don't want to lose the ability to use these lower power
states, you can try adjusting your timer speed instead: set your
default timer speed to HZ_100 (CONFIG_HZ_100).
If you know that your system should support C3 or C4 and a look at
/sys/module/processor/parameters/max_cstate shows that it's set
lower, you can try to increase it. Some BIOSes are blacklisted from
these lower power states in the kernel. As of this writing, those are
the IBM ThinkPad R40e, the Medion 41700, and the Clevo 5600D. Set
max_cstate=9 to override this limit.
_________________________________________________________________
23. Sysfs entries reference
23.1. Overview of /sys entries
Most acpi hooks have not been moved over from the /proc filesystem. There
are a few exceptions: entries related to cpu power states, cpu frequency, a
device or system's power state, and the ACPI namespace tree. Also,
hotpluggable devices may be controllable via a /sys entry.
_________________________________________________________________
23.2. Power entries in /sys
Every device with an entry in /sys, including buses, has an entry which
concludes in power/state. Some such entries on my system are
./devices/pnp0/00:09/power/state
./devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/power/state
./devices/platform/i8042/serio1/power/state
If you cat one of these, you will see the current power state of the device.
See [244]Power states for more on power states.
/sys/power/state controls the power state for the whole system, from S0-S5.
If you cat this, you see what types of system sleep are supported. Right
now, the kernel supports standby S1), mem (S3) and disk (S4). If you echo
one of these states into /sys/power/state, the system will try to enter that
sleep state. For example, echo disk > /sys/power/state will do suspend to
disk (i.e. hibernation) which is the S4 sleep state. This assumes you have
built hibernation support into your kernel, of course.
_________________________________________________________________
23.3. Hotpluggable devices and /sys entries
If you have devices which are hot-pluggable, you will see
/sys/firmware/acpi/eject and you can echo the name of the device -- as seen
from the ACPI namespace, unfortunately -- into this file and the kernel will
prepare the device so that the user can then swap it out. The name will
probably start "\_SB." and then you can append the actual name of the
device. Look in your DSDT for devices with the EJ0 method. I'd have better
information but my system has no hot-swappable devices. Sorry!
_________________________________________________________________
23.4. CPU power states (C-States) and /sys entries
/sys/module/processor/parameters/max_cstate contains the lowest power state
your CPU can enter. If you know your CPU should support C3 or C4 but you
only see C2 listed here, your BIOS may be blacklisted. See [245]Boot
parameters reference for processor.max_cstate settings to override the
blacklist.
_________________________________________________________________
23.5. CPU frequency management and /sys entries
CPU frequency entries can be found under
/sys/devices/system/cpu/cpu*/cpufreq/, assuming you built in support for CPU
frequency management. You can find some details in the [246]CPU_FREQ
reference although only ACPI-related information is covered there.
Various IBM Thinkpad systems emit a high-pitched whine when the CPU enters
C3 or C4, so echoing '2' into /sys/module/processor/parameters/max_cstate
will prevent that. But see [247]Boot parameters reference for more about
that problem.
_________________________________________________________________
23.6. ACPI namespace tree and /sys
/sys/firmware/acpi/namespace/ACPI shows the ACPI device namespace in tree
form. If it's not clear to you from the name what a given device is, you can
find it in your DSDT and grab the HID (Hardware ID) associated with it, and
look it up in this list:
[248]http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-92
3143f3456c/devids.txt If the _HID isn't listed there, it may be in the ACPI
3.0 specs. For example, in my DSDT, I see
Device (MB2)
{
Name (_HID, EisaId ("PNP0C01"))
...
}
If I look up PNP0C01 in the list, I find: "PNP0C01 System Board".
_________________________________________________________________
24. Proc entries reference
24.1. Overview of /proc entries
Many /proc entries have not made it over to sysfs yet. Those that have are
listed as deprecated here so you can avoid using them. You'll find all the
entries under /proc/acpi. These include access to your DSDT and FADT; the
ACPI event queue; battery info; CPU power and throttling state info; info on
various buttons, video display info; and much more.
_________________________________________________________________
24.2. Wake on RTC alarm entry
/proc/alarm
If you have an RTC (Real Time Clock) that supports an alarm, an entry that
lets you set that alarm shows up here. To set the alarm, write to the file,
using the following format:
echo yyyy-mm-dd hh:mm:ss > alarm
Once the alarm is set, the RTC will generate a hardware wake event when the
system is in a sleep state. It's required to work from S1-S3 and optional
for S4. You can tell if your system supports RTC wake from S4 by running
this little script. It looks at the flags in the FADT for you; there doesn't
seem to be a /proc or /sys interface that exposes this.
#!/bin/bash
# RTC_S4 flag is 113 bytes in, at bit 8 of the byte (0 is least signifi
cant bit).
# This depends on the FADT not telling us a lie. But what else do we h
ave?
if [ $(( (`cat /proc/acpi/fadt | od -j 112 -N 1 -t u1 -A n` & 0x10) >>
4)) -eq 1 ]; then
echo "RTC alarm wakes from S4"
else
echo "RTC alarm does NOT wake from S4"
fi
exit 0
_________________________________________________________________
24.3. ACPI info entry
info
If you read the info file, it will print the version number of [FIXME]. For
example:
version: 20050729
This is the same version that ACPI gives you in your log:
Sep 11 03:42:58 localhost kernel: ACPI: Subsystem revision 20050729
_________________________________________________________________
24.4. DSDT entry
dsdt
This is the binary form of your DSDT; more details about that table are
available in the section [249]DSDT editing.
_________________________________________________________________
24.5. FADT entry
fadt
This is the binary form of your FADT, or Fixed ACPI Description Table. This
table contains ACPI registers and a pointer to your DSDT. Check section
[250]What are all these ACPI tables? for a (very short) overview of some of
the ACPI tables. is
_________________________________________________________________
24.6. Event queue for acpid
event
This is where ACPI events are written so that userspace applications can
process them. If acpid is running, it will read the events and when you try
to cat them, the file will be empty. If you have no daemon running to
process events, you can cat this file to look at them, and they will be in
the same format as in /var/log/acpid. See [251]Acpid events for more
information.
_________________________________________________________________
24.7. Embedded Controller entry
embedded_controller
Embedded controllers are usually used to manage or communicate with smart
batteries and smart battery chargers. If you have a smart battery, you'll
probably also have an embedded controller, and it will show up here. It may
be listed as /proc/acpi/embedded_controller/EC0, and in that directory,
you'll have the file info. If you read that file, you can find out
driver-level specifics. Some sample output is here:
gpe bit: 0x07
ports: 0x66, 0x62
use global lock: no
If your embedded controller has the _GLK method then you should see "use
global lock: yes". If your controller supports the _GPE method (which it is
supposed to do), then you'll have a reserved GPE bit for events, and that
bit will be listed under "gpe bit".
_________________________________________________________________
24.8. Battery info
battery
If you're using a laptop, you should have an entry /proc/acpi/battery for
your battery. Often this will be called BAT0 or something similar.
Underneath that directory, you'll have entries alarm, info, and state.
alarm describes at what capacity your battery will generate a [FIXME] event.
Some batteries don't support alarms; in that case you'll see "unknown"
instead of a value. If your battery supports an alarm, you can set the alarm
by writing a number to "alarm", which will be the cutoff point in mAh; once
the battery reaches that capacity or lower, it will generate a notify event
and the OS will stuff the event into /proc/acpi/event where acpid can pick
it up and allow you, the user, to respond. See [252]The acpid event handling
daemon for information on processing these events. You can set this number
higher than the manufacturer default, but not lower. See below the
description of "design capacity warning".
If your battery doesn't support alarms, the ACPI specification requires the
OS to poll the battery to check its remaining capacity. It appears that
Linux does not yet do this. In this case, it's best to run a user
application that can check your battery status and take appropriate action.
info describes various capabilities of your battery. Here's a breakdown
using a sample listing:
* present: yes or no, depending on whether you have a battery inserted or
not
* design capacity: 7200 mAh -- your battery's capacity in milliamp-hours.
My battery will produce 7.2 amps for 1 hour.
* last full capacity: 7191 mAh -- your battery's capacity when it was last
fully charged. This is likely to be a bit lower than the design capacity
(i.e. the capacity when the battery came out of the factory).
* battery technology: rechargeable, non-rechargeable, or unknown. Know
anyone using a non-rechargeable battery? If your battery reports that it
is non-rechargeable, you probably have problems with the ACPI driver;
time to visit the kernel bugs list at [253]http://bugzilla.kernel.org
(check the ACPI component).
* design voltage: 11100 mV -- voltage of the battery when new
* design capacity warning: 720 mAh - When the battery capacity crosses
this point, it generates a notify event -- whether it is charging, and
capacity just got greater than this value, or draining, and capacity is
running low. Linux will pass that event on to /proc/acpi/event where
acpid can pick it up. See [254]The acpid event handling daemon for
information on processing these events.
If your battery supports _BTP, you'll have the alarm entry described
earlier, which allows you to set this number. Otherwise, it's set at a
default value.
* design capacity low: 218 mAh - how much energy needed to transition the
system to a sleep state. If battery capacity gets to this point, Linux
will put the system into some sleep state [FIXME which one, how?].
* capacity granularity 1: 72 mAh -- As the ACPI spec says, "battery
capacity granularity between low and warning in [mAh] or [mWh]. That is,
this is the smallest increment in capacity that the battery is capable
of measuring."
* capacity granularity 2: 72 mAh -- Same as above, for warning to Full,
except that this number can be different than capacity granularity 1
because in some systems, the granularity accuracy may change depending
on the battery level.
* model number: DELL C54475
* serial number: 1768
* battery type: LION
* OEM info: Sanyo
state describes the current battery state. From a sample listing:
* present: yes or no
* capacity state: ok or critical; critical means that the batteries are
drained. If you are on battery power only, Linux should be shutting down
your system right now. :-)
* charging state: charged, charging, discharging, charging/discharging
* present rate: 1 mA (or other value) or unknown
* remaining capacity: 7200 mAh (or other value) or unknown
* present voltage: 12441 mV (or other value) or unknown
_________________________________________________________________
24.9. Button entries
button
This is where sleep, power and lid controls are described. Let's look at
each of these.
power
You'll have an entry under this directory for your power button,
something like PBTN. The button will have the entry info, which you
can look at to see if your power button is a CM (Control Method) type
button, or an FF (Fixed Feature) type button. For more information on
the distinction, read the ACPI specification; see [255]Specifications
for the link.
sleep
You'll have an entry under this directory for your sleep button,
something like SBTN. The button will have the entry info, which you
can look at to see if your sleep button is a CM (Control Method) type
button, or an FF (Fixed Feature) type button. For more information on
the distinction, read the ACPI specification; see [256]Specifications
for the link. If you don't have a separate sleep button, there will
be an entry here anyways and your button will be classed as CM type.
lid
You'll have an entry under this directory for your laptop lid button,
something like LID. The button will have the entry info, which will
tell you that you have a "Lid Switch". There are no other types
defined at this writing. There will also be an entry state, which
will either tell you that the lid is "open" or "closed". If you're
thinking that this doesn't give you much new information, realize
that this entry isn't meant for you; it's meant for acpid-related
scripts or user applications to check and take appropriate action
when they are notified of an ACPI lid event.
_________________________________________________________________
24.10. Fan control
fan
For each fan, you'll have an entry in /proc/acpi/fan, called FAN or
something similar. Under this entry, you'll have the file state which lets
you see whether the fan is on or off by reading it. It also lets you write
the fan state by echoing a number between 0 and 3, inclusive, to the file.
State 0 corresponds to device power state D0, and so on. If you have
variable speed fans that allow this, that's how to keep them quiet during
low load times and cooling well during high load times. You'll have to
experiment to see what RPM each of these states gives you, if you have other
software that lets you monitor fan speed. Often, D0 is full on and D3 is
off.
_________________________________________________________________
24.11. Power resources
power_resource
You should also see the directory /proc/acpi/power_resource. Power resources
are supposed to be things like power planes, i.e. sources that devices rely
on and that can be turned off when all devices using them are turned off.
Having said that, I don't know any specific objects that get classified as
power resources, although some systems list power fans under this category.
Under this directory you'll have an entry for every resource with a file
state underneath it. You can read this file to see if your resource is on or
off. There's a bit more information included: the system level, which is the
lowest system sleep level that the OS can put the system in and still keep
this power resource on; the order, which lets the OS know which order to
turn on or off all resources at a given system sleep state; and the
reference count, which is for internal bookkeeping.
_________________________________________________________________
24.12. CPU entries
For each cpu, you'll have an entry in /proc/acpi/processor, CPU0-CPUn, and
for each CPU you'll have the following entries:
info
processor id
0, unless you have a multiprocessor system, in which case,
it'll be the number of the particular CPU.
acpi id
CPU number by a different scheme. ACPI gets its cpu numbering
via the MADT, which may result in a different numbering than
the processor id.
bus mastering control
This must be yes in SMP systems for C3 usage (to maintain cache
coherency); if you don't have it and your system is SMP, C3 and
lower power states will be unavailable to you.
power management
If yes, the CPU can be placed into a state of type C2 or C3.
This is not the same as being in states C2 or C3! See below for
discussion of power state *types*.
throttling control
If yes, the CPU supports some throttling states; see {FIXME}
for a discussion of how these work.
limit interface
It would be nice if this entry had some use. But it's actually
set whenever throttling control is set. There ya go. [FIXME
doublecheck]
limit
If your cpu supports throttling states, you can see the highest
throttling state that your cpu is currently permitted to enter. See
[257]What are throttling/performance state limits and how do I use
them? for more information on throttling states.
power
In addition to throttling states and performance states, each CPU
supports different power states; see [258]Power states for more about
this. The power file shows you the current power state, the maximum
state that the system will allow the CPU to enter (the state where it
uses the lowest amount of power), [FIXME], and a list of all states
the CPU actually supports. In the supported power states list, the
type field refers to the sort of preparation that the OS must do in
order to place the CPU in that power state. So for example, in the
listing below, both power states C3 and C4 require the OS to disable
bus master arbitration before entering the chosen power state; that's
the preparation the OS needs for the "C3 type".
active state: C2
max_cstate: C8
bus master activity: 08000000
states:
C1: type[C1] promotion[C2] demotion[--] latenc
y[001] usage[00000010]
*C2: type[C2] promotion[C3] demotion[C1] latenc
y[001] usage[13576208]
C3: type[C3] promotion[C4] demotion[C2] latenc
y[085] usage[01936846]
C4: type[C3] promotion[--] demotion[C3] latenc
y[185] usage[26741344]
One other thing you should pay attention to in this listing is the
usage field. This indicates how many times the CPU has been placed in
this state (including from the very same state). Unless you are
always doing very computationally intensive work, your listing should
look something like the list above, i.e. your CPU should spend most
of its time in the state with the lowest power usage, here C4. This
is true even with cpu frequency management enabled. Your CPU should
be idle most of the time and it should spend most of the time in the
deepest idle state available. If that is not happening, you should
check your kernel configuration and possibly report it as a bug.
throttling
The throttling entry shows you how many throttling states your CPU
supports, which state your CPU is currently in, and how much of the
time your CPU is forced idle for each state.
state count: 8
active state: T0
states:
*T0: 00%
T1: 12%
T2: 25%
T3: 37%
T4: 50%
T5: 62%
T6: 75%
T7: 87%
See [259]CPU throttling for more on throttling.
_________________________________________________________________
24.13. Sleep (deprecated)
/proc/acpi/sleep is deprecated; use /sys/power/state instead.
_________________________________________________________________
24.14. Thermal zone info
thermal_zone
If your system supports thermal management, you'll have entries in
/proc/acpi/thermal_zone. For each CPU and for any other devices your system
can monitor and control via ACPI, you'll have an entry that begins THM or
something similar. The entries for each of these include:
cooling_mode
This entry describes the cooling mode currently in use. This can be
one of active, passive, or critical. These are described in more
detail in the [260]Thermal management section. If your platform
supports it, you can set the cooling mode to active by echoing 0 to
this file, or passive, by echoing 1 to this file.
state
This shows the state of the thermal zone: either one of the cooling
modes, if it is currently activated, i.e. critical, passive,
active[0] - active[9], or ok if no cooling mode is in use.
trip_points
This shows the trip points you have set for the various cooling
methods your system supports. If your system only supports the
mandatory critical trip point, then that's all you'll see, as on my
system:
critical (S5): 99 C
If other methods are supported, you'll see trip points for those
also, as in the example below:
critical (S5): 103 C
passive: 100 C: tc1=1 tc2=2 tsp=100 devices=0xdfffed60
active[0]: 80 C: devices=0xdffe6c00
active[1]: 65 C: devices=0xdffe6b20
active[2]: 52 C: devices=0xdffe6aa0
active[3]: 40 C: devices=0xdffe6a20
critical (S5): 103 C
critical (S5): 103 C
The values for tc1 and tc2 are used to compute the optimal processor
throttling state to keep the thermal zone temperature down below the
passive cooling limit, and tsp is how often to sample the temperature
while doing this adjustment. These values are fixed by the vendor and
are provided here so that folks who are interested in the
nitty-gritty can do the computation and see if the hardware behavior
makes sense. See /usr/src/linux/drivers/thermal.c, function
acpi_thermal_passive(), for more information.
polling_frequency
This shows how often the temperature is checked, in seconds. By
default, Linux sets this to whatever your platform implements via the
_TZP method; if this method doesn't exist, then it's disabled. That
means that by default, temperature polling is turned off on a lot of
platforms. Fortunately, you can enable it by echoing a number to the
file, where the number is how often to poll in seconds.
temperature
This shows the current temperature in Celsius of the thermal zone.
_________________________________________________________________
24.15. Video adapter and display entries
For each video adapter, you'll have an entry under /proc/acpi/video that
starts with VID. You should have the following subentries:
DOS
[FIXME]
info
[FIXME]
POST
[FIXME]
POST_info
[FIXME]
ROM
[FIXME]
For each VID entry, you'll have entries describing displays. My system
supports a variety of displays so I have the following entries: CRT, DVI,
LCD, and TV. For each display you have these entries:
brightness
This lets you change the brightness of your LCD. You must use one of
the supported brightness levels, which you can obtain by reading the
brightness file. Some platforms don't support this.
EDID
Show extended display identification data for the display; this
includes identifying information, hfreq, vfreq, resolution, and
supported video modes. Some platforms don't support this. If you have
one that does, I'd love to get the output so folks can have a sample
in this document.
info
device_id: 0x0110 type: UNKNOWN known by bios: no
state
This lets you activate/inactivate the display. echo 0x80000001 >
/proc/video/VID/*/state turns on the display, and echo 0x80000000 >
/proc/video/VID/*/state turns it off. These esoteric numbers come
from the ACPI specs; bits 1-29 are zero, and if you want to do actual
switching and not just cacheing the change, you set bit 31 and clear
bit 30. Bit 0 is set to activate the device and cleared to inactivate
it.
If you cat the file, you'll see something like
state: 0x1f
query: 0x00
The value for state also comes straight from the ACPI specs: bits
5-31 are zero, and the meaningful bits are as follows: bit 4
[optional]: set if device is attached, bit 3: set if device is not
defective, bit 2: set if output is ready to switch, bit 1: output is
activated, and bit 0: output connector exists now. Given this, we can
decipher 0x1f as 11111 = attached, not defective, ready to switch,
activated, connector exists now.
_________________________________________________________________
24.16. Wake capabilities
wakeup
The entry wakeup has a list of which devices can change the power state of
the system, and whether or not that change is enabled.
So in the list below, if your system is in S3 (suspend to RAM), and you open
the lid, the system will wake to S0. If your system is in S4 and you press
the power button, the system will wake to S0. The other wake events are
disabled.
Device Sleep state Status
LID 3 *enabled
PBTN 4 *enabled
PCI0 3 disabled
USB0 0 disabled
USB1 0 disabled
USB2 0 disabled
USB4 0 disabled
USB3 0 disabled
MODM 3 disabled
PCIE 4 disabled
_________________________________________________________________
25. Modified acpixtract
Retrieve a given instance of a table by specifying the number of the
instance. For example, acpidump | ./acpixtract SSDT 3 > ssdt3
#!/usr/bin/perl
#
# acpixtract - extract raw table from acpidump output
#
# Example: cat mail.txt | ./acpixtract DSDT > DSDT
# iasl -d DSDT
#
($ME = $0) =~ s|.*/||;
$table = uc(shift(@ARGV) || "");
$count = shift(@ARGV) || 1;
if(@ARGV)
{
my($file);
for $file (@ARGV)
{
if(open(IN, "$file"))
{
&process(IN, STDOUT, $table, $count);
close(IN);
}
else
{
print STDERR "$ME: $file: $!\n";
}
}
}
else
{
&process(STDIN, STDOUT, $table, $count);
}
exit(0);
sub
process
{
local(*IN, *OUT, $table, $count) = @_;
my($interior) = 0;
my($localcount) = 0;
while(<IN>)
{
if(!$interior && /$table \@ 0x/)
{
$localcount++;
if ($localcount != $count) {
next;
}
$interior = 1;
}
elsif($interior && /\s+[\dA-Fa-f]{4}:\s+/)
{
$_ = $';
/\s{2}/;
$length = ((length($`) + 1) / 3) - 1;
print OUT pack('C*', map(hex, (split(/\s/, $`))[0..$length]));
}
elsif($interior)
{
while(<IN>) {}
return;
}
}
}
References
1. mailto:ariel@columbia.edu
2. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#about_this_document
3. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#introduction
4. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#copyright
5. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#disclaimer
6. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#credits
7. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#feedback
8. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#fixmes
9. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_overview
10. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#what_is_power_management
11. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#what_is_acpi
12. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_and_apm
13. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_and_linux
14. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#hardware_requirements
15. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#hardware_supported
16. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#devices_supported
17. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#bioses_supported
18. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#check_bios
19. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#unsupported_laptops
20. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#software_requirements
21. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#kernels_supported
22. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#latest_driver_and_utils
23. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#binary_distributions
24. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#compilation_installation
25. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#prereqs_and_kernel_setup
26. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#bios_settings
27. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#boot_parameters
28. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpid
29. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#what_is_acpid
30. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#compiling_acpid
31. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#running_acpid
32. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpid_events
33. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpid_tracking
34. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpid_scripts
35. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpu_management
36. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpu_management_overview
37. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpu_management_idle
38. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpu_management_freq
39. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpu-management_throttling
40. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#thermal_management
41. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#thermal_overview
42. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#thermal_zones
43. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cooling_modes
44. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#trip_points
45. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#throttling_and_pstate_limits
46. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#hotkeys
47. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#what_is_hotkey_driver
48. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#hotkey_supported_laptops
49. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#hotkey_get_event_number
50. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#hotkey_function
51. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#hotkey_driver_event_nums
52. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#hotkey_acpid_action
53. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_bus_names
54. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_ram
55. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#howto_suspend_to_ram
56. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#video_broken_whatnow
57. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_ram_utils
58. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_ram_lidclose
59. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_ram_usb
60. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_ram_whatnow
61. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_disk
62. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_disk_howto
63. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#swsusp1_vs_swsusp2
64. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_disk_utils
65. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_disk_usb
66. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_disk_whatnow
67. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#vbetool
68. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#what_is_vbetool
69. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#building_vbetool
70. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#using_vbetool
71. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#patches
72. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sata_patch
73. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#radeonfb_patch
74. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#vga_post_patch
75. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#ethernet_card_patch
76. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#yenta_patch
77. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#debugging_tips
78. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_broken_whats_wrong
79. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#dsdt_editing
80. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#last_ditch_efforts
81. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#what_to_put_in_bug_report
82. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#pmtools
83. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#compiling_pmtools
84. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#using_pmtools
85. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#iasl
86. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#what_is_iasl
87. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#building_iasl
88. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#using_iasl
89. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#dmidecode
90. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#what_is_dmidecode
91. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#compiling_dmidecode
92. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#using_dmidecode
93. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_details
94. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#power_states
95. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_tables
96. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#_other_information
97. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#mailing_lists
98. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_on_laptops
99. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#other_howtos
100. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#useful_papers
101. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#specifications
102. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#other_architectures
103. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpufreq_reference
104. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpu_frequency_managers
105. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpu_frequency_drivers
106. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpu_regulate_frequency
107. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#config_reference
108. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#boot_reference
109. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sysfs_entries
110. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sysfs_overview
111. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sysfs_power
112. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sysfs_hotpluggable
113. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sysfs_max_cstate
114. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sysfs_cpu_freq
115. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sysfs_acpi_namespace
116. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_entries
117. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_overview
118. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_wake_on_rtc_alarm
119. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_acpi_info
120. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_dsdt
121. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_fadt
122. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_event
123. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_embedded_controller
124. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_battery
125. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_button
126. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_fan
127. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_power_resources
128. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_cpu
129. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_sleep
130. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_thermal_zone
131. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_video
132. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_wake
133. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpixtract_mods
134. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#other_architectures
135. http://www.columbia.edu/~ariel/acpi/acpi_howto-01e.txt
136. http://www.columbia.edu/~ariel/acpi/acpi_howto.html
137. http://www.columbia.edu/~ariel/acpi/
138. http://www.gnu.org/copyleft/fdl.html
139. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#what_to_put_in_bug_report
140. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_on_laptops
141. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sata_patch
142. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#ethernet_card_patch
143. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#radeonfb_patch
144. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#dsdt_editing
145. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#boot_reference
146. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#config_reference
147. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#debugging_tips
148. ftp://ftp.kernel.org/pub/linux/kernel/peple/lenb/acpi/patches/release/
149. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpid
150. mailto:ariel@columbia.edu
151. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#suspend_to_disk
152. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#config_reference
153. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#boot_reference
154. http://www.linuxhq.com/kernel/v2.4/3-ac8/acpi-20010413.diff
155. http://sourceforge.net/projects/acpid/
156. http://lkml.org/lkml/2005/7/31/219
157. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_entries
158. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#hotkeys
159. http://www.thinkwiki.org/wiki/Category:Scripts
160. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_on_laptops
161. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#config_reference
162. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#proc_entries
163. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#sysfs_entries
164. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#boot_reference
165. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpufreq_reference
166. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#thermal_management
167. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#running_acpid
168. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#vbetool
169. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#boot_reference
170. http://gentoo-wiki.com/HARDWARE_Samsung_X20#ACPI_hotkeys
171. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#dsdt_editing
172. http://lkml.org/lkml/2005/9/25/86
173. http://lkml.org/lkml/2005/9/26/190
174. http://lkml.org/lkml/2005/9/25/89
175. http://www.suspend2.net/
176. http://mhensler.de/swsusp/
177. http://lkml.org/lkml/2005/9/14/377
178. http://lists.osdl.org/pipermail/linux-pm/2005-September/001358.html
179. http://www.columbia.edu/~ariel/acpi/swsusp3-2.6.14-rc4.txt
180. http://wiki.suspend2.net/
181. http://lists.suspend2.net/lurker/list/suspend2-users.html
182. http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-all-2.6.14-rc4.patch
183. http://bugzilla.kernel.org/attachment.cgi?id=6276&action=view
184. http://bugzilla.kernel.org/attachment.cgi?id=6293&action=view
185. http://www.srcf.ucam.org/~mjg59/vbetool
186. http://lkml.org/lkml/diff/2005/9/23/97/1
187. http://lkml.org/lkml/diff/2005/9/23/129/1
188. http://lkml.org/lkml/2005/9/21/11
189. http://lkml.org/lkml/2005/6/7/28
190. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#pmtools
191. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#iasl
192. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_on_laptops
193. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#specifications
194. http://gaugusch.at/kernel.shtml
195. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpid
196. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#dmidecode
197. http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
198. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpixtract_mods
199. http://developer.intel.com/technology/iapc/acpi/downloads.htm
200. http://www.nongnu.org/dmidecode/
201. http://savannah.nongnu.org/download/dmidecode/
202. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#config_reference
203. http://sourceforge.net/mailarchive/forum.php?forum=acpi-devel
204. http://lists.osdl.org/pipermail/linux-pm/
205. http://www.lkml.org/
206. http://sourceforge.net/mailarchive/forum.php?forum=linux-pm-devel
207. http://sourceforge.net/mailarchive/forum.php?forum=acpi-bugzilla
208. http://www.linux-laptop.net/
209. http://tuxmobil.org/mylaptops.html
210. https://wiki.ubuntu.com//HoaryPMResults
211. http://acpi.sourceforge.net/dsdt/view.php
212. http://www.tldp.org/HOWTO/ACPI-HOWTO/
213. http://forums.gentoo.org/viewtopic.php?t=122145
214. http://www.thinkwiki.org/wiki/How_to_make_ACPI_work
215. http://www.susewiki.org/index.php?title=Suspend_NVidia_HOWTO
216. http://www.cpqlinux.com/acpi-howto.html
217. http://powersave.sourceforge.net/powersave_doku.html
218. http://www.tldp.org/HOWTO/Battery-Powered/index.html
219. http://www.gentoo.org/doc/en/power-management-guide.xml
220. http://acpi.sourceforge.net/wiki/index.php
221. http://www.suspend2.net/HOWTO
222. http://wiki.suspend2.net/
223. http://www.usenix.org/events/usenix02/tech/freenix/full_papers/watanabe/watanabe_html/
224. http://linuxgazette.net/106/pramode.html
225. http://www.brodo.de/linux/lt05/presentation.pdf
226. http://www.linuxjournal.com/article/6699
227. file://localhost/src/ariel/acpi/howto/www.finux.org/Reprints/Reprint-Brown-OLS2004.pdf
228. http://www.acpi.info/
229. http://www.acpi.info/spec.htm
230. http://www.microsoft.com/whdc/resources/respec/specs/pmref/download.mspx
231. http://developer.intel.com/technology/iapc/acpi/downloads.htm
232. http://www.pcisig.com/specifications/conventional/
233. http://www.oreilly.com/catalog/linuxdrive3/book/ch12.pdf
234. http://www.science.unitn.it/~fiorella/guidelinux/tlk/node65.html
235. http://www.vesa.org/Public/VBE/vbecore3.pdf
236. http://www.linuxhq.com/kernel/file/Documentation/ibm-acpi.txt
237. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_on_laptops
238. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#dsdt_editing
239. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#dsdt_editing
240. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#dsdt_editing
241. http://bugme.osdl.org/show_bug.cgi?id=1203
242. http://bugzilla.kernel.org/show_bug.cgi?id=3851
243. http://www.thinkwiki.org/wiki/Problem_with_high_pitch_noises
244. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#power_states
245. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#boot_reference
246. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpufreq_reference
247. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#boot_reference
248. http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/devids.txt
249. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#dsdt_editing
250. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpi_tables
251. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpid_events
252. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpid
253. http://bugzilla.kernel.org/
254. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#acpid
255. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#specifications
256. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#specifications
257. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#throttling_and_pstate_limits
258. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#power_states
259. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#cpu-management_throttling
260. file://localhost/src/ariel/acpi/howto/ACPI-HOWTO-NEW.html#thermal_management