ACPI (Advanced Configuration and Power Interface) was designed to enable the operating system to set up and control the individual hardware components. Thus, ACPI supersedes both PnP and APM. Moreover, ACPI delivers information about the battery, AC adapter, temperature, fan, and system events like “close lid” or “battery low”.
The BIOS provides tables containing information about the individual components and hardware access methods. The operating system uses this information for tasks like assigning interrupts or activating and deactivating components. As the operating system executes commands stored in the BIOS, the functionality depends on the BIOS implementation. The tables ACPI is able to detect and load are reported in /var/log/boot.msg. See Section 9.3.1.3. “Troubleshooting” for more information about troubleshooting ACPI problems.
If the kernel detects an ACPI BIOS when the system is booted, ACPI is activated automatically (and APM is deactivated). The boot parameter acpi=on may be necessary for some older machines. The computer must support ACPI 2.0 or later. Check the kernel boot messages in /var/log/boot.msg to see if ACPI was activated. If this is the case, there is a directory /proc/acpi, which is described later.
Subsequently, a number of modules must be loaded. This is done by the start script of the ACPI daemon. If any of these modules causes problems, the respective module can be excluded from loading or unloading in /etc/sysconfig/powersave/common. The system log (/var/log/messages) contains the messages of the modules, enabling you to see which components were detected.
In /proc/acpi, find a number of files that provide information on the system state or can be used to change some of the states actively. However, many features do not work yet, either because they are still under development or because they have not been implemented by the manufacturer.
All files (except dsdt and fadt) can be read with cat. In some files, settings can be modified by entering echo X <file> to specify suitable values for X (the objects in /proc are not real files on the hard disks but interfaces to the kernel). The most important files are described below:
General information about ACPI.
Here, specify when the system should wake from a sleep state. Currently, this feature is not fully supported.
Provides information about possible sleep states.
All events are reported here and processed by a daemon like acpid or powersaved. If no daemon accesses this file, events, such as a brief click on the power button or closing the lid, can be read with cat /proc/acpi/event (terminate with Ctrl + C).
These files contain the ACPI tables DSDT (differentiated system description table) and FADT (fixed ACPI description table). They can be read with acpidmp, acpidisasm, and dmdecode. These programs and their documentation are located in the package pmtools. For example, acpidmp DSDT | acpidisasm.
Shows whether the AC adapter is connected.
Detailed information about the battery state. The charge level is read by comparing the last full capacity from info with the remaining capacity from state. A more comfortable way to do this is to use one of the special programs described below (see Section 9.3.1.2. “ACPI Tools”). The charge level at which a battery event is triggered can be specified in alarm.
This directory contains information about various switches.
Shows if the fan is currently active. The fan can be activated and deactivated manually by writing 0 (on) or 3 (off) into this file. However, both the ACPI code in the kernel and the hardware (or the BIOS) overwrite this setting when it gets too warm.
Information about the energy saving options of the processor.
Information about the current processor state. An asterisk next to
indicates that the processor is idle. This is the most frequent state, as can be seen from the usage figure.This interface is no longer used.
Enables further linear throttling of the processor. This interface is outdated. Its function has been taken over by the settings in /etc/sysconfig/powersave/common (see Section 9.5.2.3. “Adapting the Power Consumption”).
If the performance and the throttling are automatically controlled by a daemon, the maximum limits can be specified here. Some of the limits are determined by the system, some can be adjusted by the user. However, their function has been taken over by the settings in /etc/sysconfig/powersave/common (see Section 9.5.2.2. “User-Defined Battery States”).
A separate subdirectory exists for every thermal zone. A thermal zone is an area with similar thermal properties whose number and names are designated by the hardware manufacturer. However, many of the possibilities offered by ACPI are rarely implemented. Instead, the temperature control is handled conventionally by the BIOS. The operating system is not given much opportunity to intervene, as the life span of the hardware is at stake. Therefore, some of the following descriptions only have a theoretical value.
Current temperature of the thermal zone.
The state indicates if everything is “ok” or if ACPI applies “active” or “passive” cooling. In the case of ACPI-independent fan control, this state will always be “ok”.
Enables the selection of the passive (less performance, very economical) or active (full performance, uninterrupted fan noise) cooling method for full ACPI control.
Enables the determination of temperature limits for triggering specific actions like passive or active cooling, suspension (“hot”), or a shutdown (“critical”).
If the value in temperature is not updated automatically when the temperature changes, the polling mode can be toggled here. The command echo X > /proc/acpi/thermal_zone/*/polling_frequency causes the temperature to be queried every X seconds. Set X=0 to disable polling.
Like the APM daemon, the ACPI daemon processes certain events. Currently, the only supported events are the actuation of switches, such as the power button or the lid contact. All events are logged in the system log. The actions to perform in response to these events can be determined in the variables ACPI_BUTTON_POWER and ACPI_BUTTON_LID in /etc/sysconfig/powermanagement. For more options, modify the script /usr/sbin/acpid_proxy or the acpid configuration in /etc/acpi/.
Unlike apmd, little is preconfigured here, as ACPI in Linux is still in a very dynamic development stage. If necessary, configure acpid according to your needs. If you have any suggestions regarding preparatory actions, contact us through http://www.suse.de/feedback.
The range of more or less comprehensive ACPI utilities includes tools that merely display information, like the battery charge level and the temperature (acpi, klaptopdaemon, wmacpimon, etc.), tools that facilitate the access to the structures in /proc/acpi or that assist in monitoring changes (akpi, acpiw, gtkacpiw), and tools for editing the ACPI tables in the BIOS (package pmtools).
There are two different types of problems. On one hand, the ACPI code of the kernel may contain bugs that were not detected in time. In this case, a solution will be made available for download. More often, however, the problems are caused by the BIOS. Sometimes, deviations from the ACPI specification are purposely integrated in the BIOS to circumvent errors in the ACPI implementation in other widespread operating systems. Hardware components that have serious errors in the ACPI implementation are recorded in a blacklist that prevents the Linux kernel from using ACPI for these components.
The first thing to do when problems are encountered is to update the BIOS. This will solve many problems. If the computer does not boot properly, one of the following boot parameters may be helpful:
Do not use ACPI for configuring the PCI devices.
Only perform a simple resource configuration. Do not use ACPI for other purposes.
Disable ACPI.
Problems Booting without ACPI | |
---|---|
Some newer machines (especially SMP systems and AMD64 systems) need ACPI for configuring the hardware correctly. On these machines, disabling ACPI can cause problems. |
Take a closer look at the boot messages. This can be done with the command dmesg | grep -2i acpi (or all messages, as the problem may not be caused by ACPI) after booting. If an error occurs while parsing an ACPI table, the most important table — the DSDT — can be replaced with an improved version. In this case, the faulty DSDT of the BIOS will be ignored. The procedure is described in Section 9.5.4. “Troubleshooting”.
In the kernel configuration, there is a switch for activating ACPI debug messages. If a kernel with ACPI debugging is compiled and installed, experts searching for an error can be supported with detailed information.
If you experience BIOS or hardware problems, it is always advisable to contact the manufacturer of the device. Although manufacturers may not always be able to provide assistance for Linux, it is still important that they hear the word “Linux” as often as possible. Manufacturers will only take the issue seriously if they realize that an adequate number of their customers use Linux.
Additional documentation and help:
http://www.columbia.edu/~ariel/acpi/acpi_howto.txt (slightly outdated ACPI HowTo, incomplete)
http://www.cpqlinux.com/acpi-howto.html (more detailed ACPI HowTo, contains DSDT patches)
http://www.intel.com/technology/iapc/acpi/faq.htm (ACPI FAQ @Intel)
http://acpi.sourceforge.net/ (the ACPI4Linux project at Sourceforge)
http://www.poupinou.org/acpi/ (DSDT patches by Bruno Ducrot)