Nvidia-Treiber und das Spielesystem: Zurück zu Debian Stable

In den vergangenen Monaten habe ich einige leidvolle Erfahrungen mit dem Nvidia-Treiber gemacht und dieses schlimme Unbill unter dem Schlagwort Nvidia in diesem Blog kundgetan. Nun mischten sich unter den Ärger mit den proprietären Grafikkartentreibern anderweitige Hardwareprobleme mit meinem Mainboard und es war nicht immer einfach das auseinanderzuhalten. Zu Nvidias Ehrenrettung muss ich noch hinzufügen, dass es für einen Grafikkartenhersteller auch nicht immer ganz einfach ist, das gesamte Sortiment an Modellen fortwährend mit aktuellen Linuxtreibern zu versorgen, wenn die ABI des X-Servers scheinbar monatlich wechselt. Das mag aber auch meine laienhafte Sicht der Dinge sein und am Ende hat immer derjenige die Torte im Gesicht, der unfreie Treiber anbietet und den Quellcode unter Verschluss hält oder?

Tatsache ist, dass ich seit der Version 1.10 des X-Servers und dem Nvidia-Treiber 275.36 kein vernünftiges X plus Treiberpaar mehr auf meinem Rechner benutzen konnte. Alles was danach kam war schlicht unbrauchbar. In meinem /var/log/Xorg.0.log war dann z.B.

Increasing EQ size to 512 to prevent dropped events

oder

EQ overflow continuing. 100 events have been dropped

zu lesen. Aktuell hängt bei mir jedes Mal das gesamte System, wenn ich z.B den Webbrowser oder ein Spiel wie OpenArena schließe. Wenn ich Glück habe hört es irgendwann von alleine auf, wenn ich Pech habe friert der Computer ein. Keine wirklich guten Voraussetzungen für eine dauerhafte Beziehung, weswegen ich auf einem zuerst reinen Debian Sid mittlerweile den alten X-Server und Nvidia-Treiber aus den Backports von Squeeze beziehe und auf Hold gesetzt habe.

Nicht wirklich überraschend holte mich der gleiche Fluch auch mit Ubuntu 12.04 ein. Meine kleine Sammlung von Tipps zum Lösen der Nvidia-Probleme ist, man glaubt es kaum, seit der Veröffentlichung einer der meistgelesenen Artikel dieses Blogs. Ich denke, es klingt zu Unrecht etwas gehässig, aber ich bin froh, dass ich da draußen nicht alleine mit meinem Nvidia-Ärger bin. 😛

Nach wie vor halte ich es so, dass ich zuerst die freien Nouveau-Treiber installiere. Auf den älteren Laptops sind natürlich noch ganz andere Grafikkarten verbaut (Stichwort Neomagic). Überall dort wo ich ein paar Mails abrufe, im Netz surfe oder einen Film anschaue, reicht das aber ohne Probleme aus.

Das Spielesystem

Gleiches kann ich von einem Spielesystem nicht mehr behaupten. Hier ist 3D-Performance schlicht ein Muss. Um jeden Fehler meinerseits auszuschließen, habe ich nochmal versucht ein sauberes Wheezy mit allen momentan zur Verfügung stehenden Treibern zum Laufen zu bringen. Leider Fehlanzeige. Sowohl 295 aus den Backports, 302 in Wheezy oder sogar der brandneue 304 aus Experimental, immer das gleiche niederschmetternde Ergebnis. Und dabei sollte doch schon mit Version 295.59 meine 9600GT wieder zu den Gewinnern zählen.

Man sieht daran aber auch, es liegt nicht an Debian Sid. Als ich vor einem Jahr das Multiboot-System aufgesetzt habe, wollte ich auch herausfinden wie sinnvoll ein solches System für Spieler ist. Heute bin ich mir sicher: Ja, man kann Debian Unstable benutzen, aber was nützt die marginale Performance-Verbesserung des Treibers, wenn er nicht funktioniert?

Ich habe ein altes Backup eingespielt und in der sources.list die Quellen von Sid auf Wheezy geändert. Da ich außer den Spielen und dem Grafikkartentreiber keine neuere Version der Software vermisst und ich diese Versionen fast ausschließlich auch über die Backports bekommen hätte, bleibt als Fazit nur zu sagen:

Zurück zu Debian Stable

Tipp: Probleme mit Nvidia-Treibern lösen – Downgrade von Precise auf Oneiric

Nach meinem Upgrade auf Lubuntu 12.04 stellten sich, wenig überraschend, die gleichen Probleme wie mit Debian Sid ein. Die neuesten Nvidia-Treiber 295.40 verursachen bei mir, Kero und wahrscheinlich noch einer Reihe anderer Leute Verzögerungen beim Verschieben von Anwendungen, die teilweise bis zum Einfrieren des gesamtes Desktops führen können.

Das Problem ist bekannt und betrifft unter anderem Geforce 6, 7 oder 8800GTX/GTS Karten. Ich benutze jedoch eine Geforce 9600 GT, die bis zum Update auf Lubuntu 12.04 einwandfrei funktionierte.

Seid ihr von ähnlichen Problemen betroffen, habt ihr folgende Optionen zur Hand.

1. Nvidia-Treiber komplett entfernen

sudo aptitude purge nvidia-current

Die Treiber lassen sich mit diesem Befehl komplett entfernen. Nach einem Neustart wird der Nouveau-Treiber aktiv, dessen Performance in der Regel für „normalen“ Desktopbetrieb ohne anspruchsvolle 3D-Spiele oder Compiz ausreichend ist.

2. Downgrade der Nvidia-Treiber von Precise auf Oneiric

Für diverse Setups sind weiterhin die Nvidia-Treiber notwendig. In diesem Fall könnt ihr einen Downgrade von Nvidia 295.40 (Precise) auf 280.13 (Oneiric) in Erwägung ziehen.

Ein Downgrade kann zu Problemen und anderen Inkompatibilitäten führen. Jetzt wäre der richtige Zeitpunkt für ein Backup. Wer sich bei den folgenden Schritten unsicher ist, sollte sie nicht ausführen!

Öffnet die /etc/apt/sources.list mit eurem bevorzugten Editor und schaltet das alte Apt-Repositorium für Oneiric und die „restricted“-Sektion frei, indem ihr diese Zeilen hinzufügt.

deb http://de.archive.ubuntu.com/ubuntu/ oneiric main restricted
deb http://security.ubuntu.com/ubuntu oneiric-security main restricted

Nvidia-Treiber downgraden

sudo aptitude update
sudo aptitude -t oneiric install nvidia-current

Apt warnt vor dem Downgrade, dass das virtuelle Paket xorg-video-abi-10 nicht gefunden werden kann. Mit „n“ lehnt ihr die erste Lösung ab und akzeptiert die zweite. Dies solltet ihr nur tun, wenn ihr auf die zum Entfernen markierten Pakete auch tatsächlich verzichten könnt. Der Vorgang sah bei mir so aus:

sudo aptitude -t oneiric install nvidia-current
Die folgenden Pakete haben verletzte Abhängigkeiten:
 nvidia-current : Hängt ab von: xorg-video-abi-10 , welches ein virtuelles Paket ist.
Die folgenden Aktionen werden diese Abhängigkeiten auflösen:

     Beibehalten der folgenden Pakete in ihrer aktuellen Version:
1)     nvidia-current [Nicht installiert]                        

Diese Lösung akzeptieren? [Y/n/q/?] n
Die folgenden Aktionen werden diese Abhängigkeiten auflösen:

      Entfernen der folgenden Pakete:
1)      xserver-xorg-input-all
2)      xserver-xorg-input-synaptics
3)      xserver-xorg-video-all
4)      xserver-xorg-video-sisusb
5)      xserver-xorg-video-tdfx
6)      xserver-xorg-video-trident
7)      xserver-xorg-video-vesa

Downgrade der folgenden Pakete:
9)      xorg [1:7.6+12ubuntu1 (now, precise) -> 1:7.6+7ubuntu7.1 (oneiric)]
10)     xserver-xorg [1:7.6+12ubuntu1 (now, precise) -> 1:7.6+7ubuntu7.1 (oneiri
11)     xserver-xorg-core [2:1.11.4-0ubuntu10.1 (now, precise-updates) -> 2:1.

usw.

Nach dem Downgrade ist es am sinnvollsten die neuen Nvidia- und Xserver-Pakete auf „Halt“ zu setzen, damit sie beim nächsten Update nicht erneuert werden.

sudo aptitude hold '~nnvidia'
sudo aptitude hold '~nxserver'

Welche Pakete das genau sind, erfahrt ihr mit

aptitude search '~ahold'

In meinem Fall hat das Downgrade das Problem vollständig beseitigt und das System läuft stabil. Ihr solltet nun von Zeit zu Zeit überprüfen, ob es eine neuere Nvidia-Version gibt, die das Problem lösen kann.

Die Pakete lassen sich mit

sudo aptitude unhold '~nnvidia'
sudo aptitude unhold '~nxserver'

wieder zum Aktualisieren freigeben.

Update: 06.05.2012

3. Upgrade auf nvidia-current in Quantal Quetzal

Als dritte Möglichkeit könnt ihr den Nvidia-Treiber auf die aktuelle Version in Ubuntu „Quantal Quetzal“ bringen. (z.Z. 295.49). Dazu ersetzt ihr das Wort „oneiric“ in den vorhergehenden Schritten durch „quantal“.

Bei Lubuntu 12.04 und meiner Geforce 9600 GT funktionierten alle drei nur die ersten beiden Möglichkeiten. Nachdem ich jetzt noch etwas länger mit 295.49 experimentiert habe, treten ab und an immer wieder Ruckler und Verzögerungen beim Verschieben von Fenstern auf. Für mich ist daher diese Version nicht die richtige Lösung.

Eine Beobachtung mit Debian Sid: Nvidia-Pakete auf hold setzen

Im Mai letzten Jahres habe ich ein Multiboot-System aufgesetzt und mir ein auf Spiele ausgerichtetes Debian Sid installiert. Es sind nur die notwendigen Programme für eine grafische Oberfläche mit Openbox installiert und ich bin sehr zufrieden mit dem Setup. Die Bedienung ist wie gewohnt reaktionsfreudig, einfach und schnell.

Das System ist dadurch immer topaktuell, insbesondere wenn es die Nvidia-Treiber betrifft, die für 3D-Spiele immer noch notwendig sind. Leider haben sie mir in der Vergangenheit auch Probleme bereitet. Ich habe deshalb vor mehreren Monaten beschlossen bei der letzten stabilen Version zu bleiben und die Pakete auf „hold“ zu setzen und nicht mehr zu erneuern.

Das geht am einfachsten mit

aptitude hold '~nnvidia'

Mit ~n und dem folgenden Begriff werden alle Pakete, die „nvidia“ im Namen führen bei einem Update zurückgehalten.

Mit dem Befehl

aptitude search '~ahold'

lassen sich alle geblockten Pakete anzeigen.

Nun, macht das wirklich Sinn? Ich denke ja. Voraussetzung ist, dass man gerne mit Unstable oder Testing arbeitet, ausprobiert und die neuste Software verwenden möchte. Updates für kritische Pakete, die in der Vergangenheit häufiger Probleme bereitet haben, sollen zurückgehalten werden. Im meinen Fall waren das die unfreien Nvidia-Treiber. Prinzipiell sollte sich das aber auch auf andere Software übertragen lassen.

Die Gefahr besteht natürlich, dass bei übertriebenem Einsatz von „hold“ notwendige Updates verhindert werden, die z.B. sicherheitskritisch sind oder die Stabilität des Systems verbessern. Meine bisherige Erfahrung mit den Nvidia-Treibern hat mir aber gezeigt, dass es auch sehr sinnvoll sein kann Updates zu blockieren.

Für diesen Beitrag habe ich zuerst mit Partclone ein Backup der Partition gemacht, auf der das Spielesystem installiert ist. Die Vorgehensweise war die gleiche wie damals bei TinyCore Linux.

Sichern

partclone.extfs -c -d -s /dev/sda7 -o /home/apo/backup/20120422_loki_sda7.img

Wiederherstellen

partclone.restore -d -s /home/apo/backup/20120422_loki_sda7.img -o /dev/sda7

Wie sich mal wieder gezeigt hat, sind Backups einfach unheimlich nützlich. Nachdem ich mit

aptitude unhold '~nnvidia'

die Nvidia-Pakete freigegeben hatte, machte ich ein Update auf die aktuelle Version 290.40. Schon kurze Zeit später stellte ich fest, dass sich Spiele nicht mehr richtig beenden ließen, die grafische Oberfläche einfror und der Rechner nur noch mit Hilfe von SSH und der Konsole neugestartet werden konnte.

Ich bin daraufhin wieder zu Version 275 zurückgewechselt. Der Paketbetreuer für Nvidia kann in diesem Fall wenig machen. Diese Art von Regressionen treten häufig auf und können nur durch Nvidia selbst gelöst werden. Am besten man meldet das Problem im Support-Forum von Nvidia.

Meine Beobachtung ist, dass man bei Debian durchaus auch Pakete einmal auf Halt setzen kann, was der Stabilität keinen Abbruch tut. Eher im Gegenteil.

Oh Freude: Mainboardtausch zu P5QPL-AM bewirkt Wunder

Anfang des Monats dachte ich, ich hätte alles unter Kontrolle und könnte damit leben. Schließlich hatte sich herausgestellt, dass der große und mächtige Core-Duo-Rechner zwar ab sofort nur noch mit 2 GB RAM bestückt werden konnte, merkwürdige Fehlermeldungen und Abstürze sich aber wahrscheinlich auf den aktuellen Nvidia-Treiber bezogen hatten, weswegen ich ein älteres Backup aufspielte und die betreffenden Treiber auf „halt“ setzte. Zumindest von den beängstigenden Segfault-Fehlern war weit und breit nichts mehr zu sehen.

Doch dann kam der Tag als ich eine recht große Datei komprimieren wollte, bzip2 sich aber im Laufe des Prozesses schlicht weigerte fortzufahren. Interessanterweise erschien eine sehr ausführliche Fehlermeldung, dass dieser Fehler wahrscheinlich im Zusammenhang mit fehlerhaftem RAM stehen könnte….Möglicherweise war da ja was dran.

Ich startete den Rechner neu und sah..Schwärze. Irgendwann funktionierte dann nicht mal mehr der Einschaltknopf, weswegen ich die Faxen dick hatte und mir ein neues Mainboard kaufte.

Ich suchte zuerst nach dem identischen Modell P5N73-CM, um auch der kleinsten Möglichkeit von Inkompatibilität aus dem Weg zu gehen, musste aber leider feststellen, dass sich dieser Typ in den vergangenen 2,5 Jahren äußerst rar gemacht hatte. Ich entschied mich schließlich für das P5QPL-AM von ASUS, welches vergleichbare Spezifikationen hatte.

Natürlich schaute ich vorher noch einmal nach dem empfohlenen RAM-Speicher auf der Herstellerseite, von TEAM-RAM aber keine Spur. Ich kreuzte also alle Finger und siehe da 2×2 GB TEAM TVDD2048M800 Module laufen stabil in diesem Board. Die einzig heikle Aufgabe war es den Prozessor samt Kühler vom alten Board auf das neue zu bekommen. Ich weiß nun ungefähr wie sich ein Chirurg bei einer Operation am offenen Herzen fühlen muss. 🙂

Um alle Zweifel auszuräumen unterzog ich die Kiste seit letzter Woche noch einigen Stresstests, um mal das Wort des Jahres zu benutzen. Es wurden 2 GB große Dateien xz komprimiert, für die Wissenschaft mit Boinc gerechnet und auch Unity habe ich benutzt.

Fazit: Operation erfolgreich, Patient lebt

Nur gute Nachrichten

Heute ist mir eingefallen, dass es eine ganz einfache Möglichkeit gibt herauszufinden, ob ein Rechner Hardwareprobleme mit sich herumträgt oder einfach nur die Software verbugt ist. Man muss nur ein älteres Backup einspielen als alles noch problemlos funktionierte und die Ergebnisse mit der aktuellen Situation vergleichen. 🙄

Nachdem ich diesen Geistesblitz hatte, schnappte ich mir ein mehr als zwei Monate altes Partitionsabbild meines minimalen Debian-Spielesystems, holte Clonezilla wieder hervor, spielte das Image ein und siehe da, keine X-Server-Abstürze und auch keine wirren Nvidia-Treiber-Fehlermeldungen mehr.

Besser so herum als feststellen zu müssen, dass man sich eine neue Graka oder gar PC kaufen muss. Wie zu erwarten war steckt der Fehlerteufel irgendwo zwischen den neuesten Nvidia-Treibern und dem Xorg-Server. Nur um zu sehen wie effektiv das Ganze ist, habe ich nun alle Nvidia- und Xorg-Pakete mit aptitude auf „hold“ gesetzt und bin gespannt wie sich das System in Zukunft verhalten wird.

Für ein Spielesystem halte ich zwar nach wie vor aktuelle Treiber für das A und O, doch diese gegen ein instabiles System einzutauschen macht keinen Sinn. Klammert man das Treiberproblem aus, funktioniert Debian Unstable auf der Maschine ausgezeichnet. Als Alternative bietet sich in Zukunft zum Vergleich an einmal Debian Stable zu installieren und die Treiber und den Xorg-Server aus den Backports oder sogar manuell zu installieren.

Debian Backup und Neuinstallation

Da ich gerade in Schwung war, habe ich mich entschieden das parallel installierte Hauptsystem auf Basis von Debian Testing (i386) gegen ein amd64 gleichen Typs auszutauschen. Als ich die Idee zu dem Multibootsystem hatte, wollte ich mit i386 auf Nummer sicher gehen, aber da der Core Duo 64bit unterstützt und ich Debian Testing darauf ausschließlich als Arbeits-PC benutze, macht es keinen Sinn an i386 festzuhalten.

Da ich nicht bis zur Marktreife von Multiarch warten wollte, wenn es möglich sein wird ein i386 System auf amd64 upzugraden, habe ich mich für die althergebrachte Neuinstallation und „The Debian Way“ entschieden. Ich hatte das komplette Home- und Etc-Verzeichnis gesichert, auf die Paketliste von dpkg aber verzichtet.

Es genügte vollkommen das Verzeichnis /home nach der Neuinstallation wieder einzuspielen und eine Handvoll Konfigurationsdateien aus dem alten Verzeichnis /etc manuell in das neue zu verschieben. Metapakete wie gnome-core waren schnell installiert und auch der Rest war lediglich ein

aptitude install Paketname

Nun muss sich das RAM-Problem nur noch irgendwie von selbst lösen. 😉