|
|
|
|
27.3 ACPI
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 27.3.4,
Troubleshooting for more information
about troubleshooting ACPI problems.
27.3.1 ACPI in Action
If the kernel detects an ACPI BIOS when the system is booted,
ACPI is activated automatically and APM is deactivated. The
boot parameter acpi=force 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.
Subsequently, a number of modules must be loaded. This is done by the start
script of acpid. If any of these modules cause 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.
/proc/acpi now contains a number of files that provide
information about the system state or can be used to change some of the
states. Some features do not work yet because they are still under
development and the support of some functions largely depends on the
implementation of the manufacturer.
All files (except dsdt and fadt)
can be read with cat. In some files, settings can be
modified with echo, for example, echo X
> file to specify
suitable values for X. One possiblity for easy access to those values is
the powersave command, which acts as a front-end for the
Powersave daemon. The following describes the most important files:
- /proc/acpi/info
-
General information about ACPI.
- /proc/acpi/alarm
-
Here, specify when the system should wake
from a sleep state. Currently, this feature is not
fully supported.
- /proc/acpi/sleep
-
Provides information about possible sleep states.
- /proc/acpi/event
-
All events are reported here and processed by the Powersave daemon
(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).
-
/proc/acpi/dsdt and
/proc/acpi/fadt
-
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.
- /proc/acpi/ac_adapter/AC/state
-
Shows whether the AC adapter is connected.
-
/proc/acpi/battery/BAT*/{alarm,info,state}
-
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 introduced in
Section 27.3.3,
ACPI Tools. The charge level at
which a battery event (such as warning, low and critical) is triggered
can be specified in alarm.
- /proc/acpi/button
-
This directory contains information about various switches, like the
laptop lid and buttons.
- /proc/acpi/fan/FAN/state
-
Shows if the fan is currently active. Activate or deactivate the
fan 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 the system gets too warm.
- /proc/acpi/processor/*
-
A separate subdirectory is kept for each CPU included in your
system.
- /proc/acpi/processor/*/info
-
Information about the energy saving options of the processor.
- /proc/acpi/processor/*/power
-
Information about the current processor state. An asterisk next to
C2 indicates that the processor is idle. This is the
most frequent state, as can be seen from the usage
value.
- /proc/acpi/processor/*/throttling
-
Can be used to set the throttling of the processor clock.
Usually, throttling is possible in eight levels. This is
independent of the frequency control of the CPU.
- /proc/acpi/processor/*/limit
-
If the performance (outdated) 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.
-
/proc/acpi/thermal_zone/
-
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, because the life span of the hardware is
at stake. Therefore, some of the files only have
a theoretical value.
- /proc/acpi/thermal_zone/*/temperature
-
Current temperature of the thermal zone.
- /proc/acpi/thermal_zone/*/state
-
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 is always
ok.
- /proc/acpi/thermal_zone/*/cooling_mode
-
Select the cooling method controlled by ACPI. Choose from passive (less
performance, economical) or active cooling mode (full
performance, fan noise).
- /proc/acpi/thermal_zone/*/trip_points
-
Enables the determination of temperature limits for triggering specific
actions, like passive or active cooling, suspension
(hot), or a shutdown (critical).
The possible actions are defined in the DSDT (device-dependent). The
trip points determined in the ACPI specification are
critical, hot,
passive, active1, and
active2. Even if not all of them are implemented,
they must always be entered in this file in this order. For example, the
entry echo 90:0:70:0:0 >
trip_points sets the temperature for
critical to 90 and the temperature
for passive to 70 (all
temperatures measured in degrees Celsius).
-
/proc/acpi/thermal_zone/*/polling_frequency
-
If the value in temperature is not updated
automatically when the temperature changes, toggle the polling mode
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.
None of these settings, information, and events need to be edited manually.
This can be done with the Powersave daemon (powersaved) and its various
front-ends, like powersave, kpowersave, and wmpowersave. See
Section 27.3.3,
ACPI Tools.
27.3.2 Controlling the CPU Performance
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.
- Frequency and Voltage Scaling
-
and
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 APM or 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/.
- userspace governor
-
If the userspace governor is set, the kernel gives the control of CPU
frequency scaling to a userspace application, usually a daemon. In
SUSE Linux Enterprise 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.
- ondemand governor
-
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.
- conservative governor
-
This governor is similar to the ondemand 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.
- powersave governor
-
The cpu frequency is statically set to the lowest
possible.
- performance governor
-
The cpu frequency is statically set to the highest possible.
- Throttling the Clock Frequency
-
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,
too, must be controlled by a special process. The system
interface is
/proc/acpi/processor/*/throttling.
- Putting the Processor to Sleep
-
The operating system puts the processor to
sleep whenever there is nothing to do. 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 ondemand
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 be cool or 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.
In SUSE Linux Enterprise these technologies are controlled by the powersave
daemon. The configuration is explained in
Section 27.5,
The powersave Package.
27.3.4 Troubleshooting
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. If the computer does not boot at all,
one of the following boot parameters may be helpful:
- pci=noacpi
-
Do not use ACPI for configuring the PCI devices.
- acpi=oldboot
-
Only perform a simple resource configuration. Do not use ACPI
for other purposes.
- acpi=off
-
Disable ACPI.
WARNING: 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.
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—can be replaced with an
improved version. In this case, the faulty DSDT of the BIOS is
ignored. The procedure is described in Section 27.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 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.
For More Information
Additional documentation and help on ACPI:
|
|
|