Advanced Configuration and Power Interface: Unterschied zwischen den Versionen

Aus Foxwiki
 
(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' - Kurzbeschreibung
'''Advanced Configuration and Power Interface''' ('''ACPI''') - Industriestandard zur Energieverwaltung in Cputersystemen
 
== Beschreibung ==
== Beschreibung ==
Das '''Advanced Configuration and Power Interface''' ('''ACPI''') ist ein offener [[Industriestandard]] für Energieverwaltung in [[Desktop-Computer]]n, [[Notebook]]s und [[Server]]n. Er wird von Unternehmen wie [[ARM Limited|ARM]], [[Hewlett-Packard]], [[Intel]], [[Microsoft]], [[Phoenix Technologies]] und [[Toshiba]] entwickelt und stellt Schnittstellen zur [[Hardware-Erkennung]], [[Gerätekonfiguration]] und zur Energieverwaltung zur Verfügung.
Das '''Advanced Configuration and Power Interface''' ('''ACPI''') ist ein offener [[Industriestandard]] für Energieverwaltung in [[Desktop-Computer]]n, [[Notebook]]s und [[Server]]n. Er wird von Unternehmen wie [[ARM Limited|ARM]], [[Hewlett-Packard]], [[Intel]], [[Microsoft]], [[Phoenix Technologies]] und [[Toshiba]] entwickelt und stellt Schnittstellen zur [[Hardware-Erkennung]], [[Gerätekonfiguration]] und zur Energieverwaltung zur Verfügung.


Zeile 9: Zeile 9:
Die Kontrolle über die Energieverwaltung liegt, anders als beim älteren [[Advanced Power Management|APM]]-Standard, komplett beim [[Betriebssystem]], das einen besseren Überblick über den momentanen Leistungsbedarf und die Sparmöglichkeiten in einem Rechner hat als das hardwareorientierte [[BIOS]]. Mit ACPI ist das BIOS des Rechners nur noch für die Details der Kommunikation mit der Hardware verantwortlich, die Kontrolle liegt aber beim Betriebssystem. Gegenüber APM werden weitergehende Möglichkeiten zum Energiesparen angeboten.
Die Kontrolle über die Energieverwaltung liegt, anders als beim älteren [[Advanced Power Management|APM]]-Standard, komplett beim [[Betriebssystem]], das einen besseren Überblick über den momentanen Leistungsbedarf und die Sparmöglichkeiten in einem Rechner hat als das hardwareorientierte [[BIOS]]. Mit ACPI ist das BIOS des Rechners nur noch für die Details der Kommunikation mit der Hardware verantwortlich, die Kontrolle liegt aber beim Betriebssystem. Gegenüber APM werden weitergehende Möglichkeiten zum Energiesparen angeboten.


ACPI 1.0, spezifiziert von Intel, Microsoft und Toshiba, wurde im Dezember 1996 veröffentlicht.<ref>{{Internetquelle |autor=Bernhard Haluschak |url=https://www.tecchannel.de/a/grundlagen-energiemanagement-mit-acpi-3-0,402439 |titel=Energiemanagement mit ACPI 3.0 |hrsg=[[International Data Group]] |datum=2004-12-10 |abruf=2022-12-23}}</ref> Mit der Version 2.0 wurde im Juli 2000 Unterstützung für 64-Bit-Architekturen hinzugefügt. Die Version 3.0 vom 2. September 2004 wurde um die Unterstützung für [[PCI Express]] und [[Serial ATA]] sowie erweiterte [[Symmetrisches Multiprozessorsystem|SMP]]-Fähigkeiten ergänzt und auf Grund von Erfahrungen aus der Praxis mit den Implementierungen an einigen Stellen klarer gefasst. Version 4.0 wurde am 16. Juni 2009 veröffentlicht. Zu den Neuerungen gehörte unter anderem die Unterstützung von [[Universal Serial Bus|USB 3.0]].
ACPI 1.0, spezifiziert von Intel, Microsoft und Toshiba, wurde im Dezember 1996 veröffentlicht. Mit der Version 2.0 wurde im Juli 2000 Unterstützung für 64-Bit-Architekturen hinzugefügt. Die Version 3.0 vom 2. September 2004 wurde um die Unterstützung für [[PCI Express]] und [[Serial ATA]] sowie erweiterte [[Symmetrisches Multiprozessorsystem|SMP]]-Fähigkeiten ergänzt und auf Grund von Erfahrungen aus der Praxis mit den Implementierungen an einigen Stellen klarer gefasst. Version 4.0 wurde am 16. Juni 2009 veröffentlicht. Zu den Neuerungen gehörte unter anderem die Unterstützung von [[Universal Serial Bus|USB 3.0]].


Im Oktober 2013 kam die Weiterentwicklung in die Zuständigkeit vom [[Unified Extensible Firmware Interface|UEFI]]&nbsp;Forum.<ref>{{Internetquelle |url=https://uefi.org/acpi/specs |titel=Preexisting ACPI Specifications |werk=uefi.org |abruf=2022-12-23}}</ref> Version 5.1 vom August 2014 brachte Unterstützung für die [[Arm-Architektur#Armv8-A (2011)|Armv8-A]]-Architektur.<ref>[http://www.uefi.org/ACPIv5.1 UEFI Forum’s New ACPI 5.1 Specification Adapts Configuration and Power Interface to 64-bit Focused Features of the ARMv8-A Architectures]</ref>
Im Oktober 2013 kam die Weiterentwicklung in die Zuständigkeit vom [[Unified Extensible Firmware Interface|UEFI]]&nbsp;Forum.


Von Intel existiert eine ACPI-Referenzimplementierung mit Namen ACPICA (''ACPI Component Architecture''), die in leicht angepasster Form unter anderem im [[Linux (Kernel)|Linux-Kernel]] und den [[Berkeley Software Distribution|BSD-Derivaten]] verwendet wird. Die ACPICA implementiert betriebssystemunabhängige Teile der ACPI-Software, hier vor allem den ''AML-Interpreter'', der die von der Hardware bereitgestellten ACPI-Tabellen [[Parser|parst]].
Von Intel existiert eine ACPI-Referenzimplementierung mit Namen ACPICA (''ACPI Component Architecture''), die in leicht angepasster Form unter anderem im [[Linux (Kernel)|Linux-Kernel]] und den [[Berkeley Software Distribution|BSD-Derivaten]] verwendet wird. Die ACPICA implementiert betriebssystemunabhängige Teile der ACPI-Software, hier vor allem den ''AML-Interpreter'', der die von der Hardware bereitgestellten ACPI-Tabellen [[Parser|parst]].
Zeile 26: Zeile 26:
Innerhalb von G1 kann das System unterschiedlich „tief“ schlafen (S1 bis S4). In den niedrigen Schlafzuständen wird mehr Systemkontext in den schnellen flüchtigen Speichern behalten, so dass das System schneller wieder benutzbar ist. Vor Eintritt in den S4-Zustand wird der Systemkontext auf eine Festplatte geschrieben und beim Aufwachen von dort wiederhergestellt.
Innerhalb von G1 kann das System unterschiedlich „tief“ schlafen (S1 bis S4). In den niedrigen Schlafzuständen wird mehr Systemkontext in den schnellen flüchtigen Speichern behalten, so dass das System schneller wieder benutzbar ist. Vor Eintritt in den S4-Zustand wird der Systemkontext auf eine Festplatte geschrieben und beim Aufwachen von dort wiederhergestellt.


=== Wichtige Modi im ACPI-Standard ===
== Wichtige Modi im ACPI-Standard ==
==== Prozessorzustände (CPU-States) ====
==== Prozessorzustände (CPU-States) ====
{| class="wikitable"
{| class="wikitable"
Zeile 84: Zeile 84:
|{{0}}15 %
|{{0}}15 %
|}
|}
Die Leistungsaufnahme weicht zwischen verschiedenen Systemen ab und dient hier lediglich der besseren Vorstellung der unterschiedlichen C-States.<ref>[https://www.technikaffe.de/anleitung-32-c_states_p_states_s_states__energieverwaltung_erklaert technikaffe.de]</ref>
Die Leistungsaufnahme weicht zwischen verschiedenen Systemen ab und dient hier lediglich der besseren Vorstellung der unterschiedlichen C-States.


==== Gerätezustände (Device-States) ====
==== Gerätezustände (Device-States) ====
Zeile 178: Zeile 178:


== Kritik ==
== Kritik ==
ACPI wird dafür kritisiert, besonders kompliziert zu sein. Für andere Betriebssysteme als Windows sei es schwer, in ordentlicher Weise zu implementieren. [[Intel]] arbeitet deshalb für den Einsatz in Mobilgeräten an einer Alternative namens [[Simple Firmware Interface]] (SFI), empfiehlt jedoch, wenn eine Hardware beides zur Verfügung stellt, stets ACPI zu verwenden.<ref name="sfi-faq">{{Webarchiv |url=http://simplefirmware.org/faq |text=Simple Firmware Interface FAQ |wayback=20090917061911}}</ref>
ACPI wird dafür kritisiert, besonders kompliziert zu sein. Für andere Betriebssysteme als Windows sei es schwer, in ordentlicher Weise zu implementieren. [[Intel]] arbeitet deshalb für den Einsatz in Mobilgeräten an einer Alternative namens [[Simple Firmware Interface]] (SFI), empfiehlt jedoch, wenn eine Hardware beides zur Verfügung stellt, stets ACPI zu verwenden.


Wegen Fehlern in der ACPI-Implementierung vieler Hardwarekomponenten muss das Betriebssystem dieses undokumentierte Verhalten mit verschiedenen Methoden korrigieren. Das Betriebssystem Linux gibt sich dem BIOS gegenüber als Windows aus, um den besser getesteten Windows-Modus zu erhalten.
Wegen Fehlern in der ACPI-Implementierung vieler Hardwarekomponenten muss das Betriebssystem dieses undokumentierte Verhalten mit verschiedenen Methoden korrigieren. Das Betriebssystem Linux gibt sich dem BIOS gegenüber als Windows aus, um den besser getesteten Windows-Modus zu erhalten.
Zeile 184: Zeile 184:
Es gibt einen „ACPI-Machine-Language“-Compiler von Intel und einen von Microsoft. Die Hersteller bevorzugen die Microsoft-Implementierung, weil sie besser mit Windows zusammenarbeitet. Hardware-Defekte durch falsche Stromsparmaßnahmen wollen die Hersteller unbedingt vermeiden.
Es gibt einen „ACPI-Machine-Language“-Compiler von Intel und einen von Microsoft. Die Hersteller bevorzugen die Microsoft-Implementierung, weil sie besser mit Windows zusammenarbeitet. Hardware-Defekte durch falsche Stromsparmaßnahmen wollen die Hersteller unbedingt vermeiden.


[[Bill Gates]] überlegte 1999, ob er ACPI so gestalten sollte, dass andere Betriebssysteme Probleme mit dessen Implementierung haben:<ref>[http://golem.de/0704/51686.html Microsoft: ACPI sollte nur unter Windows funktionieren – Patente sollten Verwendung durch offene Betriebssysteme verhindern]</ref>
[[Bill Gates]] überlegte 1999, ob er ACPI so gestalten sollte, dass andere Betriebssysteme Probleme mit dessen Implementierung haben:
{{Zitat
{{Zitat
  |Text=One thing I find myself wondering about is whether we shouldn’t try and make the “ACPI” extensions somehow Windows specific.
  |Text=One thing I find myself wondering about is whether we shouldn’t try and make the “ACPI” extensions somehow Windows specific.
Zeile 202: Zeile 202:


== Beschreibung ==
== Beschreibung ==
# ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20210730/utaddress-204)


  # ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20210730/utaddress-204)
  acpi_enforce_resources= [ACPI]
{ strict | lax | no }
    acpi_enforce_resources= [ACPI]
Check for resource conflicts between native drivers
            { strict | lax | no }
and ACPI OperationRegions (SystemIO and SystemMemory
            Check for resource conflicts between native drivers
only). IO ports and memory declared in ACPI might be
            and ACPI OperationRegions (SystemIO and SystemMemory
used by the ACPI subsystem in arbitrary AML code and
            only). IO ports and memory declared in ACPI might be
can interfere with legacy drivers.
            used by the ACPI subsystem in arbitrary AML code and
 
            can interfere with legacy drivers.
  strict (default): access to resources claimed by ACPI
   
is denied; legacy drivers trying to access reserved
            strict (default): access to resources claimed by ACPI
resources will fail to bind to device using them.
            is denied; legacy drivers trying to access reserved
 
            resources will fail to bind to device using them.
  lax: access to resources claimed by ACPI is allowed;
   
legacy drivers trying to access reserved resources
            lax: access to resources claimed by ACPI is allowed;
will bind successfully but a warning message is logged.
            legacy drivers trying to access reserved resources
 
            will bind successfully but a warning message is logged.
  no: ACPI OperationRegions are not marked as reserved,
   
no further checks are performed.
            no: ACPI OperationRegions are not marked as reserved,
            no further checks are performed.


=== Solution ===
=== Solution ===
Zeile 236: Zeile 235:
===== Projekt =====
===== Projekt =====
===== Weblinks =====
===== Weblinks =====
# https://de.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
# [https://www.acpica.org/ ACPI Component Architecture] – Intel Corporation
# [https://www.acpica.org/ ACPI Component Architecture] – Intel Corporation
# [https://www.heise.de/ct/Redaktion/ciw/acpi.html Tipps zur ACPI-Konfiguration] – [[c’t]]-Redaktion, Einführung
# [https://www.heise.de/ct/Redaktion/ciw/acpi.html Tipps zur ACPI-Konfiguration] – [[c’t]]-Redaktion, Einführung

Aktuelle Version vom 7. Juli 2023, 23:13 Uhr

Advanced Configuration and Power Interface (ACPI) - Industriestandard zur Energieverwaltung in Cputersystemen

Beschreibung

Das Advanced Configuration and Power Interface (ACPI) ist ein offener Industriestandard für Energieverwaltung in Desktop-Computern, Notebooks und Servern. Er wird von Unternehmen wie ARM, Hewlett-Packard, Intel, Microsoft, Phoenix Technologies und Toshiba entwickelt und stellt Schnittstellen zur Hardware-Erkennung, Gerätekonfiguration und zur Energieverwaltung zur Verfügung.

Insbesondere bekannt ist er durch die verschiedenen Energiesparmodi ACPI-S1 bis S5, die das Advanced Power Management (APM) abgelöst haben.

Grundlagen

Die Kontrolle über die Energieverwaltung liegt, anders als beim älteren APM-Standard, komplett beim Betriebssystem, das einen besseren Überblick über den momentanen Leistungsbedarf und die Sparmöglichkeiten in einem Rechner hat als das hardwareorientierte BIOS. Mit ACPI ist das BIOS des Rechners nur noch für die Details der Kommunikation mit der Hardware verantwortlich, die Kontrolle liegt aber beim Betriebssystem. Gegenüber APM werden weitergehende Möglichkeiten zum Energiesparen angeboten.

ACPI 1.0, spezifiziert von Intel, Microsoft und Toshiba, wurde im Dezember 1996 veröffentlicht. Mit der Version 2.0 wurde im Juli 2000 Unterstützung für 64-Bit-Architekturen hinzugefügt. Die Version 3.0 vom 2. September 2004 wurde um die Unterstützung für PCI Express und Serial ATA sowie erweiterte SMP-Fähigkeiten ergänzt und auf Grund von Erfahrungen aus der Praxis mit den Implementierungen an einigen Stellen klarer gefasst. Version 4.0 wurde am 16. Juni 2009 veröffentlicht. Zu den Neuerungen gehörte unter anderem die Unterstützung von USB 3.0.

Im Oktober 2013 kam die Weiterentwicklung in die Zuständigkeit vom UEFI Forum.

Von Intel existiert eine ACPI-Referenzimplementierung mit Namen ACPICA (ACPI Component Architecture), die in leicht angepasster Form unter anderem im Linux-Kernel und den BSD-Derivaten verwendet wird. Die ACPICA implementiert betriebssystemunabhängige Teile der ACPI-Software, hier vor allem den AML-Interpreter, der die von der Hardware bereitgestellten ACPI-Tabellen parst.

ACPI funktioniert nicht auf älterer Hardware. Für volle ACPI-Unterstützung müssen sowohl die Hauptplatine mit ihrem Chipsatz, Timer und BIOS als auch das Betriebssystem und teilweise auch die CPU ACPI-fähig sein. Des Weiteren wird ein Netzteil nach ATX 2.01 oder neuer benötigt.

Die Hardware kann über den System Control Interrupt (SCI) bestimmte Ereignisse an das Betriebssystem signalisieren. Dazu können beispielsweise das Umschalten von Batterie- auf Netzstromversorgung oder das Aufwachen aus dem Energiesparmodus gehören.

Energieverwaltung – Energiesparmodi nach ACPI-Standard

Die Möglichkeiten, unter Verwendung von ACPI Energie zu sparen, sind vielfältig.

Der gesamte Rechner kann sich in einem von vier Zuständen befinden, die in der ACPI-Spezifikation „G0“ bis „G3“ genannt werden. „G0“ – „Working“ entspricht dabei dem „aktiven“ Zustand, in dem mit dem Computer gearbeitet werden kann, und „G3“ – „Mechanical off“, also „mechanisch abgeschaltet“, ist ein Rechner mit gezogenem Stecker. Dazwischen liegt der Schlafzustand „G1“, in dem große Teile des Rechners abgeschaltet sind, aber aus dem dennoch in kurzer Zeit in den aktiven Zustand zurückgekehrt werden kann, und der „Soft-Off“-Zustand „G2“, der einem Computer auf ATX-Standby-Spannung entspricht.

Innerhalb von G1 kann das System unterschiedlich „tief“ schlafen (S1 bis S4). In den niedrigen Schlafzuständen wird mehr Systemkontext in den schnellen flüchtigen Speichern behalten, so dass das System schneller wieder benutzbar ist. Vor Eintritt in den S4-Zustand wird der Systemkontext auf eine Festplatte geschrieben und beim Aufwachen von dort wiederhergestellt.

Wichtige Modi im ACPI-Standard

Prozessorzustände (CPU-States)

C-State Name Latenz zu C0 Leistungsaufnahme
C0 Arbeitszustand (Operating Mode) 100 %
C1 Angehalten (Halt) Vorlage:01 µs Vorlage:040 %
C1E Erweiterter Halt (Enhanced Halt) Vorlage:01–2 µs Vorlage:035 %
C2 Gestoppter Takt (Stop Clock) Vorlage:059 µs Vorlage:030 %
C2E Erweiterter Stop (Extended Stop) Vorlage:070 µs Vorlage:028 %
C3 Tiefer Schlaf (Deep Sleep) Vorlage:085 µs Vorlage:026 %
C4 Tieferer Schlaf (Deeper Sleep) Vorlage:0150 µs Vorlage:024 %
C4E/C5 Erweiterter tiefer Schlaf (Enhanced Deeper Sleep) Vorlage:0250 µs Vorlage:022 %
C6 Tiefes Abschalten (Deep Power Down) Vorlage:0300 µs Vorlage:019 %
C7 Tieferes Abschalten (Deeper Power Down) Vorlage:0400 µs Vorlage:015 %

Die Leistungsaufnahme weicht zwischen verschiedenen Systemen ab und dient hier lediglich der besseren Vorstellung der unterschiedlichen C-States.

Gerätezustände (Device-States)

D-State Beschreibung
D0 Gerät ist eingeschaltet und voll funktionsfähig
D1 Zwischenzustand, der je nach Gerät abweichen kann
D2 Zwischenzustand, der je nach Gerät abweichen kann
D3 Hot Gerät ist an einer Stromquelle angeschlossen und kann in einen höheren Zustand wechseln
D3 Cold Gerät hat keine Stromzufuhr und kann keine Kommandos ausführen

Ruhezustände (Sleep-States)

S-State Beschreibung
S0 System voll funktionsfähig. Alle Systeme sofort einsatzbereit.
S1 einfachster Schlafmodus; wenige Funktionen sind abgeschaltet, die CPU ist angehalten (Throttle)
S2 erweiterter Schlafmodus. Weitere Komponenten sind abgeschaltet, insbesondere der Cache der CPU
S3 Standby-Modus (Suspend to RAM, STR, Suspend to memory, STM) – die meiste Hardware der Hauptplatine ist abgeschaltet, der Betriebszustand auf einem flüchtigen Speicher gesichert
S4 Ruhezustand (englisch „hibernation“, „suspend to disk“, „STD“) – der Betriebszustand ist auf einem nicht-flüchtigen Speicher gesichert
S5 Soft-Off-Modus, System ist quasi ausgeschaltet, aber das Netzteil liefert Spannung und das System kann mit einem mechanischen Taster („Einschaltknopf“), der an der Hauptplatine angeschlossen ist, oder – je nach Modell und BIOS-Einstellung – auch über die Netzwerkschnittstelle (Wake On LAN) wieder aktiviert werden

Einzelne Geräte im System können sich in den Zuständen D0 (an) bis D3 (aus) befinden. Wie viel Energie in den beiden dazwischen liegenden Zuständen gespart wird und ob diese überhaupt für ein Gerät zur Verfügung stehen, liegt im Ermessen des Hardware-Herstellers.

Prozessoren können sich innerhalb des G0-Zustands in verschiedenen Unterzuständen befinden. C0 ist dabei der „Arbeitszustand“. Jeder ACPI-fähige Prozessor beherrscht darüber hinaus den C1-Zustand, der aktiviert wird, wenn der Prozessor leerläuft. Dabei wird dem Prozessor die hlt-Instruktion gesendet. Sobald ein Interrupt anliegt, wacht er wieder auf. Besonders Mobilprozessoren kennen darüber hinaus noch die stärkeren Sparzustände C2, C3 oder noch höher, bei denen das Aufwachen zunehmend länger dauert (bei C3 meist bereits so viel, dass es sich nicht lohnt, diesen Zustand einzusteuern, da der Weg zurück nach C0 zu viel Zeit benötigt). In den C-Zuständen geht es zunächst nur um leerlaufende Prozessoren. Darüber hinaus können viele moderne CPUs bei wenig Arbeitsaufkommen in C0 Takt und Kernspannung mehrstufig drosseln. Von diesen „Performance States“ (P-States) kann es beliebig viele geben. Das Betriebssystem muss entscheiden, wie stark es den Prozessor bei niedrigem Arbeitsaufkommen drosselt, ohne dass eine Rückkehr zur höchsten Taktstufe „P0“ unangemessen lange dauert.

Systembeschreibungs-Tabellen, AML, ASL

BIOS und Chipsatz stellen eine Reihe von Tabellen zur Verfügung, die das System und seine Komponenten beschreiben oder Routinen anbieten, die das Betriebssystem aufrufen kann. Sie sind teilweise in Form eines speziellen Bytecodes, der ACPI Machine Language (AML), hinterlegt. Sie können mit einem Compiler und einem Disassembler zwischen dieser maschinenlesbaren Form und der menschenlesbaren ACPI Source Language (ASL) übersetzt werden. Die benötigten Software-Werkzeuge werden von Intel oder Microsoft zum kostenlosen Herunterladen angeboten, so dass es für Menschen mit ASL-Kenntnissen möglich ist, fehlerhafte Tabellen, hier vor allem die DSDT (Differentiated System Description Table) selbst zu reparieren.

Fehlerhafte Tabellen führen besonders unter alternativen Betriebssystem wie Linux oder xBSD zu Problemen, da einige Hauptplatinenhersteller ihre Tabellen nur unter Microsoft Windows testen. Die Microsoft-ACPI-Implementierung ist dafür bekannt, an einigen Stellen nicht zeichengetreu den Standard zu befolgen, so dass eventuelle Probleme den Herstellern nicht auffallen. Die zwei häufigsten Fehler sind, dass die Tabellen davon ausgehen, dass die Hauptplatine in jedem Fall nur unter Microsoft Windows laufen wird oder sie in bestimmten Funktionen keinen Wert zurückgeben (impliziter Return). Die ACPI-Implementierungen der freien Betriebssysteme müssen um diese Fehler herumarbeiten.

Folgende Tabellen existieren unter anderem:

  • 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)

Tabellenbeschreibungen

Die Systembeschreibungstabellen sind eine hierarchisch aufgebaute Struktur, die aus mehreren Untertabellen besteht.

RSDP (Root System Description Pointer)
Diese Tabelle enthält einen Zeiger auf die weiteren Tabellen und wird von der Hauptplatine entweder in der EBDA (Extended BIOS Data Area) oder im Speicherbereich von E0000h bis FFFFFh abgelegt. Der ACPI-Treiber des Betriebssystems sucht den Speicher nach der „magischen“ Zeichenkette RSD PTR  ab und erhält so die Adressen des RSDP und der weiteren Tabellen. Bei Rechnern mit EFI steht der RSDP im EFI und das Durchsuchen des Arbeitsspeichers ist nicht nötig.
RSDT (Root System Description Table)
Die RSDT enthält einen oder mehrere Verweise auf andere Tabellen, die Informationen über die Verfahrensweisen – nach bestimmten Standards – die im System eine Rolle spielen, enthalten. So ist im ACPI-System zum Beispiel immer der Verweis auf die Fixed ACPI Description Table (FADT) vorhanden.
DSDT (Differentiated System Description Table)
DSDT beschreibt implementierte Systemfunktionen wie Energieverwaltung, Plug and Play und Kühlung in sogenannten Definition Blocks. Definition Blocks enthalten neben Informationen zur Ansteuerung auch in AML (ACPI Machine Language) kodierte Steuerfunktionen. Die für ACPI-Funktionen in der DSDT eingetragenen Definition Blocks bilden die Grundlage für das Funktionieren der ACPI-Funktionen im System. Der DSDT Differentiated Definition Block wird beim Systemboot geladen und verbleibt im Speicher.
XSDT (Extended System Description Table)
Diese Tabelle enthält Verweise auf zusätzliche Beschreibungen der Konfiguration und der Systemimplementierung.
FADT (Fixed ACPI Description Table)
Diese Tabelle enthält statische, systembedingte Informationen zur Energieverwaltung, sowie Zeiger auf die Firmware ACPI Control Structure (FACS) und die Differentiated System Description Table (DSDT).
FACS (Firmware ACPI Control Structure)
Die FACS speichert die vom BIOS eingetragenen systemspezifischen Daten zum ACPI. Diese Daten sind die Grundlage für die Kommunikation von Betriebssystem und Firmware.
SBST (Smart Battery Table)
Eine ACPI-Tabelle, die von Plattformen mit Smart Battery Subsystemen benutzt wird. Die Tabelle definiert Energieversorgungsgrenzwerte, die das System veranlassen, in bestimmte Schlafzustände zu wechseln und den Benutzer darauf aufmerksam zu machen.

Vorlage:Lückenhaft

ECDT (Embedded Controller Boot Resources Table)
SRAT (System Resource Affinity Table)
Diese Tabelle wird von NUMA-fähigen Betriebssystemen ausgelesen, um lokalen Threads (Aktivitätsträger) auch lokalen Speicher zuweisen zu können. Die Speicherzugriffszeit wird somit minimiert, die Systemleistung steigt. Eine eventuelle „Node-Interleaving“-Funktion, welche in einigen AMD-Opteron-BIOS-Einstellungen zu finden sind, gehört bei NUMA-fähigen Betriebssystemen und geeigneten NUMA-fähigen Anwendungen abgeschaltet, SRAT selbstverständlich an.
SLIT (System Locality Distance Information Table)
Diese Tabelle gibt den Abstand der Knoten untereinander an. Das wird benötigt, um angeforderten Speicher auf dem nächsten (d. h. schnellsten) Knoten zu allozieren, falls der lokale Speicher zu klein ist.

Kritik

ACPI wird dafür kritisiert, besonders kompliziert zu sein. Für andere Betriebssysteme als Windows sei es schwer, in ordentlicher Weise zu implementieren. Intel arbeitet deshalb für den Einsatz in Mobilgeräten an einer Alternative namens Simple Firmware Interface (SFI), empfiehlt jedoch, wenn eine Hardware beides zur Verfügung stellt, stets ACPI zu verwenden.

Wegen Fehlern in der ACPI-Implementierung vieler Hardwarekomponenten muss das Betriebssystem dieses undokumentierte Verhalten mit verschiedenen Methoden korrigieren. Das Betriebssystem Linux gibt sich dem BIOS gegenüber als Windows aus, um den besser getesteten Windows-Modus zu erhalten.

Es gibt einen „ACPI-Machine-Language“-Compiler von Intel und einen von Microsoft. Die Hersteller bevorzugen die Microsoft-Implementierung, weil sie besser mit Windows zusammenarbeitet. Hardware-Defekte durch falsche Stromsparmaßnahmen wollen die Hersteller unbedingt vermeiden.

Bill Gates überlegte 1999, ob er ACPI so gestalten sollte, dass andere Betriebssysteme Probleme mit dessen Implementierung haben: Vorlage:Zitat




Beschreibung

# ACPI Warning: SystemIO range 0x0000000000000295-0x0000000000000296 conflicts with OpRegion 0x0000000000000290-0x0000000000000299 (\_GPE.HWM) (20210730/utaddress-204)
acpi_enforce_resources= [ACPI]
{ strict | lax | no }
Check for resource conflicts between native drivers
and ACPI OperationRegions (SystemIO and SystemMemory
only). IO ports and memory declared in ACPI might be
used by the ACPI subsystem in arbitrary AML code and
can interfere with legacy drivers.
strict (default): access to resources claimed by ACPI
is denied; legacy drivers trying to access reserved
resources will fail to bind to device using them.
lax: access to resources claimed by ACPI is allowed;
legacy drivers trying to access reserved resources
will bind successfully but a warning message is logged.
no: ACPI OperationRegions are not marked as reserved,
no further checks are performed.

Solution

acpi_enforce_resources=no


Anhang

Siehe auch

Dokumentation

Links

Projekt
Weblinks
  1. https://de.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface
  2. ACPI Component Architecture – Intel Corporation
  3. Tipps zur ACPI-Konfigurationc’t-Redaktion, Einführung
  4. ACPI unter FreeBSD
  5. ACPI Specification 6.5
  6. https://wiki.archlinux.org/title/ACPI_modules
  7. https://forums.gentoo.org/viewtopic-p-8690372.html?sid=2c553bfbe6a8ca643a5b108c9a503097