Advanced Configuration and Power Interface

from Wikipedia, the free encyclopedia

The Advanced Configuration and Power Interface ( ACPI ) is an open industry standard for power management in desktop computers , notebooks and servers . It is being developed in the lead by the companies Hewlett-Packard , Intel , Microsoft , Phoenix Technologies and Toshiba and provides interfaces for hardware detection , device configuration and energy management.

It is particularly well known for the various energy saving modes ACPI-S1 to S5, which have replaced Advanced Power Management (APM).


In contrast to the older APM standard, control of the energy management lies entirely with the operating system , which has a better overview of the current power requirements and the savings options in a computer than the hardware- oriented BIOS . With ACPI, the computer's BIOS is only responsible for the details of communication with the hardware, but control lies with the operating system. Compared to APM, further options for saving energy are offered.

ACPI 1.0 was released in 1996. With version 2.0, support for 64-bit architectures was added in July 2000. Version 3.0 of September 2, 2004 was supplemented by support for PCI Express and Serial ATA as well as extended SMP capabilities and, based on practical experience with the implementations, clarified in some places. Version 4.0 was released on June 16, 2009. The innovations include support for USB 3.0 . Version 5.1 from August 2014 brought support for the ARMv8 architecture. The current version 6.0 was published in April 2015.

Intel has an ACPI reference implementation called ACPICA ( ACPI Component Architecture ), which is used in a slightly adapted form in the Linux kernel and the BSD derivatives , among other things . ACPICA implements parts of the ACPI software that are independent of the operating system, in particular the AML interpreter , which parses the ACPI tables provided by the hardware .

ACPI does not work on older hardware. For full ACPI support, the motherboard with its chipset , timer and BIOS as well as the operating system and, in some cases, the CPU must be ACPI-capable. Furthermore, a power supply according to ATX 2.01 or newer is required.

The hardware can signal certain events to the operating system via the System Control Interrupt (SCI). This can include, for example, switching from battery to mains power supply or waking up from energy-saving mode.

Energy management - energy saving modes according to the ACPI standard

There are many ways to save energy using ACPI.

The entire computer can be in one of four states, which are named "G0" to "G3" in the ACPI specification. "G0" - "Working" corresponds to the "active" state in which you can work with the computer, and "G3" - "Mechanical off" is a computer with the plug unplugged. In between there is the sleep state "G1", in which large parts of the computer are switched off, but from which it is still possible to return to the active state in a short time, and the "soft-off" state "G2", which allows a computer to use ATX -Standby voltage corresponds.

The system can sleep differently within G1 (S1 to S4). In the low sleep states, more system context is retained in the fast volatile memories, so that the system can be used again more quickly. Before entering the S4 state, the system context is written to a hard disk and restored from there when you wake up.

Important modes in the ACPI standard

Processor states (CPU states)

C-state Surname Latency to C0 Power consumption
C0 Operating mode 100%
C1 Stopped (stop) 0-01 µs 040%
C1E Enhanced Halt 01–2 µs 035%
C2 Stopped Clock (Stop Clock) 0–59 µs 030%
C2E Extended Stop 0–70 µs 028%
C3 Deep sleep 0–85 µs 026%
C4 Deeper Sleep -150 µs 024%
C4E / C5 Enhanced Deeper Sleep -250 µs 022%
C6 Deep Power Down -300 µs 019%
C7 Deeper Power Down -400 µs 015%

The power consumption differs between different systems and is only used here to better understand the different C-states.

Device states

D state description
D0 The device is switched on and fully functional
D1 Intermediate state, which may vary depending on the device
D2 Intermediate state, which may vary depending on the device
D3 Hot Device is connected to a power source and can change to a higher state
D3 Cold The device has no power supply and cannot execute any commands

Sleep states

S-state description
S0 System fully functional. All systems ready for immediate use.
S1 simplest sleep mode ; Few functions are switched off, the CPU is stopped ( throttle )
S2 extended sleep mode. Other components are switched off, especially the CPU cache
S3 Standby mode ( Suspend to RAM , STR, Suspend to memory , STM) - most of the hardware on the motherboard is switched off and the operating status is saved on a volatile memory
S4 Idle state (English "hibernation", "suspend to disk", "STD") - the operating state is saved on a non-volatile memory
S5 Soft-off mode , the system is virtually switched off, but the power supply unit supplies voltage and the system can be activated with a mechanical button ("power button") connected to the motherboard or - depending on the model and BIOS setting - also via the Network interface ( Wake On LAN ) must be reactivated

Individual devices in the system can be in the states D0 (on) to D3 (off). How much energy is saved in the two states in between and whether this is even available for a device is at the discretion of the hardware manufacturer.

Processors can be in different sub-states within the G0 state. C0 is the "working state". Every ACPI-capable processor can also use the C1 state, which is activated when the processor is idling. The hltinstruction is sent to the processor . As soon as there is an interrupt, it wakes up again. Mobile processors in particular also know the more powerful savings states C2, C3 or even higher, in which waking up takes increasingly longer (with C3 usually so much that it is not worth controlling this state because the way back to C0 takes too much time required). In the C states it is initially only about idle processors. In addition, many modern CPUs can throttle in several stages in the C0 cycle and core voltage with little workload. There can be any number of these “Performance States” (P-States). The operating system has to decide how much it throttles the processor when the workload is low, without a return to the highest clock speed "P0" taking an unreasonably long time.

System description tables, AML, ASL

The BIOS and chipset provide a series of tables that describe the system and its components or offer routines that the operating system can call. Some of them are stored in the form of a special byte code, the ACPI Machine Language (AML) . They can be translated between this machine-readable form and the human-readable ACPI Source Language (ASL) using a compiler and a disassembler . The required software tools are available for free download from Intel or Microsoft, so that people with ASL knowledge can repair faulty tables themselves, especially the DSDT ( Differentiated System Description Table ).

Incorrect tables lead to problems, especially under alternative operating systems such as Linux or xBSD, since some motherboard manufacturers only test their tables under Microsoft Windows. The Microsoft ACPI implementation is known for not following the standard exactly in some places, so that the manufacturers do not notice any problems. The two most common mistakes are that the tables assume that the motherboard will only run under Microsoft Windows in any case or that it does not return any value in certain functions (implicit return). The ACPI implementations of the free operating systems must work around these errors.

The following tables exist among others:

  • RSDP ( Root System Description Pointer )
  • RSDT ( Root System Description Table )
  • DSDT ( Differentiated System Description Table )
  • XSDT ( Extended System Description Table )
  • FADT ( Fixed ACPI Description Table )
  • FACS ( Firmware ACPI Control Structure )
  • SBST ( Smart Battery Table )
  • ECDT ( Embedded Controller Boot Resources Table )
  • SRAT ( System Resource Affinity Table )
  • SLIT ( System Locality Distance Information Table )

Table descriptions

The system description tables are a hierarchical structure that consists of several sub-tables.

RSDP (Root System Description Pointer)
This table contains a pointer to the other tables and is stored by the main board either in the EBDA (Extended Bios Data Area) or in the memory area from E0000h to FFFFFh. The ACPI driver of the operating system searches the memory for the “magic” character string RSD PTR and thus receives the addresses of the RSDP and the other tables. On computers with EFI , the RSDP is in the EFI and it is not necessary to search the main memory.
RSDT (Root System Description Table)
The RSDT contains one or more references to other tables that contain information about the procedures - according to certain standards - that play a role in the system. In the ACPI system, for example, there is always a reference to the Fixed ACPI Description Table (FADT).
DSDT (Differentiated System Description Table)
DSDT describes implemented system functions such as energy management, plug and play and cooling in so-called definition blocks. In addition to control information, definition blocks also contain control functions encoded in AML (ACPI Machine Language). The definition blocks entered for ACPI functions in the DSDT form the basis for the functioning of the ACPI functions in the system. The DSDT Differentiated Definition Block is loaded during system boot and remains in memory.
XSDT (Extended System Description Table)
This table contains references to additional descriptions of the configuration and the system implementation.
FADT (Fixed ACPI Description Table)
This table contains static, system-related information on energy management, as well as pointers to the firmware ACPI Control Structure (FACS) and the Differentiated System Description Table (DSDT).
FACS (Firmware ACPI Control Structure)
The FACS stores the system-specific data for the ACPI entered by the BIOS. This data is the basis for the communication between the operating system and firmware.
SBST (Smart Battery Table)
An ACPI table used by platforms with Smart Battery subsystems. The table defines power supply limit values ​​which cause the system to switch to certain sleep states and to make the user aware of them.

ECDT (Embedded Controller Boot Resources Table)
SRAT (System Resource Affinity Table)
This table is read out by NUMA- enabled operating systems in order to be able to assign local threads ( activity carriers ) also local memory. The memory access time is thus minimized and the system performance increases. A possible “node interleaving” function, which can be found in some AMD Opteron BIOS settings, is switched off in NUMA-compatible operating systems and suitable NUMA-compatible applications, SRAT is of course included.
SLIT (System Locality Distance Information Table)
This table shows the distance between the nodes. This is needed in order to allocate requested memory on the next (i.e. fastest) node if the local memory is too small.


ACPI has been criticized for being particularly complicated. For operating systems other than Windows, it is difficult to implement in a proper way. Intel is therefore working on an alternative called Simple Firmware Interface (SFI) for use in mobile devices , but recommends always using ACPI if the hardware provides both.

Because of errors in the ACPI implementation of many hardware components, the operating system must correct this undocumented behavior using various methods. The Linux operating system presents itself to the BIOS as Windows in order to obtain the better tested Windows mode.

There is an "ACPI Machine Language" compiler from Intel and one from Microsoft. Manufacturers prefer the Microsoft implementation because it works better with Windows. The manufacturers want to avoid hardware defects caused by incorrect energy-saving measures.

In 1999 Bill Gates considered designing ACPI in such a way that other operating systems had problems with its implementation:

“One thing I find myself wondering about is whether we shouldn't try and make the“ ACPI ”extensions somehow Windows specific. It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work. Maybe there is no way to avoid this problem but it does bother me. Maybe we could define the APIs so that they work well with NT and not the others even if they are open. Or maybe we could patent something related to this. "

“I wonder if we shouldn't try to make the ACPI extensions Windows specific in some way. It is not very cheap when we and our partners do the work and Linux works wonderfully with it without having contributed anything. Maybe you can't avoid it, but it bothers me. Perhaps we could define the APIs to work well with NT but not the others, even though they are open. Or maybe we could patent something in this context. "

- Bill Gates : E-Mail “ACPI extensions” from January 24th, 1999

Web links

Individual evidence

  1. UEFI Forum's New ACPI 5.1 Specification Adapts Configuration and Power Interface to 64-bit Focused Features of the ARMv8-A Architectures
  2. ACPI 6.0 (PDF).
  4. Simple Firmware Interface FAQ ( Memento from September 17, 2009 in the Internet Archive )
  5. Email from Bill Gates (PDF; 22 kB)