Das FreeBSD-Handbuch
Zurück Kapitel 11. Konfiguration und Tuning Weiter

11.16. ACPI-Fehlersuche

Verfasst von Nate Lawson. Mit Beiträgen von Peter Schultz und Tom Rhodes.

ACPI ist ein gänzlich neuer Weg, um Geräte aufzufinden und deren Stromverbrauch zu regulieren. Weiterhin bietet ACPI einen einheitlichen Zugriff auf Geräte, die vorher vom BIOS verwaltet wurden. Es werden zwar Fortschritte gemacht, dass ACPI auf allen Systemen läuft, doch tauchen immer wieder Fehler auf: fehlerhafter Bytecode der ACPI-Machine-Language (AML) einiger Systemplatinen, ein unvollständiges FreeBSD-Kernel-Subsystem oder Fehler im ACPI-CA-Interpreter von Intel®.

Dieser Abschnitt hilft Ihnen, zusammen mit den Betreuern des FreeBSD-ACPI-Subsystems, Fehlerquellen zu finden und Fehler zu beseitigen. Danke, dass Sie diesen Abschnitt lesen; hoffentlich hilft er, Ihre Systemprobleme zu lösen.

11.16.1. Fehlerberichte einreichen

Anmerkung: Bevor Sie einen Fehlerbericht einreichen, stellen Sie bitte sicher, dass Ihr BIOS und die Firmware Ihres Controllers aktuell sind.

Wenn Sie sofort einen Fehlerbericht einsenden wollen, schicken Sie bitte die folgenden Informationen an die Mailingliste freebsd-acpi:

Obwohl die meisten Entwickler die Mailingliste freebsd-current lesen, sollten Sie Fehlerberichte an die Liste freebsd-acpi schicken. Seien Sie bitte geduldig; wir haben alle Arbeit außerhalb des Projekts. Wenn der Fehler nicht offensichtlich ist, bitten wir Sie vielleicht, einen offiziellen Fehlerbericht (PR) mit send-pr(1) einzusenden. Geben Sie im Fehlerbericht bitte dieselben Informationen wie oben an. Mithilfe der PRs verfolgen und lösen wir Probleme. Senden Sie bitte keinen PR ein, ohne vorher den Fehlerbericht an die Liste freebsd-acpi zu senden. Wir benutzen die PRs als Erinnerung an bestehende Probleme und nicht zum Sammeln aller Probleme. Es kann sein, dass der Fehler schon von jemand anderem gemeldet wurde.

11.16.2. ACPI-Grundlagen

ACPI gibt es in allen modernen Rechnern der ia32- (x86), ia64- (Itanium) und amd64- (AMD) Architektur. Der vollständige Standard bietet Funktionen zur Steuerung und Verwaltung der CPU-Leistung, der Stromversorgung, von Wärmebereichen, Batterien, eingebetteten Controllern und Bussen. Auf den meisten Systemen wird nicht der vollständige Standard implementiert. Arbeitsplatzrechner besitzen meist nur Funktionen zur Verwaltung der Busse, während Notebooks Funktionen zur Temperaturkontrolle und Ruhezustände besitzen.

Ein ACPI konformes System besitzt verschiedene Komponenten. Die BIOS- und Chipsatz-Hersteller stellen mehrere statische Tabellen bereit (zum Beispiel die Fixed-ACPI-Description-Table, FADT). Die Tabellen enthalten beispielsweise die mit SMP-Systemen benutzte APIC-Map, Konfigurationsregister und einfache Konfigurationen. Zusätzlich gibt es die Differentiated-System-Description-Table (DSDT), die Bytecode enthält. Die Tabelle ordnet Geräte und Methoden in einem baumartigen Namensraum an.

Ein ACPI-Treiber muss die statischen Tabellen einlesen, einen Interpreter für den Bytecode bereitstellen und die Gerätetreiber im Kernel so modifizieren, dass sie mit dem ACPI-Subsystem kommunizieren. Für FreeBSD, Linux und NetBSD hat Intel den Interpreter ACPI-CA, zur Verfügung gestellt. Der Quelltext zu ACPI-CA befindet sich im Verzeichnis src/sys/contrib/dev/acpica. Die Schnittstelle von ACPI-CA zu FreeBSD befindet sich unter src/sys/dev/acpica/Osd. Treiber, die verschiedene ACPI-Geräte implementieren, befinden sich im Verzeichnis src/sys/dev/acpica.

11.16.3. Häufige Probleme

Damit ACPI richtig funktioniert, müssen alle Teile funktionieren. Im Folgenden finden Sie eine Liste mit Problemen und möglichen Umgehungen oder Fehlerbehebungen. Die Liste ist nach der Häufigkeit, mit der die Probleme auftreten, sortiert.

11.16.3.1. Mausprobleme

Es kann vorkommen, dass die Maus nicht mehr funktioniert, wenn Sie nach einem Suspend weiterarbeiten wollen. Ist dies bei Ihnen der Fall, reicht es meistens aus, den Eintrag hint.psm.0.flags="0x3000" in Ihre /boot/loader.conf aufzunehmen. Besteht das Problem weiterhin, sollten Sie einen Fehlerbericht an das FreeBSD Project senden.

11.16.3.2. Suspend/Resume

ACPI kennt drei Suspend-to-RAM-Zustände (STR): S1-S3. Es gibt einen Suspend-to-Disk-Zustand: S4. Der Zustand S5 wird Soft-Off genannt. In diesem Zustand befindet sich ein Rechner, wenn die Stromversorgung angeschlossen ist, der Rechner aber nicht hochgefahren ist. Der Zustand S4 kann auf zwei Arten implementiert werden: S4BIOS und S4OS. Im ersten Fall wird der Suspend-to-Disk-Zustand durch das BIOS hergestellt im zweiten Fall alleine durch das Betriebssystem.

Anmerkung: Die Suspend-Zustände sind Ruhezustände, in denen der Rechner weniger Energie als im Normalbetrieb benötigt. Resume bezeichnet die Rückkehr zum Normalbetrieb.

Die Suspend-Zustände können Sie mit dem Kommando sysctl hw.acpi ermitteln. Das Folgende könnte beispielsweise ausgegeben werden:

hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.s4bios: 0

Diese Ausgabe besagt, dass mit dem Befehl acpiconf -s die Zustände S3, S4OS und S5 eingestellt werden können. Hätte s4bios den Wert 1, gäbe es den Zustand S4BIOS anstelle von S4OS.

Wenn Sie die Suspend- und Resume-Funktionen testen, fangen Sie mit dem S1-Zustand an, wenn er angeboten wird. Dieser Zustand wird am ehesten funktionieren, da der Zustand wenig Treiber-Unterstützung benötigt. Der Zustand S2 ist ähnlich wie S1, allerdings hat ihn noch niemand implementiert. Als nächstes sollten Sie den Zustand S3 ausprobieren. Dies ist der tiefste STR-Schlafzustand. Dieser Zustand ist auf massive Treiber-Unterstützung angewiesen, um die Geräte wieder richtig zu initialisieren. Wenn Sie Probleme mit diesem Zustand haben, können Sie die Mailingliste freebsd-acpi anschreiben. Erwarten Sie allerdings nicht zu viel: Es gibt viele Treiber und Geräte, an denen noch gearbeitet und getestet wird.

Um das Problem einzugrenzen, entfernen Sie soviele Treiber wie möglich aus dem Kernel. Sie können das Problem isolieren, indem Sie einen Treiber nach dem anderen laden, bis der Fehler wieder auftritt. Typischerweise verursachen binäre Treiber wie nvidia.ko, X11-Grafiktreiber und USB-Treiber die meisten Fehler, hingegen laufen Ethernet-Treiber für gewöhnlich sehr zuverlässig. Wenn ein Treiber zuverlässig geladen und entfernt werden kann, können Sie den Vorgang automatisieren, indem Sie die entsprechenden Kommandos in die Dateien /etc/rc.suspend und /etc/rc.resume einfügen. In den Dateien finden Sie ein deaktiviertes Beispiel, das einen Treiber lädt und wieder entfernt. Ist die Bildschirmanzeige bei der Wiederaufnahme des Betriebs gestört, setzen Sie bitte die Variable hw.acpi.reset_video auf 0. Versuchen Sie auch, die Variable hw.acpi.sleep_delay auf kürzere Zeitspannen zu setzen.

Die Suspend- und Resume-Funktionen können Sie auch auf einer neuen Linux-Distribution mit ACPI testen. Wenn es mit Linux funktioniert, liegt das Problem wahrscheinlich bei einem FreeBSD-Treiber. Es hilft uns, das Problem zu lösen, wenn Sie feststellen können, welcher Treiber das Problem verursacht. Beachten Sie bitte, dass die ACPI-Entwickler normalerweise keine anderen Treiber pflegen (beispielsweise Sound- oder ATA-Treiber). Es ist wohl das beste, die Ergebnisse der Fehlersuche an die Mailingliste freebsd-current und den Entwickler des Treibers zu schicken. Wenn Ihnen danach ist, versuchen Sie, den Fehler in der Resume-Funktion zu finden, indem Sie einige printf(3)-Anweisungen in den Code des fehlerhaften Treibers einfügen.

Schließlich können Sie ACPI noch abschalten und stattdessen APM verwenden. Wenn die Suspend- und Resume-Funktionen mit APM funktionieren, sollten Sie vielleicht besser APM verwenden (insbesondere mit alter Hardware von vor dem Jahr 2000). Die Hersteller benötigten einige Zeit, um ACPI korrekt zu implementieren, daher gibt es mit älterer Hardware oft ACPI-Probleme.

11.16.3.3. Temporäre oder permanente Systemhänger

Die meisten Systemhänger entstehen durch verlorene Interrupts oder einen Interrupt-Sturm. Probleme werden verursacht durch die Art, in der das BIOS Interrupts vor dem Systemstart konfiguriert, durch eine fehlerhafte APIC-Tabelle und durch die Zustellung des System-Control-Interrupts (SCI).

Anhand der Ausgabe des Befehls vmstat -i können Sie verlorene Interrupts von einem Interrupt-Sturm unterscheiden. Untersuchen Sie die Ausgabezeile, die acpi0 enthält. Ein Interrupt-Sturm liegt vor, wenn der Zähler öfter als ein paar Mal pro Sekunde hochgezählt wird. Wenn sich das System aufgehangen hat, versuchen Sie mit der Tastenkombination Ctrl+Alt+Esc in den Debugger DDB zu gelangen. Geben Sie dort den Befehl show interrupts ein.

Wenn Sie Interrupt-Probleme haben, ist es vorerst wohl am besten, APIC zu deaktivieren. Tragen Sie dazu die Zeile hint.apic.0.disabled="1" in loader.conf ein.

11.16.3.4. Abstürze (Panics)

Panics werden so schnell wie möglich behoben; mit ACPI kommt es aber selten dazu. Zuerst sollten Sie die Panic reproduzieren und dann versuchen einen backtrace (eine Rückverfolgung der Funktionsaufrufe) zu erstellen. Richten Sie dazu den DDB über die serielle Schnittstelle (siehe Abschnitt 20.6.5.3) oder eine gesonderte dump(8)-Partition ein. In DDB können Sie den backtrace mit dem Kommando tr erstellen. Falls Sie den backtrace vom Bildschirm abschreiben müssen, schreiben Sie bitte mindestens die fünf ersten und die fünf letzten Zeile der Ausgabe auf.

Versuchen Sie anschließend, das Problem durch einen Neustart ohne ACPI zu beseitigen. Wenn das funktioniert hat, können Sie versuchen, das verantwortliche ACPI-Subsystem durch Setzen der Variablen debug.acpi.disable herauszufinden. Die Hilfeseite acpi(4) enthält dazu einige Beispiele.

11.16.3.5. Nach einem Suspend oder einem Stopp startet das System wieder

Setzen Sie zuerst in loader.conf(5) die Variable hw.acpi.disable_on_poweroff auf 0. Damit wird verhindert, dass ACPI während des Systemabschlusses die Bearbeitung verschiedener Ereignisse deaktiviert. Auf manchen Systemen muss die Variable den Wert 1 besitzen (die Voreinstellung). Normalerweise wird der unerwünschte Neustart des Systems durch Setzen dieser Variablen behoben.

11.16.3.6. Andere Probleme

Wenn Sie weitere Probleme mit ACPI haben (Umgang mit einer Docking-Station, nicht erkannte Geräte), schicken Sie bitte eine Beschreibung an die Mailingliste. Allerdings kann es sein, dass einige Probleme von noch unvollständigen Teilen des ACPI-Subsystems abhängen und es etwas dauern kann bis diese Teile fertig sind. Seien Sie geduldig und rechnen Sie damit, dass wir Ihnen Fehlerbehebungen zum Testen senden.

11.16.4. ASL, acpidump und IASL

Ein häufiges Problem ist fehlerhafter Bytecode des BIOS-Herstellers. Dies erkennen Sie an Kernelmeldungen auf der Konsole wie die folgende:

ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\
(Node 0xc3f6d160), AE_NOT_FOUND

Oft können Sie das Problem dadurch lösen, dass Sie eine aktuelle BIOS-Version einspielen. Die meisten Meldungen auf der Konsole sind harmlos, wenn aber beispielsweise der Batteriestatus falsch angezeigt wird, können Sie in den Meldungen nach Problemen mit der AML-Machine-Language (AML) suchen. Der Bytecode der AML wird aus der ACPI-Source-Language (ASL) übersetzt und in einer Tabelle, der DSDT, abgelegt. Eine Kopie der ASL können Sie mit dem Befehl acpidump(8) erstellen. Verwenden Sie mit diesem Befehl sowohl die Option -t (die Inhalte der statischen Tabellen anzeigen) als auch die Option -d (die AML in ASL zurückübersetzen). Ein Beispiel für die Syntax finden Sie im Abschnitt Fehlerberichte einreichen.

Sie können einfach prüfen, ob sich die ASL übersetzen lässt. Für gewöhnlich können Sie Warnungen während des Übersetzens ignorieren. Fehlermeldungen führen normal dazu, dass ACPI fehlerhaft arbeitet. Ihre ASL übersetzen Sie mit dem nachstehenden Kommando:

# iasl ihre.asl

11.16.5. Die ASL reparieren

Auf lange Sicht ist es unser Ziel, dass ACPI ohne Eingriffe des Benutzers läuft. Zurzeit entwickeln wir allerdings noch Umgehungen für Fehler der BIOS-Hersteller. Der Microsoft®-Interpreter (acpi.sys und acpiec.sys) prüft die ASL nicht streng gegen den Standard. Daher reparieren BIOS-Hersteller, die ACPI nur unter Windows® testen, ihre ASL nicht. Wir hoffen, dass wir das vom Standard abweichende Verhalten des Microsoft-Interpreters dokumentieren und in FreeBSD replizieren können. Dadurch müssen Benutzer ihre ASL nicht selbst reparieren. Sie können Ihre ASL selbst reparieren, wenn Sie ein Problem umgehen und uns helfen möchten. Senden Sie uns bitte die mit diff(1) erstellte Differenz zwischen alter und neuer ASL. Wir werden versuchen, den Interpreter ACPI-CA zu korrigieren, damit die Fehlerbehebung nicht mehr erforderlich ist.

Die nachfolgende Liste enthält häufige Fehlermeldungen, deren Ursache und eine Beschreibung, wie die Fehler korrigiert werden:

11.16.5.1. Abhängigkeiten vom Betriebssystem

Einige AMLs gehen davon aus, dass die Welt ausschließlich aus verschiedenen Windows-Versionen besteht. FreeBSD kann vorgeben, irgendein Betriebssystem zu sein. Versuchen Sie das Betriebssystem, das Sie in der ASL finden, in der Datei /boot/loader.conf anzugeben: hw.acpi.osname="Windows 2001".

11.16.5.2. Fehlende Return-Anweisungen

Einige Methoden verzichten auf die vom Standard vorgeschriebene Rückgabe eines Wertes. Obwohl der Interpreter ACPI-CA dies nicht beheben kann, besitzt FreeBSD die Möglichkeit, den Rückgabewert implizit zu setzen. Wenn Sie wissen, welcher Wert zurückgegeben werden muss, können Sie die fehlenden Return-Anweisungen selbst einsetzen. Die Option -f zwingt iasl, die ASL zu übersetzen.

11.16.5.3. Überschreiben der vorgegebenen AML

Nachdem Sie Ihre ASL in der Datei ihre.asl angepasst haben, übersetzen Sie die ASL wie folgt:

# iasl ihre.asl

Mit der Option -f erzwingen Sie das Erstellen der AML auch wenn während der Übersetzung Fehler auftreten. Beachten Sie, dass einige Fehler, wie fehlende Return-Anweisungen, automatisch vom Interpreter umgangen werden.

In der Voreinstellung erstellt der Befehl iasl die Ausgabedatei DSDT.aml. Wenn Sie diese Datei anstelle der fehlerhaften Kopie des BIOS laden wollen, editieren Sie /boot/loader.conf wie folgt:

acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/DSDT.aml"

Stellen Sie bitte sicher, dass sich die Datei DSDT.aml im Verzeichnis /boot befindet.

11.16.6. ACPI-Meldungen zur Fehlersuche erzeugen

Der ACPI-Treiber besitzt flexible Möglichkeiten zur Fehlersuche. Sie können sowohl die zu untersuchenden Subsysteme als auch die zu erzeugenden Ausgaben festlegen. Die zu untersuchenden Subsysteme werden als so genannte “layers” angegeben. Die Subsysteme sind in ACPI-CA-Komponenten (ACPI_ALL_COMPONENTS) und ACPI-Hardware (ACPI_ALL_DRIVERS) aufgeteilt. Welche Meldungen ausgegeben werden, wird über “level” gesteuert. “level” reicht von ACPI_LV_ERROR (es werden nur Fehler ausgegeben) bis zu ACPI_LV_VERBOSE (alles wird ausgegeben). “level” ist eine Bitmaske, sodass verschiedene Stufen auf einmal (durch Leerzeichen getrennt) angegeben werden können. Die erzeugte Ausgabemenge passt vielleicht nicht in den Konsolenpuffer. In diesem Fall sollten Sie die Ausgaben mithilfe einer seriellen Konsole sichern. Die möglichen Werte für “layers” und “level” werden in der Hilfeseite acpi(4) beschrieben.

Die Ausgaben zur Fehlersuche sind in der Voreinstellung nicht aktiviert. Wenn ACPI im Kernel enthalten ist, fügen Sie options ACPI_DEBUG zur Kernelkonfigurationsdatei hinzu. Sie können die Ausgaben zur Fehlersuche global aktivieren, indem Sie in der Datei /etc/make.conf die Zeile ACPI_DEBUG=1 einfügen. Das Modul acpi.ko können Sie wie folgt neu übersetzen:

# cd /sys/modules/acpi/acpi
&& make clean &&
make ACPI_DEBUG=1

Installieren Sie anschließend acpi.ko im Verzeichnis /boot/kernel. In der Datei loader.conf stellen Sie “level” und “layer” ein. Das folgende Beispiel aktiviert die Ausgabe von Fehlern für alle ACPI-CA-Komponenten und alle ACPI-Hardwaretreiber (wie CPU, LID):

debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
debug.acpi.level="ACPI_LV_ERROR"

Wenn ein Problem durch ein bestimmtes Ereignis, beispielsweise den Start nach einem Ruhezustand, hervorgerufen wird, können Sie die Einstellungen für “level” und “layer” auch mit dem Kommando sysctl vornehmen. In diesem Fall müssen Sie die Datei loader.conf nicht editieren. Auf der sysctl-Kommandozeile geben Sie dieselben Variablennamen wie in loader.conf an.

11.16.7. ACPI-Informationsquellen

Weitere Informationen zu ACPI erhalten Sie an den folgenden Stellen:

Zurück Zum Anfang Weiter
Energie- und Ressourcenverwaltung Nach oben FreeBSDs Bootvorgang

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.