ACPI (advanced configuration and power interface) was designed to enable the operating system to set up and control the individual hardware components. ACPI supersedes both PnP and APM. It 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. Because the operating system executes commands
stored in the BIOS, the functionality depends on the BIOS implementation.
The tables ACPI can detect and load are reported in
/var/log/boot.msg. See
Section 31.2.3, “Troubleshooting” for more information about
troubleshooting ACPI problems.
The CPU can save energy in three ways. Depending on the operating mode of the computer, these methods can be combined. Saving energy also means that the system heats up less and the fans are activated less frequently.
PowerNow! and
Speedstep are the designations AMD and
Intel use for this technology. However, this technology is also
applied in processors of other manufacturers. The clock frequency of
the CPU and its core voltage are reduced at the same time, resulting
in more than linear energy savings. This means that when the
frequency is halved (half performance), far less than half of the
energy is consumed. This technology is independent from ACPI. There
are two main approaches to performing CPU frequency scaling—by
the kernel itself or by a userspace application. Therefore, there are
different kernel governors that can be set below
/sys/devices/system/cpu/cpu*/cpufreq/.
If the userspace governor is set, the kernel gives the control of CPU frequency scaling to a userspace application, usually a daemon. In openSUSE distributions, this daemon is the powersaved package. When this implementation is used, the CPU frequency is adjusted in regard to the current system load. By default, one of the kernel implementations is used. However, on some hardware or in regard to specific processors or drivers, the userspace implementation is still the only working solution.
This is the kernel implementation of a dynamic CPU frequency policy and should work on most systems. As soon as there is a high system load, the CPU frequency is immediately increased. It is lowered on a low system load.
This governor is similar to the on demand implementation, except that a more conservative policy is used. The load of the system must be high for a specific amount of time before the CPU frequency is increased.
The cpu frequency is statically set to the lowest possible.
The cpu frequency is statically set to the highest possible.
This technology omits a certain percentage of the clock signal
impulses for the CPU. At 25% throttling, every fourth impulse is
omitted. At 87.5%, only every eighth impulse reaches the processor.
However, the energy savings are a little less than linear. Normally,
throttling is only used if frequency scaling is not available or to
maximize power savings. This technology must be controlled by a
special process, as well. The system interface is
/proc/acpi/processor/*/throttling.
The operating system puts the processor to sleep whenever there is no
activity. In this case, the operating system sends the CPU a
halt command. There are three states: C1, C2, and
C3. In the most economic state, C3, even the synchronization of the
processor cache with the main memory is halted. Therefore, this state
can only be applied if no other device modifies the contents of the
main memory via bus master activity. Some drivers prevent the use of
C3. The current state is displayed in
/proc/acpi/processor/*/power.
Frequency scaling and throttling are only relevant if the processor is busy, because the most economic C state is applied anyway when the processor is idle. If the CPU is busy, frequency scaling is the recommended power saving method. Often the processor only works with a partial load. In this case, it can be run with a lower frequency. Usually, dynamic frequency scaling controlled by the kernel on demand governor or a daemon, such as powersaved, is the best approach. A static setting to a low frequency is useful for battery operation or if you want the computer to run cool or be quiet.
Throttling should be used as the last resort, for example, to extend the battery operation time despite a high system load. However, some systems do not run smoothly when they are throttled too much. Moreover, CPU throttling does not make sense if the CPU has little to do.
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, 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
acpica).
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, 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 of 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. If the computer does not boot at all, 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. | |
Sometimes, the machine is confused by hardware that is attached over USB or FireWire. If a machine refuses to boot, unplug all unneeded hardware and try again.
Monitor the boot messages of the system with the command dmesg
| grep -2i acpi (or all messages, because 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
(Differentiaed System Description Table)—can
be replaced with an improved version. In this case, the faulty DSDT of
the BIOS is ignored. The procedure is described in
Section 31.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 manufacturers. Especially if they do not always provide assistance for Linux, they should be confronted with the problems. Manufacturers will only take the issue seriously if they realize that an adequate number of their customers use Linux.