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 noch beim TUXEDO Control Center. Nutzt man aber nur eines der Tools, dann kann man die Erweiterung wunderbar nutzen.

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 der Editor und übernehmt die folgenden Zeilen, sie regeln für die /dev/sda das Stromsparverhalten. Solltet Ihr 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 abchließ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 die 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 nach, ob jetzt immer noch die selben 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

Im 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.

Da das wohl zahlreiche Laptops von Acer, über Asus und Dell bis hin zu MSI sowie auch „normale“ Mainboards wie auch 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 keine 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 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.

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, der 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.

Dies soll über Ultraschall-Signale geschehen, die über von einer Software generiert werden, über die Boxen des Computers abgespielt und von ein 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öhrempfinden (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.