Linux und Hardware – immer wieder mal frickeln …

Tux
Tux

Letzte Woche knallte es. Nach einem routinemäßigen Systemupgrade hatte ich meine normale Unity-Oberfläche nicht mehr. Der Notfallmodus ging noch, sonst aber nicht viel. Das heisst also bei Ubuntu “Long Time Support”. Drei Monate vor der nächsten LTS und drei Jahre vor Supportende crasht einfach mal so die Grafik beim Upgrade.

Eine Netzrecherche brachte wenig Erhellendes, auffällig war allerdings, dass der proprietäre AMD fglrx-Treiber nirgend auftauchte, obwohl der doch eigtentlich für die Ausgabe verantwortlich sein sollte. Die Konfigurationstools meldeten, er sei nicht oder fehlerhaft installiert, die xorg.conf sah aber korrekt aus und im Paketmanager standen die entsprechenden Pakete als installiert. Keiner weiss also was Genaues.

Zu dem proprietären Treiber bin ich wohl vor einiger Zeit gewechselt, weil der Open-Source-Treiber nicht wollte oder Schwierigkeiten gemacht hatte. EIn Blick in den Paketmanager verriet, dass der noch installiert und aktuell war. Der Versuch, ihn via EIntrag in xorg.conf zu aktivieren, blieb zunächst ergebnislos, bis ich irgendwann auf die Idee kam, den proprietären Treiber komplett zu deinstallieren. Und das brachte mir nach entsprechendem Editieren der xorg.conf ein funktionierendes Unity zurück. Nebenbei: der Open-Source-Treiber erzeugt erheblich weniger Systemlast, so das die Gesamtperormance des Systems nun besser ist.

Notebook
Notebook

Im Zuge der Reperaturen habe ich dann gleich noch den Kernel von 3.2 auf 3.11 upgedatet (damit sollte die Kiste fit fürs im April anstehende Upgrade auf die nächste Long Term Support Version sein), so dass das ganze System auf modernerem Stand ist.

Ein weiteres Problem blieb dann noch: die Kiste (ein Thinkpad R500) neigt unter Vollast zu Heisswerden. Im Dock kann die Luft nicht so schnell abgeführt werden, ein Überdrehen des Lüfters via thinkfan ist nicht zu empfehlen, das führt dazu, dass man bald einen neuen braucht.

Ich hatte schon längere Zeit das Jupiter-Applet benutzt, welches eine Taktkontrolle per Mausklick erlaubt. Allerdings kann man nur grob zwischen maximaler Taktstufe, OnDemand und minimaler Taktstufe wählen – eine festeingestellte mittlere Taktstufe fehlt, gleichzeitig gibt es keine Szenarien, das z. B. von der Temperatur abhängig zu steuern. Das Standardverhalten läuft in meinen Augen zu knapp an die Notabschaltung heran, so dass ich eine kühlere Lösung suchte.

Fündig wurde ich durch ein kleines Script von Sepero Hacker, das genau das ermöglicht: Erreicht die CPU die Grenztemperatur, taktet sie runter, wird sie kühler, taktet sie wieder hoch. Damit sollte sich eine befriedigendere Balance zwischen optimaler Leistung und kühlem System herstellen lassen. Von Hand gestartet, tat das Script, was es sollte. Aber will man bei jedem Systemstart dran denken und längliche Scriptaufrufe von Hand starten? Ich will das zumindest nicht.

Eingetragen in /etc/rc.local startet es nun automatisch und macht seinen Job. Nachdem ich die Kiste aber mal in den Bereitschaftsmodus versetzt und wieder aufgeweckt hatte, war das Script weg, die CPU wurde wieder zu warm. Also musste ich noch ein Aufwachscript anlegen, welches das Script nach dem Aufwachen wieder startet. Wie das geht, steht hier.

Rückblickend muss ich sagen: Linux rockt. Dinge, die ich bei anderen Systemen hinnehmen muss, lassen sich hier mit ein wenig frickeln lösen. Ein wenig Grips und Recherche, und das System läuft genau so, wie ich es will und für richtig halte.