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.
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:
Beschreiben Sie den Fehler und alle Umstände, unter denen der Fehler auftritt. Geben Sie ebenfalls den Typ und das Modell Ihres Systems an. Wenn Sie einen neuen Fehler entdeckt haben, versuchen Sie möglichst genau zu beschreiben, wann der Fehler das erste Mal aufgetreten ist.
Die Ausgabe von dmesg(8) nach der Eingabe
von boot -v
.
Geben Sie auch alle Fehlermeldungen an, die erscheinen,
wenn Sie den Fehler provozieren.
Die Ausgabe von dmesg(8) nach der Eingabe
von boot -v
und mit deaktiviertem
ACPI, wenn das Problem ohne
ACPI nicht auftritt.
Die Ausgabe von sysctl hw.acpi
.
Dieses Kommando zeigt die vom System unterstützten
ACPI-Funktionen an.
Die URL, unter der die ACPI-Source-Language (ASL) liegt. Schicken Sie bitte nicht die ASL an die Mailingliste, da die ASL sehr groß sein kann. Eine Kopie der ASL erstellen Sie mit dem nachstehenden Befehl:
#
acpidump -td > name
-system
.asl
Setzen Sie bitte für name
den Namen Ihres Kontos und für
system
den Hersteller und
das Modell Ihres Systems ein. Zum Beispiel:
njl-FooCo6000.asl
.
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.
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
.
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.
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.
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:
S4
BIOS und
S4
OS.
Im ersten Fall wird der Suspend-to-Disk-Zustand durch
das BIOS hergestellt im zweiten
Fall alleine durch das Betriebssystem.
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:
Diese Ausgabe besagt, dass mit dem Befehl
acpiconf -s
die Zustände
S3
, S4
OS
und S5
eingestellt werden können.
Hätte s4bios
den Wert
1
, gäbe es den Zustand
S4
BIOS anstelle
von S4
OS.
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.
Ein häufiges Problem mit Suspend/Resume ist, dass viele Gerätetreiber ihre Firmware, Register und Gerätespeicher nicht korrekt speichern, wiederherstellen und/oder reinitialisieren. Um dieses Problem zu lösen, sollten Sie zuerst die folgenden Befehle ausführen:
#
sysctl debug.bootverbose=1
#
sysctl debug.acpi.suspend_bounce=1
#
acpiconf -s 3
Dieser Test emuliert einen Suspend/Resume-Zyklus für
alle Geräte (ohne dass diese dabei wirklich in den Status
S3
wechseln). In vielen Fällen
reicht dies bereits aus, um Probleme (beispielsweise
verlorener Firmware-Status, Timeouts, hängende Geräte)
zu entdecken. Beachten Sie dabei, dass das Gerät bei
diesem Test nicht wirklich in den Status
S3
wechseln. Es kann also vorkommen, dass
manche Geräte weiterhin mit Strom versorgt werden (dies
wäre bei einem wirklichen Wechsel in den Status
S3
NICHT möglich.
Andere Geräte werden normal weiterarbeiten, weil sie
über keine Suspend/Resume-Funktionen verfügen.
Schwierigere Fälle können den Einsatz zusätzlicher Hardware (beispielsweise serielle Ports/Kabel für die Verbindung über eine serielle Konsole oder Firewire-Ports/Kabel für dcons(4)) sowie Kenntnisse im Bereich Kerneldebugging erforderlich machen.
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.
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.
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 27.6.5.3, „DDB Debugger über die serielle Schnittstelle“) 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.
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.
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.
Ein häufiges Problem ist fehlerhafter Bytecode des BIOS-Herstellers. Dies erkennen Sie an Kernelmeldungen auf der Konsole wie die folgende:
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
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:
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"
.
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.
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:
Stellen Sie bitte sicher, dass sich die Datei
DSDT.aml
im Verzeichnis
/boot
befindet.
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):
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.
Weitere Informationen zu ACPI erhalten Sie an den folgenden Stellen:
die FreeBSD ACPI Mailingliste,
die Archive der ACPI-Mailingliste: http://lists.FreeBSD.org/pipermail/freebsd-acpi/,
die alten Archive der ACPI-Mailingliste: http://home.jp.FreeBSD.org/mail-list/acpi-jp/,
die ACPI-Spezifikation (Version 2.0): http://acpi.info/spec.htm,
in den nachstehenden FreeBSD-Hilfeseiten: acpi(4), acpi_thermal(4), acpidump(8), iasl(8) und acpidb(8),
DSDT debugging resource (als Beispiel wird Compaq erläutert, die Ressource ist aber dennoch nützlich).
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>.