Für die Lebensdauer des Laptop-Akkus ist es beispielsweise nicht sonderlich ideal, wenn das Gerät am Schreibtisch meistens am Strom hängt und das Netzteil die Batterie immer auf 100 Prozent hält. Ideal wäre es, den Akku im Netzbetrieb abzuklemmen und das Gerät nur noch über das Netzteil mit Strom zu versorgen — der Akku würde sich dabei nur sehr langsam entladen. Ebenso wichtig wäre es, den Akku nicht immer auf die vollen 100 Prozent Kapazität aufzuladen. Für die Lebensdauer des Akkus ideal wäre ein Pendeln zwischen 20 und 80 Prozent. Das wissen auch die Hersteller, doch unter Linux gibt es oft keinen Dienst, der sich um das optimale Ladeverhalten kümmert. Nur wenige Hersteller wie etwa TUXEDO mit seinem FlexiCharger haben uns Linux-User im Blick.

Battery Health Charging für GNOME

Die Erweiterung installiert ihr per Mausklick über das GNOME Extensions Portal. Anschließend müsst ihr die Einstellungen der Erweiterung öffnen (etwa über das Zahnrad-Icon neben dem Titel im GNOME-Panel) und der Erweiterung unter Installieren via PolicyKit administrative Rechte geben. Zudem müssen die entsprechenden Kernelmodule oder Bibliotheken installiert sein — Details zu den unterstützten Geräten findet ihr auf der Projektseite. Auf meinen zwei Testgeräten, einem TUXEDO InfinityBook Pro 14 unter TUXEDO OS und einem DELL XPS 15 von 2018 unter Arch Linux, ist von Haus aus alles installiert. Das InfinityBook benötigt das tuxedo-keyboard-Kernelmodul, der Dell XPS die Bibliothek libsmbios.

Nicht verwirren lassen darf man sich bei der Anzeige des Ladezustands. Stellt der Rechner bei zum Beispiel 80 Prozent das Laden ein, dann verschwindet der Ladeblitz neben dem Akku-Symbol im Panel, obwohl das Gerät weiter am Strom hängt und der Akku auch nicht entladen wird — bis auf die in der Regel geringe Selbstentladung. Das Verhalten lässt sich in den Einstellungen der Erweiterung korrigieren. Es ist auch nicht ganz klar, ob das System den Ladezustand sauber erkennt. Ist ein Akku bei einem Limit von 90 Prozent nun bei 90 oder 100 Prozent „voll“ geladen? Auch kommen sich die unterschiedlichen Tools ein wenig in die Quere: Setze ich auf dem Dell-Laptop via smbios-battery-ctl den Lademodus, dann bekommt die Erweiterung nichts davon mit, Ähnliches passiert auch beim TUXEDO Control Center. Nutzt man aber nur eines der Tools, dann kann man die Erweiterung wunderbar nutzen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Es ist also dringend an der Zeit, sich um das Gerät zu kümmern: Mit einem neuen Lüfter ist endlich wieder Ruhe im Karton. Ein neuer Akku sorgt wieder für 2 Stunden Strom und mit den richtigen Settings hält der Akku sogar knapp an die 3:30 Stunden. Es lohnt sich also, ein wenig Zeit in Intels Stromspar-Analyse-Tool Powertop zu investieren. Dabei müsst ihr nicht gleich den Akku tauschen, auch Nutzer eines neuen Laptops profitieren von den durch Powertop empfohlenen Stromsparmaßnahmen.

Generell möchte ich hier jetzt keine große Umbauanleitung geben, da ihr speziell beim Dell Vostro vor keinen großen Problemen steht. Neue zum Vostro V130 kompatible Lüfter gibt es bei Ebay für weniger als 17 Euro und auch neue Akkus kosten nur knapp um die 50 Euro. Für wenig mehr als 65 Euro lässt sich das Notebook somit fast komplett generalüberholen. Bei meinen Bestellungen kam der Lüfter per Luftpost direkt aus China — ohne dass der Zoll sich über die Sendung mokierte. Der Akku wurde dagegen direkt aus Deutschland ausgeliefert.

Neuer Lüfter und Akku

Der Aufwand beim Umbau hält sich beim Vostro V130 in Grenzen: Mit einem konventionellen kleinen Phillips-Schraubendreher aka Kreuzschlitzschraubenzieher lassen sich sämtliche Schrauben auf der Rückseite und die zwei auf der schwarzen Hinterseite herausdrehen. Danach gilt es nur noch die Blende für den SD-Kartenslot rauszunehmen und den Rückendeckel zur Vorderseite hin abzuziehen. Lüfter und Akku lassen sich dann ebenso problemlos austauschen wie das Gerät öffnen, es müssen wieder nur ein paar simple Schrauben gelöst werden.

Direkt nach dem Umbau läuft der Lüfter wieder seidenweich und auch die Akkulaufzeit kann sich mit 2 Stunden wieder sehen lassen. Allerdings sind diese zwei Stunden beileibe nicht das Ende der Fahnenstange. Mit den richtigen Werkzeugen kitzelt ihr locker 50 Prozent mehr Laufzeit aus eurem Linux-Laptop, ohne dass ihr dabei allzu viel Aufwand treiben oder auf Komfort verzichten müsst. Die Akkulaufzeit meines frisch renovierten Dell Vostro V130 ließ sich von den besagten 2 Stunden auf knapp 3:15 Stunden steigern — es lohnt sich also, ein wenig in die Thematik einzusteigen.

Akkulaufzeit mit Powertop optimieren

Die 2 Stunden Akkulaufzeit sind im Gegensatz zu den anfänglichen 20 bis 30 Minuten zwar toll, doch nach wie vor nicht wirklich überragend. Von dem integrierten 30 Wh/2700 mAh großen Akku kann man zwar keine Wunder erwarten, doch Dell spricht von über 4 Stunden Laufzeit und der Test bei Notebookcheck berichtet von einer Laufzeit von etwa 2:30 beim Surfen über WLAN beziehungsweise knapp 4:30 im Leerlauf bei geringster Bildschirmhelligkeit. Von daher ist es an der Zeit, sich auch etwas mit dem Optimieren der Akkulaufzeit zu beschäftigen.

Dabei hilft euch das von Intel entwickelte Analysewerkzeug Powertop. Es reduziert selber nicht den Stromverbrauch, stattdessen analysiert Powertop das System bis ins letzte Detail und verrät die größten Stromschlucker abseits des Displays und anderer essentieller Funktionen. Doch damit nicht genug: Powertop spuckt gleich die passenden Kommandos aus, mit denen sich die hungrige Hardware ohne große Einbußen an Komfort und Leistung bändigen lässt. Mit ein bisschen Geduld lässt sich so die Akkulaufzeit des Laptops daher unter Linux wesentlich verbessern.

HINWEIS: Als Arch-User habe ich die Aktion natürlich mit Arch Linux durchgeführt. Selbstverständlich funktioniert das Tutorial aber auch mit anderen Linux-Distributionen wie Debian oder Ubuntu — der größte Unterschied liegt in der Installation der Pakete und der Ausführung des Powertop-Skripts während des Bootvorgangs. Für User mit den erwähnten Distributionen gibt es im Ubuntuusers-Wiki auch eine tolle Anleitung. Ich für meinen Teil konzentriere mich hier an dieser Stelle auf Arch Linux und lasse auch mal Beispiele für Ubuntu aus, da ich den Vorgang eben nur unter Arch getestet habe.

Powertop-Tipps unter Arch Linux umsetzen

Im ersten Schritt müsst ihr Powertop mitsamt dem Ethtool und dem Gnome Power Manager installieren. Der Power Manager ist nicht unbedingt vonnöten, allerdings zeigt er den Verlauf des Ladezustands schön übersichtlich als Graph an und liefert zudem zahlreiche andere Informationen zum Stromverbrauch des Systems unter Linux. Braucht ihr kein optisches Feedback eurer Aktion oder setzt ihr auf eine andere Desktopumgebung als Gnome, dann lasst den Power Manager einfach weg und erspart euch so eventuell die Installation von zahlreichen Abhängigkeiten, die ihr sonst gar nicht braucht.

$ sudo pacman -S powertop ethtool
$ sudo pacman -S gnome-power-manager

Nun ruft ihr mit sudo powertop das Analysewerkzeug zum ersten Mal aus einem Terminal heraus auf. In der Übersicht seht ihr ganz oben die aktuelle Entladungsrate in Watt und die von Powertop geschätzte restliche Akkulaufzeit. Merkt euch besonders die aktuelle Entladungsrate, denn die gilt es zum Verlängern der Akkulaufzeit abzusenken. Wichtig ist auch die Anzahl der Aufwachvorgänge/Sekunde. Je öfter der Prozessor aus dem Tiefschlaf geholt wird, desto weniger Zeit verbringt er im Stromsparmodus. Beobachtet beide Ausgaben mal eine Weile und notiert euch die Werte, ihr zieht sie am Ende der Aktion zum Vergleich heran.

### Powertop im Terminal aufrufen und testen
$ sudo powertop
### Powertop-Report erstellen und im Browser öffnen
$ sudo powertop --html=powertop-report.html
$ xdg-open powertop-report.html

Um im Inhalt der Ausgabe zu scrollen, drückt ihr einfach auf die Pfeiltasten eurer Tastatur. Per Tabulator-Taste wechselt ihr von der Übersicht, zum Leerlauf-Status, der Frequenz- und Gerät-Statistik sowie zu den Abstimmbaren Optionen. Hier ist besonders der letzte Punkt Abstimmbare Optionen von Interesse. Die Tabelle zeigt rechts Systemeinstellungen, die sich auf den Stromverbrauch auswirken. Linksbündig sagt die Ausgabe „Gut“ oder „Schlecht“, ob der entsprechende Punkt bereits behoben ist. Wählt ihr mit den Pfeiltasten einen der schlechten Punkte an, könnt ihr oft mit [Eingabe] die entsprechende Konfiguration optimieren. Die linke Spalte sollte dabei von Schlecht auf Gut wechseln.

Diese Änderung ist nun aber nicht permanent, sodass es sich an dieser Stelle gar nicht lohnt, weiter manuell einen Eintrag nach dem anderen zu optimieren. Das ist aber auch gar nicht nötig, denn die Einstellungen lassen sich auch direkt im System vornehmen, sodass Powertop nichts mehr zu meckern hat. Erzeugt euch dazu wie im oberen Listing beschrieben einen Powertop-Report powertop-report.html und öffnet diesen im nächstbesten Browser. Auf der Powertop-Seite tippt ihr dann auf den Reiter Tuning. Er enthält gesammelt alle wichtigen Optionen, die Akkulaufzeit zu verlängern.

Die Befehle aus dem PowerTop-Report müsstet ihr nun eigentlich direkt übernehmen können. Doch auch das macht einiges an Arbeit. Mit ein bisschen Shell-Magie lassen sich die Aufrufe zu wenigen Kommandos kombinieren, die ihr dann in ein extra Powertop-Skript packt, das ihr am Ende dann beim Start des Systems ausführen lässt. Erstellt dazu mit einem beliebigen Texteditor und Root-Rechten die Datei /usr/local/sbin/powertop.sh und fügt den Inhalt aus folgendem Listing ein.

#!/bin/bash
for i in /sys/class/scsi_host/host[012345]/link_power_management_policy; do echo min_power >$i; done
echo '1500' > '/proc/sys/vm/dirty_writeback_centisecs';
echo '1' > '/sys/module/snd_hda_intel/parameters/power_save';
echo '0' > '/proc/sys/kernel/nmi_watchdog';

## Runtime PM for PCI Device
find /sys/bus/pci/devices/*/power -name control -exec echo auto >{} \;
for i in $(find /sys/devices/pci0000\:00/0* -maxdepth 3 -name control); do
    echo auto > $i;
done
find /sys/bus/pci/devices/*/power -name control -exec echo auto >{} \;
for i in $(find /sys/devices/pci0000\:ff/0* -maxdepth 3 -name control); do
    echo auto > $i;
done

Achtet bitte darauf, dass ihr das Skript mit sehr hoher Wahrscheinlichkeit noch an euer System anpassen müsst. Orientiert euch dabei an den Ausgaben des Powertop-Reports oder an den Tipps des Ubuntuusers-Wiki. Meist werdet ihr in der ersten Zeile die Anzahl der SCSI-Hosts korrigieren („[012345]“), eventuell den Powersave-Modus des Intel-HDA-Soundchips rausnehmen oder auch das Runtime Power Management anpassen müssen. Am Ende speichert ihr die Datei ab und beendet den Editor. Arbeitet ihr wie hier im Beispiel mit Nano, geschieht dies mit [Strg]+[O], [Eingabe] und [Strg]+[X]. Danach macht ihr das Skript noch mit chmod +x ausführbar, sonst fehlen Systemctl nachher die Rechte, das Skript beim Booten zu starten.

$ sudo nano /usr/local/sbin/powertop.sh
$ sudo chmod +x /usr/local/sbin/powertop.sh

Wie schon erwähnt, benutzt Arch Linux Systemd als Init-System. Dieses sorgt unter anderem dafür, dass beim Booten die wichtigsten Prozesse in der richtigen Reihenfolge gestartet werden — an dieser Stelle unterscheidet sich der Vorgang noch von vielen Distributionen, die noch nicht auf Systemd aufbauen. Auch Powertop können wir in dieses System einklinken. Erstellt dafür wieder mit einem Editor und Root-Rechten die Datei /etc/systemd/system/powertop.service und fügt den folgenden Inhalt ein. Diesen müsst ihr dieses Mal nicht anpassen. Die Datei sorgt dafür, dass Systemd das von euch erstellte Powertop-Skript beim Booten ausführen wird.

[Unit]
Description="PowerTop Tuning"
ConditionPathExists=/usr/local/sbin/powertop.sh

[Service]
Type=oneshot
RemainAfterExit=yes
KillMode=none
ExecStart=/usr/local/sbin/powertop.sh
ExecStop=exit

[Install]
WantedBy=multi-user.target

Nun könnt ihr eure Powertop-Optimierungen testen… ob ihr wirklich richtig steht, seht ihr, wenn das Licht angeht. Ruft dazu mit systemctl start den powertop.service auf, mit systemctl status prüft ihr danach den Erfolg der Aktion. Auch ein Blick auf sudo powertop lohnt sich. Dort sollte der Tab Abstimmbare Optionen deutlich weniger mit „Schlecht“ markierte Einträge aufführen. Bei mir bleibt eigentlich nur noch das AutoSuspend für die USB-Geräte und der Wake-On-LAN-Status des im Laptop verbauten Ethernet-Adapters zurück.

$ sudo systemctl start powertop.service
$ systemctl status powertop.service
● powertop.service - "PowerTop Tuning config"
Loaded: loaded (/etc/systemd/system/powertop.service; enabled; vendor preset: disabled)
Active: active (exited) since Di 2015-06-02 12:11:49 CEST; 10min ago
Process: 319 ExecStart=/usr/local/sbin/powertop.sh (code=exited, status=0/SUCCESS)
Main PID: 319 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/powertop.service

Jun 02 12:11:49 estrellita systemd[1]: Starting "PowerTop Tuning"...
Jun 02 12:11:49 estrellita systemd[1]: Started "PowerTop Tuning".
$ sudo powertop

AutoSuspend für USB-Geräte solltet ihr generell vermeiden, da sonst Mäuse und andere USB-Geräte immer wieder aussetzen und um Wake-On-LAN kümmern wir uns im nächsten Schritt getrennt vom Powertop-Skript. Ein Laptop hängt selten per Kabel-Ethernet im Netzwerk und muss auch noch seltener per Wake-on-LAN über das Netzwerk geweckt bzw. gebootet werden. Es macht daher Sinn, Wake-on-LAN zu deaktivieren, da die Funktion im Standby und Ruhezustand zusätzlichen Strom verbraucht. Unter Arch gibt es mehrere Wege, Wake-on-LAN zu steuern, der einfachste geht über eine simple Udev-Regel, die ihr in Form der Datei /etc/udev/rules.d/70-disable_wol.rules mit folgendem Inhalt anlegt.

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*", RUN+="/usr/bin/ethtool -s %k wol d"

Funktioniert alles wie gewünscht, dann aktiviert mittels systemctl enable den Powertop-Booteintrag powertop.service und startet euren Rechner anschließend noch einmal neu durch. Habt ihr sauber gearbeitet, dann sollte Powertop kaum mehr einen Task mit „Schlecht“ kennzeichnen. Perfekt läuft es, wenn wirklich nur noch AutoSuspend für eure USB-Geräte als Verbesserungspotential übrig bleibt — diesen Punkt würde ich allerdings wie schon beschrieben nicht korrigieren. Damit solltet ihr nun eurem Linux-Laptop eine deutlich verbesserte Akkulaufzeit verpasst haben.

$ sudo systemctl enable powertop.service
$ sudo reboot

Bei meinem Dell Vostro V130 geht die Entladungsrate im Leerlauf bei aktiviertem WLAN und gleicher Helligkeit des Displays auf 9.10 W bis 9.30 W zurück. Damit verlängert sich im selben Zug auch die Akkulaufzeit von knapp über 2 Stunden auf locker mehr als 3 Stunden — ohne dass ich dabei an Komfort verliere oder irgendwelche Hardware-Komponenten nicht mehr funktionieren. Würde ich WLAN und Bluetooth abschalten sowie die Helligkeit des Displays auf ein erträgliches Minimum reduzieren, wären locker 4 Stunden Akkulaufzeit drinnen. Mehr verspricht Dell für das Gerät auch nicht in den technischen Spezifikationen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Bei meinem Laptop braucht man gar nicht erst groß zu testen, man hört das Problem alle paar Minuten. Die Festplatte dreht runter und startet nach einem kurzen Päuschen sofort wieder durch. Man kann dies auch mit den Smartmontools gut nachvollziehen, installiert euch das entsprechende Paket und checkt dann im Abstand von ein paar Minuten mit smartctl den „Load_Cycle_Count“ eurer Platte, steigt dieser Zähler permanent an, dann solltet Ihr eingreifen (Anmerkung: Ich beziehe hier alle Befehle auf die erste Platte im System /dev/sda).

$ sudo apt-get install smartmontools
$ sudo smartctl -A /dev/sda | grep Load_Cycle_Count
I93 Load_Cycle_Count    [...]   15225

Der Grund für das Abschalten der Platte liegt im Powermanagement des Systems. Über APM wird die Platte zum Stromsparen in den Ruhezustand geschickt, über hdparm könnt Ihr die entsprechende Konfiguration im Akku- und Netzbetrieb auslesen. Schmeißt dazu wieder das Terminal an und führt die folgenden Befehle aus, in meinem Fall unterscheidet sich der Wert nicht, egal ob das Notebook am Netz hängt oder über den Akku mit Strom versorgt wird.

#### Im Akkubetrieb....
$ sudo hdparm -I /dev/sda |  grep level
Advanced power management level: 127

#### Im Netzbetrieb....
$ sudo hdparm -I /dev/sda |  grep level
Advanced power management level: 127

Im Netzbetrieb sollte das Abschalten der Platte eigentlich so lange wie möglich hinausgezögert werden, ein Wert von 254 wäre daher ideal, allerdings unterscheidet auf meinen System das Powermanagement der Platte nicht zwischen Akku- und Netzbetrieb. Um das permanent zu ändern öffnet Ihr die Konfigurationsdatei /etc/hdparm.conf in einem Texteditor und tragt dort an das Ende der Datei die entsprechenden Einstellungen ein, keine Angst, das ist nicht sonderlich schwer.

$ gksudo gedit /etc/hdparm.conf

Scrollt jetzt bis ans Ende des Editors und übernehmt die folgenden Zeilen, sie regeln für die /dev/sda das Stromsparverhalten. Solltet Ihr über einen Desktop-Ersatz-von-einem-Notebook mit mehreren Platten verfügen, dann müsst Ihr den Eintrag für die weiteren Platten wiederholen. Hattet Ihr vorhin im Akkubetrieb einen anderen Wert als 127, so ändert dies bitte für die Zeile „apm_battery“ entsprechend ab, ich persönlich würde nicht von den Systemvorgaben abweichen.

Speichert nun abschließend eure Änderungen ab und beendet den Editor. Weiter gibt es eigentlich nichts mehr zu tun, das „Schlimmste“ habt Ihr somit hinter euch. Bleibt nur zu hoffen, dass sich das Stromsparverhalten der Platten tatsächlich auch ändert, dies gilt es noch einmal kurz zu überprüfen.

/dev/sda {
        apm = 254            # Netzbetrieb
	apm_battery = 127    # Batteriebetrieb
	spindown_time = 0    # kein Anhalten des Spindelmotors
}

Die Änderungen werden sofort aktiv, wenn sich der Modus ändert. Zieht also einfach mal den Netzstecker und überprüft mit hdparm erneut, ob jetzt immer noch dieselben Werte für den „Advanced power management level“ ausgegeben werden. In meinem Fall sollten jetzt im Akku-Betrieb 127 und im Netz-Betrieb 254 ausgegeben werden.

#### Im Akkubetrieb....
$ sudo hdparm -I /dev/sda |  grep level
Advanced power management level: 127

#### Im Netzbetrieb....
$ sudo hdparm -I /dev/sda |  grep level
Advanced power management level: 254

In meinem Fall beruhigt die Änderung nicht nur das schlechte Gewissen die Platte vorzeitig zu schrotten, sondern auch die Ohren. Das permanente Hoch- und Runterdrehen der Platte ist gerade an einem ruhigen Arbeitsplatz mit der Zeit doch etwas nervend. Durch den Eintrag in die hdparm.conf ist eure Änderung permanent, auch ein Neustart des Systems ändert nichts mehr. Sollte euch diese Anpassung nicht mehr gefallen, dann löscht einfach die von euch eingetragenen Zeilen und schon ist wieder alles beim Alten.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Torben hat den Stromverbrauch seines mit einer SSD ausgestatteten Lenovo Z370 mit ein paar Skripten analysiert und aus den Daten ein paar beeindruckende Graphen gewonnen. Am besten haben sich bei ihm die Bootparameter pcie_aspm=force acpi=noirq i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 bewährt. Diese senkten auf seinem Z370 den Stromverbrauch deutlich ab und verlängerten so die Akkulaufzeit von etwa drei auf über fünf Stunden.

Das bisschen Arbeit lohnt sich daher also auf jeden Fall, die Graphen sprechen eigentlich für sich. Bislang hat sich auch noch niemand gemeldet, bei dem die Kernelparameter zu Problemen geführt haben, von daher gehe ich mal davon aus, dass die Parameter auch nicht zu Instabilitäten im System führen. Selber kann ich es leider nicht probieren, da ich keine Geräte mit dem passenden Chipsatz besitze.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Da das wohl zahlreiche Laptops von Acer über Asus und Dell bis hin zu MSI sowie „normale“ Mainboards und Kompakt-PCs betrifft, übernehme ich hier einmal die Lösung. Sie lässt sich auch auf andere Linux-Distributionen übertragen. In den Kommentaren des ursprünglichen Beitrags sieht man auch Nutzer von Fedora Core oder LMDE, die den Standby ihres Rechners fixen konnten. Das Skript ist sicherlich kein Allheilmittel für alle Laptops mit Problemen mit dem Energiemanagement, doch vielleicht hilft es euch ja.

Das Problem scheint mit den USB-Controllern zusammenzuhängen, sie werden wohl beim Herunterfahren nicht korrekt deaktiviert und behindern das Übergehen in den Standby/Suspend. Um das Problem nun anzugehen, legt man ein zusätzliches Skript für den PowerManager unter /etc/pm/sleep.d/ an…

$ gksudo gedit /etc/pm/sleep.d/20_custom-ehci_hcd

…und fügt den folgenden Inhalt ein. Ihr müsst in dem Skript nichts anpassen, Ihr könnt es eins zu eins übernehmen.

#!/bin/sh

TMPLIST_E=/tmp/ehci-dev-list
TMPLIST_X=/tmp/xhci-dev-list
E_DIR=/sys/bus/pci/drivers/ehci_hcd
X_DIR=/sys/bus/pci/drivers/xhci_hcd
E_BIND=$E_DIR""/bind
E_UNBIND=$E_DIR""/unbind
X_BIND=$X_DIR""/bind
X_UNBIND=$X_DIR""/unbind


#param1 = temp file, param2 = device dir, param3 = unbind 
unbindDev (){
#inspired by http://art.ubuntuforums.org/showpost.php?p=9744970&postcount=19    
  echo -n '' > $1
    for i in `ls $2 | egrep '[0-9a-z]+\:[0-9a-z]+\:.*$'`; do
      echo -n "$i" | tee $3
      echo "$i" >> $1
  done
}

#param1 = tem file, param2 = bind
bindDev(){
  [ -f $1 ] || return
  
  for i in `cat $1`; do
    echo -n "$i" | tee $2

  done
  rm $1
}

case "${1}" in
  hibernate|suspend)
    unbindDev $TMPLIST_E $E_DIR $E_UNBIND
    unbindDev $TMPLIST_X $X_DIR $X_UNBIND
        ;;
  resume|thaw)
    bindDev $TMPLIST_E $E_BIND
    bindDev $TMPLIST_X $X_BIND
        ;;
esac

Abschließend müsst Ihr nur noch die Rechte so abändern, dass das Skript ausgeführt werden kann…

$ sudo chmod +x /etc/pm/sleep.d/20_custom-ehci_hcd

…und dann zum Test das Notebook in den Standby schicken. Das Skript sollte sofort seine Wirkung zeigen und – hoffentlich – das Notebook nun endlich ordentlich in den Bereitschafts- bzw. Ruhezustandsmodus gehen. Sollte sich die Aktion als Nullnummer erweisen, so könnt Ihr das Skript wieder löschen…

$ sudo rm /etc/pm/sleep.d/20_custom-ehci_hcd

…und weiter auf die Suche nach einer Lösung gehen, das Skript wird euch dann leider nicht helfen. Anbei noch eine Liste mit Laptops, bei denen sich der Standby/Suspend mit dem Skript beheben lies. Sie ist bei weitem nicht vollständig und soll nur erste Anhaltspunkte liefern, ob sich das Skript bei euch positiv auswirken kann.

• Acer Aspire 5750-6690 unter Ubuntu Maverick 10.10
• Asus EEEPC 1000H unter Linux Mint 10 LXDE
• Asus B53F unter Ubuntu Natty 11.04 und Maverick 10.10
• Asus K52F unter Ubuntu Natty 11.04
• Asus K72JR
• Asus N53J unter Fedora Core 14 und N53SN unter Ubuntu Natty 11.04
• Asus N73JG unter Fedora Core 15 (Rawhide)
• Asus P31F unter Ubuntu Natty 11.04
• Asus U35JC und U36JC unter Ubuntu Natty 11.04
• Asus U50F unter Ubuntu Maverick 10.10
• Asus X53E-SX107V unter Ubuntu Natty 11.04
• Averatec 2200
• Dell E4300 unter Ubuntu Natty 11.04
• Dell E6400 unter Ubuntu Natty 11.04
• Dell Studio 1558
• HP EliteBook 8540p
• HP Envy 17 unter Ubuntu Maverick 10.10
• HP Compaq 6730b
• IBM T410s unter Ubuntu Natty 11.04
• Lenovo ThinkPad SL500 unter Ubuntu Maverick 10.10
• Lenovo 3000 Y410 unter Ubuntu Natty 11.04
• Sony Vaio VPC-F115FM und VPC-F13S1E
• Sony Vaio WGN-FW235J unter Ubuntu 11.04 (Nur Ruhezustand)
• Toshiba Satellite U500-1DV unter Ubuntu Maverick 10.10

Weitere Informationen lassen sich auch noch in einem Thread auf ubuntuforums.org finden, aus dem heraus dieser Workaround entstanden ist.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Im Endeffekt ist das Ganze relativ leicht umzusetzen. Erfahrenen Linux-Usern müsste ich nur die Schlagworte hdparm, die Option -S XX und die Konfigurationsdatei hdparm.conf nennen. Wer ausführliche Informationen möchte, der sollte einfach weiterlesen  Erstmal muss man dazu die Daten der Platte herausfinden, die man bei Nichtgebrauch abschalten möchte. Am einfachsten geht dies über die Laufwerksverwaltung von GNOME, die ihr über das Menü unter Einstellungen | System aufrufen könnt. Dort müsstet ihr einfach nur eure Platte raussuchen und euch das entsprechende Gerät /dev/sdXY merken.

In meinem Beispiel arbeite ich also mit der Platte /dev/sdc. Wahrscheinlich handelt es sich bei euch um ein anderes Gerät, von daher müsst ihr die folgenden Hinweise an eure Situation anpassen. Für KDEler gibt es alternativ sicherlich auch in der KDE SC ein entsprechendes Werkzeug, und wenn alle Stricke reißen, hilft auf jeden Fall ein sudo fdisk -l weiter.

Nun überprüft ihr am besten erst einmal, ob sich eure Platte überhaupt in den Leerlauf schicken lässt. Alle halbwegs aktuellen Platten und Controller sollten dazu eigentlich in der Lage sein, aber bevor ihr euch später wundert, warum das nicht funktioniert, solltet ihr erstmal einen kleinen Test machen. Ruft dazu hdparm mit der Option -C auf…

$ sudo hdparm -C /dev/sdc
/dev/sdc:
 drive state is:  active/idle

Man sieht, dass hdparm den Status korrekt abrufen konnte und die Platte läuft – man sollte dies auch an ihrem Betriebsgeräusch erkennen können. Nun könnt ihr die Platte einmal von Hand abschalten…

$ sudo hdparm -y /dev/sdc

…der Erfolg der Aktion sollte hörbar sein. Optional könnt ihr erneut mit der Option -C nachprüfen, ob die Platte auch wirklich in den Standby geschickt werden konnte.

$ sudo hdparm -C /dev/sdc
/dev/sdc:
drive state is:  standby

Sobald ihr wieder auf die Platte zugreift (bspw. über den Dateimanager), wird die Platte wieder automatisch anlaufen und ihre Daten preisgeben. Nun wäre es recht umständlich, die Platte immer von Hand abzuschalten. Besser wäre es, wenn sich die Platte nach einer gewissen Zeit ohne Zugriffe automatisch abstellen könnte.

Dazu gibt es die Option -S XX von hdparm. Über sie könnt ihr eine Zeitspanne definieren, ab der die Platte abgeschaltet wird. Der Zahlenwert hinter dem Schlüssel drückt nicht direkt die Zeit aus, sondern dient nur als Multiplikator. Ich zitiere einfach mal die man-Page…

Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some older drives may have very different interpretations of these values.

Ein Wert von bspw. 60 entspricht daher 60*5 Sekunden, also 300 Sekunden oder fünf Minuten. Zu kurz sollte man das Timeout nicht wählen, da zu häufiges Runter- und wieder Hochdrehen des Motors die Lebensdauer der Platte beeinträchtigen kann.

$ sudo hdparm -S 60 /dev/sdc

Damit das Ganze automatisch beim Start des Systems ausgeführt wird, solltet ihr diese Einstellung in der Konfigurationsdatei /etc/hdparm.conf speichern. Am besten arbeitet ihr in dem Fall mit UUIDs, sodass sich der Eintrag immer auf die gewünschte Platte bezieht, selbst wenn sich eure Plattenkonfiguration einmal ändern sollte. Bestimmt die UUID über bspw…

$ sudo blkid
[...]
/dev/sdb1: LABEL="data-intern" UUID="ff7f1cdd-431a-4e47-8b90-49737cec82b3" TYPE="ext4"
/dev/sdc1: LABEL="datengrab" UUID="4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe" TYPE="ext3"

…und fügt dann einfach euren gewünschten Eintrag an das Ende der hdparm.conf an…

$ sudo gedit /etc/hdparm.conf
[...]
/dev/disk/by-uuid/4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe {
	spindown_time = 60
}

…ab dem nächsten Neustart sollte die Einstellung automatisch aktiv sein und eure Platte bei Nichtgebrauch abgeschaltet werden. Abschließend noch der Hinweis, dass ihr beim Arbeiten mit hdparm wirklich euer Hirn einschalten müsst. Bei der „Schlaffunktion“ müsst ihr – wie bereits erwähnt – bedenken, dass zu häufiges Hochdrehen der Platte die Lebensdauer reduzieren kann. Setzt das Intervall daher auf keinen Fall zu kurz. [UPDATE 13.07.2012: Ich habe den Beitrag auf die aktuelle Syntax der hdparm.conf umgestellt, damit dürften einige Rückfragen aus den Kommentaren geklärt sein.]

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Dafür braucht Y5 Battery Saver kein ebenso stromfressendes GPS-Signal. Das Programm bestimmt über die Cell ID an welchem Sendemast das Telefon gerade eingebucht ist. Verbindet man sich zu einem WLAN, dann merkt sich Y5 Battery Saver diese Cell ID. In Zukunft wird dann das WLAN immer dann automatisch eingeschaltet, sobald das Telefon an diesem Sendemast eingebucht ist. Verlässt man das Empfangsgebiet des Sendemastes, dann wird das WLAN wieder wie von Geisterhand abgeschaltet.

Natürlich ist die Positionsbestimmung über die Cell ID nicht super genau, doch darum geht es ja gar nicht. Meist ist beispielsweise der Arbeitsplatz weit genug von Zuhause entfernt, so dass das WLAN spätestens nach ein paar hundert Metern auf dem Weg zum Arbeitsplatz, zur Uni oder wohin auch immer automatisch deaktiviert wird. Auf meinem alten Samsung Galaxy mit Android 1.5 funktioniert das Programm recht gut und zuverlässig. Und der erzielte Stromspareffekt kann sich durchaus sehen lassen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Nun baut Ubuntu jedoch seit Jaunty die dafür nötigen Kernel-Module fest in den Kernel ein. Dadurch ist es nicht mehr möglich nur das eine Kernel-Module zu patchen, es muss leider der gesamte Kernel neu kompiliert werden… Vor einigen Monaten habe ich bereits über eine Paketquelle mit einem „PHC-Kernel“ geschrieben, in der Hoffnung dass mit der Quelle die Kernel-Kompiliererei ein Ende hat, doch bislang war ich vom linux-phc Team etwas enttäuscht. Das PPA hat meiner Erinnerung nach, während der bisherigen Lebenszeit von Jaunty gerade mal ein Update erfahren.

Mit Ubuntu Karmic ändert sich das Vorgehen mal wieder etwas. Das PPA enthält nun einen Kernel, dem die SpeedStep-Module komplett fehlen, so kann man sich die Kernelmodule selber erzeugen…

PHC-Kernel installieren

Den Anfang macht die Installation des angepassten Kernels, man kann den Kernel sowie die nötigen Bibliotheken und Tools für das Kompilieren des Kernelmoduls via…

$ sudo add-apt-repository ppa:linux-phc/ppa
$ sudo apt-get install build-essential linux-generic-phc linux-headers-generic-phc

…herunterladen und installieren. Nach der Installation startet man am besten den Rechner neu. Beim Booten steht jetzt ein zusätzlicher Kernel, der mit -phc endet, zur Verfügung. Speed-Stepping sollte mit diesem Kernel erstmal nicht funktionieren, wundert Euch also nicht, wenn die CPU vorerst immer mit maximaler Taktrate läuft.

Kernelmodule erzeugen

Nun könnt Ihr euch aus dem Forum von linux-phc.org bereits gepatchte Kernelmodule herunterladen. Es gibt zwei Varianten, einmal phc-k8*.tar.gz für AMD X2, AMD Turion64 und AMD Turion X2 Prozessoren und einmal phc-intel*.tar.gz für Intel Mobile Centrino, Atom (N2xx) und Intel Core/Core2 CPUs. Ihr müsst das passende Kernelmodul wählen.

Ich habe hier ein Gerät mit einem alten Intel Centrino, daher führe ich das am Beispiel des gerade aktuellen Moduls phc-intel-0.3.2-8.tar.gz durch… Habt Ihr das Modul heruntergeladen, so müsst Ihr es entpacken und in das entstandene Verzeichnis wechseln…

$ tar -xzf phc-intel*
$ cd phc-intel*

Nun könnt ihr das Modul erzeugen, kompilieren und installieren. Dies könnt Ihr via…

$ make prepare
$ make
$ sudo make install
$ sudo modprobe phc-intel

…durchführen. Solltet ihr Schwierigkeiten dabei haben, so liefert die im Archiv enthaltene README Datei weitere Informationen. Den Erfolg könnt Ihr wieder via…

$ cat /sys/devices/system/cpu/cpu0/cpufreq/phc_controls
16:33 14:33 12:20 10:14 8:6 6:4 

…ausprobieren. Ist das Modul erfolgreich gebaut worden und habt Ihr es via modprobe geladen, dann zeigt die Ausgabe von cat etwas an, falls die Ausgabe nichts bringt, dann hakt es irgendwo. Damit das Kernelmodul von nun an automatisch geladen wird, steckt ihr es in die Datei /etc/modules. Öffnet dazu die Datei in einen Editor mit Root-Rechten…

$ sudo gedit /etc/modules

und fügt die Zeile…

phc-intel

…ein. Speichert die Datei abschließend. Ihr seid damit noch nicht fertig… Ihr müsst noch passende Spannungswerte ermitteln und die Einstellungen permanent in Eurem System verankern. Seit Jaunty hat sich das Vorgehen nicht verändert. Informationen dazu findet Ihr im älteren Artikel PPA für Jaunty mit gepatchtem Kernel zum Undervolten.

Governor ohne PolicyKit-Abfrage ändern

Abschließend noch ein kleiner Tipp, der mit dem Thema hier nicht direkt etwas zu tun hat. In den Kommentaren zu Ubuntu Karmic Koala 9.10 aus meiner Sicht hat Christoph Wickert Hinweise gegeben, wie man auch mit PolicyKit-1 von GNOME aus Karmic die Taktrate bzw. den Governor ohne Passwortabfrage ändern kann. Ich füge dazu alle Benutzer, die den Governor ändern können sollen, in die Gruppe „users“ ein…

$ sudo adduser $USER users

(Kleiner Hinweis: Ihr müsst euch einmal aus und wieder einloggen. Erst dann werden die Gruppenzugehörigkeiten neu eingelesen) Danach könnt Ihr via…

$ sudo gedit /var/lib/polkit-1/localauthority/50-local.d/gnome-cpufreq.pkla

…die nötige Konfigurationsdatei erstellen. Als Inhalt fügt Ihr…

[Allow users to set the CPU frequency]
Identity=unix-group:users
Action=org.gnome.cpufreqselector
ResultAny=no
ResultInactive=no
ResultActive=yes

…ein. Danach könnt Ihr die Taktrate ohne die Eingabe eines Passwortes ändern.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Dies soll über Ultraschall-Signale geschehen, die von einer Software generiert werden, über die Boxen des Computers abgespielt und von einem Mikrofon aufgenommen werden. Die Signale mit über 20kHz sollen vom menschlichen Ohr nicht wahrnehmbar sein. Für Windows gibt es fertige ausführbare Dateien des Sonar Power Managers, unter Linux muss man sich sonarPM selber kompilieren…

Den Quellcode könnt Ihr von der Homepage herunterladen und anschließend entpacken. In der README findet Ihr dann eigentlich alle nötigen Informationen um sonarPM zu installieren. Ich gebe Euch trotzdem alle Infos Schritt für Schritt, so könnt Ihr auch ohne große Basteleien sonarPM austesten…

$ tar -xzf SonarPM*.tar.gz
$ cd sonar_dist/

Um sonarPM nun kompilieren zu können, braucht ihr folgende Bibliotheken. So wie ich das sehe, müsste es diese Bibliotheken für alle Ubuntu-Versionen und Debian ab Lenny geben.

$ sudo apt-get install portaudio19-dev libxss-dev libwxgtk2.8-dev

Habt Ihr die Bibliotheken installiert, könnt Ihr Euch dran machen sonarPM zu kompilieren. Ihr könnt direkt make ausführen, ein configure-Skript wird nicht benutzt…

$ make sonar_gui
$ make sonar_tui

Da das Programm nicht in der Lage ist für seine Konfigurationsdateien im Home-Verzeichnis einen Ordner anzulegen, müsst Ihr das machen.

$ mkdir ~/.sonarPM

Nun seid Ihr fertig und könnt die GUI von sonarPM via…

$ ./sonar_gui

… starten. Bei diesem ersten Start müsst Ihr die passenden Audio-Geräte auswählen. Unter Ubuntu Karmic funktionierte PulseAudio recht gut. Das Mikrofon habe ich jedoch direkt ausgewählt.

Anschließend startet sonarPM und fängt an Signale auszugeben. Anfangs hört man noch deutlich Signale, die nach und nach verschwinden. Nach rund 30 Sekunden Kalibrierung blieb sonarPM für mein Hörempfinden (fast) lautlos.

Bei mir klappte das Abschalten des Bildschirmes, allerdings nicht wirklich zuverlässig. Manchmal ging der Bildschirm aus, obwohl ich noch vor dem Rechner saß. Manchmal bleibt er an, obwohl ich nicht am Rechner sitze. Eventuell liegt das am Mikrofon meiner Webcam, das leider einen etwas zu dumpfen Klang liefert. Vielleicht entstehen die leisen Klicks, die ich ab und zu höre, auch durch das schlechte Mikrofon. Auch scheinen die Boxen mancher Laptops zu limitiert zu sein. Oft können die Brüllwürfel billiger Laptops die nötigen 20kHz nicht liefern. sonarPM eignet sich daher eher zum Rumspielen und Ausprobieren, am besten ist sowieso der schnelle Griff zum Ein-/Aus Schalter des Monitors.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Dazu gibt es in GNOME das CPU Frequency Applet, das den Benutzer durch die Option „Powersave“ schnell dazu verleitet diese Einstellung im mobilen Betrieb zu verwenden. Öfters liest man Support-Anfragen in dieser Art…

Ich würde gerne mein Ubuntu 9.04, das auf einem Notebook läuft, so konfigurieren, dass es die CPU-Policy auf „Powersave“ stellt, wenn es per Akku betrieben wird und auf „OnDemand“ schaltet, wenn es an der Steckdose hängt.

Wie eingangs angesprochen ist die Taktrate der CPU nur ein kleines Zahnrad im Räderwerk des Energiemanagements einer CPU. Viel wichtiger sind die Schlafmodi der CPU, in die ein Prozessor jedoch nur fallen kann, wenn es nichts mehr zu tun gibt. Im Normalfall (d.h. „normaler“ Betrieb: Keine Spiele, keine andauernden Berechnungen) spart man mit „Powersave“ KEINE Energie. Auch wenn diese Option fälschlicherweise „Powersave“ heißt, der Akku geht damit eher schneller zur Neige.

Ich zitiere mal Making sure we do power management the right way von Matthew Garrett. Matthew ist ein Angestellter von Canonical und dort unter anderem für den Kernel zuständig.

Weitere Informationen und ein anschauliches Beispiel gibt Arjan van de Ven, der Kopf eines Teams bei Intel, das sich um Power Management und die Performance von Linux auf Intel Hardware kümmert.

Will heißen, je schneller die CPU wieder in Tiefschlaf fallen kann, desto mehr Energie wird sie sparen. Indem man sie nun zwingt immer mit niedrigster CPU-Rate zu laufen, verhindert man, dass sie möglichst schnell wieder einschlafen kann. Mit Powersave spart man nur dann Energie, wenn die CPU sowieso bei jeder Taktrate voll ausgelastet wäre (also bspw. bei 3D-Spielen oder Berechnungen). Im normalen Betrieb, egal ob Akku oder Netz, sollte man OnDemand benutzen, um Energie zu sparen.

Ich persönlich benutze Powersave um den Lärm, den der Lüfter meines Laptops macht, zu kontrollieren. Arbeitet man mit anderen in einer leisen Umgebung, so ist ein permanent hochdrehender Lüfter doch arg nervig. Weitere interessante Ideen bzgl. Energiesparen bei Computern im Allgemeinen und Laptops im Speziellen findet man auf thinkpad-wiki.org unter Linux Stromsparen und Vista Stromverbrauch senken.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.