Durch dieses Problem wird die Leistungsaufnahme nun deutlich nach oben getrieben, verschiedene Stellen sprechen von 30 bis 40% mehr Energieverbrauch und damit natürlich eine höhere Temperatur der CPU, schneller drehende und somit lautere Lüfter und logischerweise auch kürzere Akkulaufzeiten. Mit ein paar Kernel-Parametern kann man jedoch auch den Kernel 3.0 aus Ubuntu Oneiric dazu bringen die CPU in den gewünschten RC-6 Zustand zu versetzen, allerdings haben User anschließend von Problemen mit der Grafikausgabe berichtet. Es bleibt daher abzuwägen, ob der Tipp sich für alle Sandy-Bridge Notebooks/Deskops eignet.

Richtig ausführliche Tests zu den einzelnen Kernel-Parametern findet Ihr auf Phoronix, die Jungs haben verschiedene Tests gefahren und die Auswirkungen eines jeden der dort genannten Kernelparameter auf die Leistungsaufnahme wie auch die Performance untersucht. Allerdings kann auch Phoronix nicht sagen, welche Modelle durch die Tweaks Grafikprobleme aufweisen und welche nicht, von daher bleibt es euch überlassen das ganze selber zu testen.

Hast du einen Rechner mit Sandy-Bridge Chipsatz?

Ersteinmal würde ich sicher gehen ob ihr auch wirklich ein System mit Sandy-Bridge habt. Solltet euer Notebook ein paar Jahre alt sein, dann wird dies mit Sicherheit nicht der Fall sein. Habt ihr jedoch euren Rechner gerade erst oder vor ein paar Monaten gekauft und nicht gerade das günstigste Modell genommen, dann ist die Chance recht hoch, dass ihr einen Sandy-Bridge Rechner habt. Solltet ihr euch in dieser Richtung nicht sicher sein, dann schaut am besten via…

$ grep name /proc/cpuinfo
model name      : Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz

…nach eurer CPU und schaut dann mit dieser Nummer in der Wikipedia nach, ob bei euch solch ein Chipsatz verbaut ist. Alternativ könnt ihr natürlich auch auf den Rechner sehen und nach dem passenden „Intel Core i“-Logo suchen. Auch hier hilft die Wikipedia wieder mit den passenden Logos aus.

Wie viel Schluckt die CPU aktuell?

Als nächstes würde ich mir den aktuellen Stromverbrauch ansehen, nicht dass ihr später die Kernelparameter nutzt und vielleicht leichte Grafikprobleme bemerkt, die Einstellung aber letztendlich nichts bringt. Schaut daher entweder mit Powertop oder durch Auslesen von /proc/acpi/battery/BAT0/state nach, was die CPU aktuell schluckt. Lasst den Rechner dazu am besten ein Minütchen arbeitslos vor sich hin zuckeln.

$ powertop  # muss wahrscheinlich installiert werden
$ grep rate /proc/acpi/battery/BAT0/state
present rate:            14406 mW

Schreibt euch den Wert am besten kurz auf, so könnt ihr später dann vergleichen, ob es wirklich etwas gebracht hat. Powertop ist von Haus aus nicht auf einem Ubuntu-System installiert, ihr könnt die Anwendung jedoch über das gleichnamige Paket bequem aus der Paketverwaltung heraus installieren.

Die Kernel-Parameter setzen

Nun wo hoffentlich alles Infos beisammen sind, könnt ihr die eigentlichen Einstellungen vornehmen. Öffnet dazu die Datei /etc/default/grub in euren bevorzugten Editor mit Root-Rechten…

$ sudo gedit /etc/default/grub

…und sucht euch diese Zeile heraus…

...
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
...

…dort fügt ihr dann erstmal die Parameter quiet splash pcie_aspm=force acpi=noirq i915.i915_enable_rc6=1 an. Das Ganze lässt sich noch entsprechend anpassen, es sind aber die Optionen, die nach dem Bug her am besten funktionieren. Probiert es daher erstmal mit dieser Kombination.

...
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pcie_aspm=force acpi=noirq i915.i915_enable_rc6=1"
...

Abschließend muss das noch mit einem…

sudo update-grub

…in die Konfiguration von Grub geschrieben werden. Startet danach euren Rechner neu und überprüft erneut über Powertop oder den oben genannten Befehl die aktuelle Leistungsaufnahme des Systems. Ihr solltet jetzt Einsparungen zwischen 30 und 40% feststellen können. Ich bin mal gespannt was ihr berichtet, da ich kein Gerät mit diesem Chipsatz besitze, kann ich das leider nicht selber ausprobieren.

Weitere Kernelparameter

Oben habe ich ja schon den Beitrag auf Phoronix erwähnt, die alle in diesem Zusammenhang relevanten Kernelparameter i915.i915_enable_rc6=1, i915.i915_enable_fbc=1, i915.lvds_downclock=1 ausgetestet haben. Die einzelnen Optionen können für weitere Verbesserung sorgen, eventuell führen sie aber zu zusätzlichen Abstürzen oder Grafikproblemen. Daher würde ich die Optionen nach und nach einfügen und austesten, ob sie sich mit dem System vertragen.

i915.i915_enable_rc6=1 – RC6 was enabled by default for a while, but then it ended up being too buggy for some hardware configuration so it had to be disabled. For affected systems on the current code-base, enabling RC6 can cause GPU hangs. The Intel RC6 feature allows the GPU to enter a lower power state when the GPU is idling.

i915.i915_enable_fbc=1 – This kernel option enables FBC (frame-buffer compression) for the Intel graphics driver. Frame-buffer compression is not enabled by default since for some systems when frame-buffer compression is active there is a bug where the screen is not being properly repainted when using a compositing window manager. As implied by the name, frame-buffer compression will compress the buffer of what’s to be drawn to the screen so that less memory bandwidth is used on screen refreshes, and as a result, less memory being confused.

i915.lvds_downclock=1 – This kernel option will down-clock the LVDS refresh rate, which can increase power savings as a result. However, for systems that do not properly support LVDS down-clocking, the screen can begin to flicker during use.

Ob das Ganze was bringt und ob es zu Seiteneffekten kommt, kann ich an dieser Stelle nicht ausprobieren. Ich wäre happy wenn ihr an dieser Stelle ein bisschen Feedback bekommen könnte, besonders Interessant sind natürlich eure Ergebnisse bzgl. des Stromverbrauchs und ob es zu Problemen mit der Grafikausgabe oder zu Abstürzen kommt.

Das Paket yum-utils ist bei Fedora 13 von Haus aus installiert, von daher kann man auf jedem aktuellen Fedora-System einfach etwas in dieser Art…

$ package-cleanup --oldkernels --count=2

…aufrufen. Dabei werden alle Kernel bis auf die letzten zwei deinstalliert. Einfacher gehts eigentlich nicht mehr.

Noch besser wäre es in meinen Augen, wenn der Update-Manager auf die Vielzahl von installierten Kernels hinweisen und auf Wunsch die letzten Kernel – bis auf die X neusten – deinstallieren würde, doch das zum Implementieren bedeutet natürlich einen höheren Aufwand als das eigentlich doch recht simple Kommando. Ich hatte daher auf brainstorm.ubuntu.com eine Idee eingebracht…[Offline]…doch mir kam jemand zuvor, somit muss ich mich mit „Solution #4“ zufrieden geben [Offline] Wäre schön, wenn sich hier früher oder später eine simple Lösung ergeben würde, denn gerade unerfahrene Anwender misten selten die Kernel aus. Ich habe schon Rechner mit mehr als zehn Kernel gesehen (Ubuntu Brainstorm wurde eingestellt und die Webseiten abgeschaltet).

Betrachtet man den gesamten Kernel – Die Version 2.6.30 besteht aus 12.606.910 Zeilen Quelltext – so würde ein Unternehmen folgende Leistung bringen müssen um den Kernel komplett zu entwickeln.

• Gesamtwert: 1.025.553.430 Euro
• Benötigte Entwickler: 985,74
• Geschätzte Entwicklungszeit: 167,59 Monate (14 Jahre)

Bricht man die Zahlen auf einzelne Jahre runter, dann hätten in den Jahren von 2005 bis 2007 jeweils zweistellige Millionenbeträge investiert werden müssen. Im Jahr 2008 stieg dieser Wert sprunghaft an.

• 2005 (Von 2.6.11 zu 2.6.16): 80.141.810 Euro
• 2006 (Von 2.6.16 zu 2.6.21): 72.704.900 Euro
• 2007 (Von 2.6.21 zu 2.6.25): 94.729.880 Euro
• 2008 (Von 2.6.25 zu 2.6.30): 228.353.700 Euro

Leider sagt die Studie nichts über das Jahr 2009 oder gar 2010 aus, ich hätte gerne aktuelle Zahlen gesehen. Über die absoluten Werte kann man gerne spekulieren, basieren sie doch auf Abschätzungen und Annahmen. Doch sie zeigen, dass der Linux-Kernel in den vergangenen Jahren enorm an Attraktivität für Unternehmen und deren Entwickler gewonnen hat. Laut Slashdot entsprechen die Entwicklungskosten des Linux-Kernels aus dem Jahre 2008 4% bzw. 12% der Kosten für Forschung und Entwicklung, die Microsoft bzw. Google in dieser Zeit für sämtliche ihrer Produkte ausgegeben haben.

Über Synaptic kann man sich die alten Kernel in einer graphischen Umgebung raussuchen und sie dann deinstallieren. Doch dazu müsste man sich nach und nach allen alten Ballast raussuchen und von Hand zur Deinstallation vormerken. Das ist umständlich und dauert durchaus ein kleines Weilchen, erst recht wenn sich im Ubuntu-System nach einer ganzen Weile eine Menge Kernel angesammelt haben. Mit ein bisschen Shell-Magie deinstalliert man jedoch mit nur einem Kommando alle alten Linux-Kernel inklusive ihren Headern. Via…

…löscht ihr alle alten Kernel inklusive den jeweils zusätzlich installierten Kernel-Headern von der Festplatte. Der aktuelle Kernel des Systems bleibt dabei komplett unangetastet. Ihr müsst also keine Angst haben, dass ihr nach dem Ausführen des Befehls gleich ganz ohne Kernel dasteht und euren Computer nicht mehr booten könnt. Trotzdem solltet ihr einen kritischen Blick auf die Liste der zu deinstallierenden Pakete werfen, nicht dass aus irgendeinem Grund eine Abhängigkeit quer schießt und das halbe System von der Platte fliegt.

$ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
Die folgenden Pakete werden ENTFERNT:
linux-headers-2.6.31-13* linux-headers-2.6.31-13-generic*
linux-headers-2.6.31-14* linux-headers-2.6.31-14-generic*
linux-image-2.6.27-14-generic* linux-image-2.6.31-13-generic*
linux-image-2.6.31-14-generic* linux-restricted-modules-2.6.27-14-generic*
0 aktualisiert, 0 neu installiert, 8 zu entfernen und 10 nicht aktualisiert.
Nach dieser Operation werden 441MB Plattenplatz freigegeben.
Möchten Sie fortfahren [J/n]?

Allerdings würde ich generell ältere Kernel erst dann von der Festplatte löschen, wenn ich weiß dass ich mit dem aktuellen Linux-Kernel definitiv keine Probleme habe. Lasst nach einem Kernelupdate den alten Kernel daher also noch ein paar Tage oder gar ein paar Wochen auf eurem Rechner. Die dadurch verbrauchten MByte lassen sich meist verschmerzen. Das Aufräumen könnt ihr ja immer noch nachholen, mehr als einen Befehl braucht es dazu ja nicht.

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.

Es sei angeblich kein Kabel angesteckt. Natürlich schiebt man die Schuld erstmal auf die DSL-Hardware. Also DSL-Router neu starten, Switch und Kabel kontrollieren. Es waren aber keine Fehler zu finden. Des weiteren leuchteten die Lichter am Switch und an der Netzwerkkarte genauso wie immer. Die Netzwerkkarte ist also „eigentlich“ verbunden. Allerdings sagen

$ sudo ethtool eth0
[...]
	Link detected: no

und

$ dmesg | grep eth
[...]
[   39.513660] forcedeth 0000:00:08.0: irq 2302 for MSI/MSI-X
[   39.514304] eth0: no link during initialization.
[   39.515419] ADDRCONF(NETDEV_UP): eth0: link is not ready

eine andere Sprache. Das Netzwerk lässt sich in Ubuntu Jaunty nicht aktivieren, egal was man macht… Boote ich jedoch die SystemRescueCD, so kann ich ohne Probleme mein Netzwerk aufbauen.

Schuld daran scheint Kernel 2.6.29.3 aus der SystemRescueCD zu sein. Der aktuelle Kernel scheint eine Regression zu haben, die verhindert dass die Netzwerkkarte mit älteren Kerneln aktiviert werden kann. Meine „Lösung“ für dieses Problem war nun

• Rechner mit der SystemRescueCD booten
• Netzwerk aktivieren
• Rechner HART abschalten

Danach funktionierte das Netzwerk in Jaunty wieder wie gehabt. Eventuell versetzt der neue Kernel aus der SystemRescueCD die Netzwerkkarte via ACPI in einen Zustand, aus dem sie ein „alter“ Kernel nicht mehr wecken kann. Möglicherweise reicht es auch einfach den Rechner einmal vollständig abzuschalten, das habe ich nicht weiter ausgetestet…

Ich vermute, dass das Problem alle Distributionen mit Kernel 2.6.29 (oder neuer) und Rechner, die mit dem forcedeth Kernelmodul arbeiten, betrifft. Die Info sollte man also im Hinterkopf behalten, wenn man demnächst Live-CDs mit Ubuntu Karmic ausprobiert und entsprechende Hardware besitzt…

UPDATE: Leser dieses Artikels sollten bedenken, dass sich das Rad der Geschichte immer weiterdreht. Zum Zeitpunkt der Erstellung des Beitrages waren diese Informationen korrekt, doch mittlerweile kann man beruhigt zu Ext4 greifen. Die im Beitrag genannten Patches haben es sogar noch in den Kernel von Ubuntu Jaunty geschafft. Ext4 IST in der Zwischenzeit reif für den Desktop geworden!

I recently installed Kubuntu Jaunty on a new drive, using Ext4 for all my data.

The first time i had this problem was a few days ago when after a power loss ktimetracker’s config file was replaced by a 0 byte version . No idea if anything else was affected.. I just noticed ktimetracker right away.

Today, I was experimenting with some BIOS settings that made the system crash right after loading the desktop. After a clean reboot pretty much any file written to by any application (during the previous boot) was 0 bytes. For example Plasma and some of the KDE core config files were reset. Also some of my MySQL databases were killed…

Es ist auch kein „Ubuntu-Problem“

I thought it was worth adding this, even though I’m running Gentoo, it seems to be exactly the same issue:

I recently upgraded to ext4 as well, I ran a game in Wine and the system hardlocked (nothing special there with the fglrx drivers). After rebooting all my Wine registry files were 0 bytes, as were many of my Gnome configuration files. Absoloute nightmare. fsck on boot said that it had removed 760+ orphaned inodes.

Um es kurz zusammenzufassen: Sollte ein Rechner mit Ext4 Partitionen abstürzen oder ihm der Saft ausgehen, so droht massiver Datenverlust. Die Gefahr bei einem Crash Daten zu verlieren ist deutlich höher als bei Ext3. Das Problem ist massiv und Bedarf sowohl Änderungen am Kernel wie auch Änderungen an der Art und Weise wie Anwendungen Daten ablegen. Theodore Ts’o – einer der bekanntesten Entwickler des Linux Kernels – fasst das Problem hier sehr gut zusammen.

Ext4 mag reif für Serversysteme sein, denen dank USV sicherlich nie der Strom ausgeht. Doch man sollte es sich mehr als zweimal überlegen Ext4 auf einem Notebook oder Desktop einzusetzen, denen dank proprietären Treiber und experimentierfreudigen Usern der eine oder andere Absturz droht!