Kernel-Log: Höherer Stromverbrauch durch BIOS-Bugs

Trends & News | Kernel-Log

Kernel seit 2.6.38 verbrauchen mehr Strom, weil sie in bestimmten Situationen die Stromspartechnik ASPM deaktivieren. Neue Stable- und Longterm-Kernel bringen Korrekturen; einer hängt aber auffällig hinterher.

Im April hatte die Webseite Phoronix darüber berichtet, einige Systeme würden mit den Linux-Versionen 2.6.35 und 2.6.38 mehr Leistung aufnehmen als mit den jeweiligen Vorgängern. In Test will Phoronix jetzt die Ursache für den mit 2.6.38 steigenden Stromverbrauch gefunden haben.

Schuld sei die in 2.6.38 integrierte Änderung "PCI: Disable ASPM if BIOS asks us to". Sie soll laut Commit-Kommentar Probleme bei Systemen beseitigen, bei denen das BIOS die PCI-Express-Stromspartechnik ASPM (Active State Power Management) bei manchen PCIe-Chips aktiviert, in seiner von Linux konsultierten FADT (Fixed ACPI Description Table) jedoch erklärt, die ASPM nicht zu unterstützen. Durch die Änderung beachtet der Kernel die Angabe in den ACPI-Tabellen und versucht die Stromspartechnik bei allen PCIe-Geräten zu deaktivieren, sofern es das BIOS denn erlaubt.

Offensichtlich gibt es jedoch viele Systeme, bei denen das BIOS über die FADT falsche Informationen zur ASPM-Unterstützung liefert. Bei vielen von ihnen sind ab Kernel 2.6.38 daher alle PCIe-Lanes zur Kommunikation mit PCIe-Chips dauerhaft voll aktiv, was zu der höheren Leistungsaufnahme führt, die Phoronix und eine Reihe von Anwendern beobachteten. Über den Kernel-Parameter "pcie_aspm=force" kann man den Kernel anweisen, ASPM zwangsweise zu aktivieren. Das kann aber zu Systemabstürzen führen, wie etwa Red Hat in der RHEL-6-Dokumentation erläutert. Auf einem Thinkpad-Notebook von Phoronix sank die Leistungsaufnahme durch das Einschalten von ASPM von 24,8 auf 21,6 Watt und damit auf das Niveau beim Betrieb mit Kernel 2.6.37.

Windows scheint solche Situationen anders zu handhaben – es ist unklar, ob es anderswo nach Informationen zur ASPM-Unterstützung schaut oder ASPM einfach nutzt, sofern das BIOS die Kontrolle freigibt. Letztendlich deutet vieles auf eine Problematik hin, die den Reboot- und UEFI-Problemen von Linux ähnelt, denen jüngst etwas Aufmerksamkeit zugekommen ist (1, 2): Linux spricht die Hardware anders an als Windows, wodurch Linux ungetestete Pfade betritt und Probleme auftreten, weil die Hardware-Hersteller meist nur mit Windows getestet haben. Da hilft es auch nichts, das Linux die Dinge teilweise sogar korrekter angeht als Windows: Recht spezifikationskonformes Arbeiten gepaart mit unsauberen ACPI-Tabellen in den Notebook-BIOSen war schon eine der Ursachen für viele der ACPI-Probleme, die Linux-Anwender vor Jahren häufig plagten. Besser wurde es, seit sich der ACPI-Interpreter von Linux mehr wie der von Windows verhält und auch die selben Fehler macht ("Bug compatibility").

Wie die Kernel-Hacker das Problem angehen, dürften die nächsten Tage und Wochen zeigen; vermutlich wird frühestens Linux 3.1 eine Korrektur enthalten, damit ASPM wieder bei mehr Systemen aktiv ist. Phoronix ist zudem noch auf der Suche nach der Änderung, die ab Linux-Kernel 2.6.35 zu einer höheren Leistungsaufnahme führt.

Greg Kroah-Hartman hat den Stable-Kernel 2.6.39.2 sowie die Longterm-Kernel 2.6.32.42 und 2.6.33.15 veröffentlicht. Die Freigabe-Mails zu den beiden erstgenannten Versionen enthalten den üblichen Hinweis, der nachdrücklich zum Update auffordert, ohne klar zustellen, ob auch Sicherheitslücken beseitigt wurden.

Paul Gortmaker hat wenig später den Longterm-Kernel 2.6.34.10 freigegeben, der über 240 Änderungen bringt. Anders als Greg Kroah-Hartman erwähnt er in der Freigabe-Mail die Korrektur von Sicherheitslücken. Zwischen 2.6.34.9 und 2.6.34.10 vergingen aber über zehn Wochen, in denen Kroah-Hartman vier neue Longterm-Kernel der 32er-Serie veröffentlicht hat. Es ist recht wahrscheinlich, dass diese 32er-Versionen bereits einige Sicherheitslücken korrigiert haben, die in der 34er-Serie erst jetzt beseitigt wurden.

Forum zum Thema

Kommentare

Kommentare lesen (53 Beiträge)

Anzeige