Es ist wichtig, Hardware effizient einzusetzen. Energie- und Ressourcenverwaltung ermöglicht es dem System auf verschiedene Ereignisse, beispielsweise einen unerwarteten Temperaturanstieg, reagieren zu können. Eine frühe Spezifikation für die Energieverwaltung war das Advanced Power Management (APM). APM steuert den Energieverbrauch eines Systems auf Basis der Systemaktivität. Ursprünglich konnten Stromverbrauch und Wärmeabgabe eines Systems nur schlecht von Betriebssystemen gesteuert werden. Die Hardware wurde vom BIOS gesteuert, was die Kontrolle der Energieverwaltung für den Anwender erschwerte. Das APM-BIOS wird von dem Hersteller des Systems zur Verfügung gestellt und ist auf die spezielle Hardware angepasst. Der APM-Treiber des Betriebssystems greift auf das APM Software Interface zu, das den Energieverbrauch regelt.
APM hat hauptsächlich vier Probleme. Erstens läuft die Energieverwaltung unabhängig vom Betriebssystem in einem herstellerspezifischen BIOS. Beispielsweise kann das APM-BIOS die Festplatten nach einer konfigurierbaren Zeit ohne die Zustimmung des Betriebssystems herunterfahren. Zweitens befindet sich die ganze APM-Logik im BIOS; das Betriebssystem hat gar keine APM-Komponenten. Bei Problemen mit dem APM-BIOS muss das Flash-ROM aktualisiert werden. Diese Prozedur ist gefährlich, da sie im Fehlerfall das System unbrauchbar machen kann. Zum Dritten ist APM eine Technik, die herstellerspezifisch ist und nicht koordiniert wird. Fehler im BIOS eines Herstellers werden nicht unbedingt im BIOS anderer Hersteller korrigiert. Das letzte Problem ist, dass im APM-BIOS nicht genügend Platz vorhanden ist, um eine durchdachte oder eine auf den Zweck der Maschine zugeschnittene Energieverwaltung zu implementieren.
Das Plug and Play BIOS (PNPBIOS) war in vielen Situationen ebenfalls unzureichend. Das PNPBIOS verwendet eine 16-Bit-Technik. Damit das Betriebssystem das PNPBIOS ansprechen kann, muss es in einer 16-Bit-Emulation laufen. FreeBSD stellt einen APM-Treiber zur Verfügung, welcher für Systeme benutzt werden sollte, die vor dem Jahr 2000 hergestellt wurden. Der Treiber wird in apm(4) beschrieben.
Der Nachfolger von APM ist das Advanced Configuration and Power Interface (ACPI). ACPI ist ein Standard verschiedener Hersteller, welcher die Verwaltung von Hardware und Energiesparfunktionen festlegt. Die ACPI-Funktionen, die mehr Kontrolle und Flexibilität bieten, können vom Betriebssystem gesteuert werden.
Dieser Abschnitt zeigt die Konfiguration von ACPI unter FreeBSD. Zudem werden einige Tipps zur Fehlersuche vorgestellt und wie Sie Problemberichte einreichen können, sodass Entwickler ACPI-Probleme erfassen und beheben können.
Der acpi(4)-Treiber wird standardmäßig beim
Systemstart vom loader(8) geladen und sollte daher
nicht fest in den Kernel eingebunden
werden. Der Treiber kann im laufenden Betrieb nicht entfernt
werden, da er zur Kommunikation mit der Hardware verwendet
wird. Falls jedoch Probleme auftreten, kann
ACPI auch komplett deaktiviert werden.
Dazu muss hint.acpi.0.disabled="1" in
/boot/loader.conf gesetzt und
anschließend das System neu gestartet werden. Alternativ
können Sie diese Variable auch am loader(8)-Prompt
eingeben, wie in Abschnitt 12.2.3, „Phase Drei“
beschrieben.
ACPI und APM können nicht zusammen verwendet werden. Das zuletzt geladene Modul beendet sich, sobald es bemerkt, dass das andere Modul geladen ist.
Mit acpiconf können Sie das System in
einen Ruhemodus (sleep mode)
versetzen. Es gibt verschiedene Modi
(von 1 bis 5), die Sie
auf der Kommandozeile mit -s angeben können.
Für die meisten Anwender sind die Modi 1
und 3 völlig ausreichend. Der Modus
5 schaltet das System
aus (Soft-off) und entspricht
dem Befehl halt -p.
Verschiedene Optionen können mit sysctl
gesetzt werden. Lesen Sie dazu acpi(4) sowie
acpiconf(8).
ACPI gibt es in allen modernen Rechnern der ia32- (x86) 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 Abhilfen oder Korrekturen. Die Liste ist nach der Häufigkeit, mit der die Probleme auftreten, sortiert. Wenn eine Korrektur das Problem nicht behebt, finden Sie in Abschnitt 11.13.4, „Abrufen und Einreichen von Informationen zur Fehlersuche“ Anweisungen, wie Sie einen Problembericht einreichen können.
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
/boot/loader.conf aufzunehmen.
ACPI kennt drei
Suspend-to-RAM-Zustände
(STR),
S1-S3 sowie einen
Suspend-to-Disk-Zustand (STD)
S4. STD 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. 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.
Benutzen Sie sysctl hw.acpi um die
Suspend-Zustände zu ermitteln. Diese Beispielausgabe stammt
von einem Thinkpad:
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, S4
und S5 eingestellt werden können.
Hätte s4bios den Wert
1, gäbe es den Zustand
S4BIOS anstelle
von S4.
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.
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, entladen Sie soviele
Treiber wie möglich. Wenn das funktioniert, laden Sie einen
Treiber nach dem anderen, bis der Fehler wieder auftritt.
Typischerweise verursachen binäre Treiber wie
nvidia.ko, 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
/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 die
Variable hw.acpi.reset_video auf
1. 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. Erfahrene Benutzer können versuchen, 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 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
/boot/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 26.6.4.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
hw.acpi.disable_on_poweroff="0" in
/boot/loader.conf. 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.
Einige BIOS-Hersteller liefern einen fehlerhaften Bytecode aus. Dies erkennen Sie an Kernelmeldungen wie diesen:
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 suchen.
Der BIOS-Bytecode, bekannt als ACPI Maschine Language (AML) wird aus der Sprache namens ACPI Source Language (ASL) übersetzt. Die AML ist in einer Tabelle, bekannt als Differentiated System Description Table (DSDT), abgelegt.
Es ist das Ziel von FreeBSD, dass
ACPI ohne Eingriffe des Benutzers
läuft. Zurzeit werden allerdings noch Abhilfen für Fehler
der BIOS-Hersteller entwickelt.
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. Die FreeBSD Entwickler
hoffen, dass sie das vom Standard abweichende Verhalten des
Microsoft®-Interpreters dokumentieren und in FreeBSD replizieren
können. Dadurch müssen Benutzer ihre
ASL nicht selbst reparieren.
Um bei der Fehlersuche zu helfen und das Problem
möglicherweise zu beheben, kann eine Kopie der
ASL gemacht werden. Dazu nutzen Sie
acpidump zusammen mit -t,
um den Inhalt der Tabelle anzuzeigen und -d,
um die AML zu zerlegen:
#acpidump -td >my.asl
Einige AMLs gehen davon aus, dass
der Anwender eine Windows®-Versionen benutzt. Versuchen
Sie das Betriebssystem, das Sie in der ASL
finden, in /boot/loader.conf anzugeben:
hw.acpi.osname=."Windows 2009"
Manche Abhilfen erfordern eine Anpassung von
my.asl. Wenn diese Datei bearbeitet
wird, erstellen Sie die neue ASL mit dem
folgenden Befehl. Warnung können meistens ignoriert werden,
aber Fehler verhindern die ordnungsgemäße Funktion von
ACPI.
#iasl -fmy.asl
Die Option -f erzwingt das Erstellen der
AML auch dann, wenn während der Übersetzung
Fehler auftreten. Einige Fehler, wie fehlende
Return-Anweisungen, werden automatisch vom FreeBSD Interpreter
umgangen.
Die voreingestellte Ausgabedatei von
iasl ist 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
DSDT.aml in
/boot befindet und starten Sie das
System neu. Wenn dadurch das Problem behoben wird, schicken
Sie einen diff(1) der alten und der neuen
ASL an freebsd-acpi, damit die
Entwickler das Problem in acpica
umgehen können.
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 „layer“
angegeben und in Komponenten
(ACPI_ALL_COMPONENTS) und
ACPI-Hardware
(ACPI_ALL_DRIVERS) aufgeteilt.
Welche Meldungen ausgegeben werden, wird über
„level“ gesteuert. Die Level reichen von von
ACPI_LV_ERROR (es werden nur Fehler
ausgegeben) bis zu ACPI_LV_VERBOSE (alles
wird ausgegeben). Das 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 sollte
die Ausgabe mithilfe einer seriellen Konsole gesichert werden.
Die möglichen Werte für „layers“ und
„level“ werden in 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
Kopieren Sie anschließend
acpi.ko ins Verzeichnis
/boot/kernel.
In /boot/loader.conf stellen Sie
„level“ und „layer“ ein. Das
folgende Beispiel aktiviert die Ausgabe von Fehlern für
alle ACPI-Komponenten und alle
Hardwaretreiber:
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 /boot/loader.conf
nicht editieren. Auf der Kommandozeile geben Sie über
sysctl dieselben Variablennamen wie in
/boot/loader.conf an.
Sobald Sie die Fehlerinformationen gesammelt haben, schicken Sie diese an freebsd-acpi, sodass die Betreuer des FreeBSD-ACPI-Subsystems diese Informationen zur Analyse und für die Entwicklung einer Lösung verwenden können.
Bevor Sie einen Fehlerbericht an diese Mailingliste einreichen, stellen Sie bitte sicher, dass das BIOS und die Firmware des Controllers aktuell sind.
Wenn Sie einen Fehlerbericht einsenden, fügen Sie bitte die folgenden Informationen ein:
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 nach der
Eingabe von boot -v.
Geben Sie auch alle Fehlermeldungen an, die erscheinen,
wenn Sie den Fehler provozieren.
Die Ausgabe von dmesg 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 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 für name
den Namen des Kontos und für
system den Hersteller und
das Modell des 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) 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. Es kann sein, dass der Fehler schon von jemand anderem gemeldet wurde.
Weitere Informationen über ACPI finden Sie hier:
Die FreeBSD ACPI Mailingliste
(https://lists.freebsd.org/pipermail/freebsd-acpi/)
Die ACPI 2.0 Spezifikation (http://acpi.info/spec.htm)
acpi(4), acpi_thermal(4), acpidump(8), iasl(8) und acpidb(8)
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>.