Tag: Nvidia

Posted on

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

Posted on

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.

Posted on

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.

Posted on

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 2x2 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

Posted on

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

Posted on

Eine gute und eine schlechte Nachricht

Der erste Eindruck hat nicht getrogen und tatsächlich hatte das Netzteil des Thinkpad 600 durch den Kurzschluss auf dem Weihnachtsmarkt ordentlich etwas abbekommen. Mit dem neuen Universalnetzteil funktioniert die Kiste aber wieder, Debian, ConnochaetOS, KolibriOS und Co. laufen einträchtig im Multibootsystem und alle Daten sind nach wie vor intakt. Eine gute Nachricht, weswegen weiteren Experimenten nichts entgegenstehen sollte. 🙂
Auf der anderen Seite hat mich in letzter Zeit der etwas verrückt spielende Core Duo in Atem gehalten, weshalb weniger Zeit für interessantere Computerprobleme geblieben ist. Die weniger gute Nachricht lautet dann auch, dass das System weiterhin instabil ist, obwohl ich mittlerweile einige Zeit damit verbracht habe, um mich über den Unterschied von Single- und Dual-Channel-RAM zu informieren, schon wieder gelernt habe :roll:, dass man selbst bei sorgfältiger Recherche immer noch Fehler machen kann und zu guter Letzt nicht mehr unterscheiden kann, ob es nun ein Hardware- oder doch eher ein Softwareproblem ist. Aber der Reihe nach.
Der Core Duo besaß einmal 2x 2GB-RAM-Module des Herstellers Team Group aus Taiwan mit der genauen Produktbezeichnung TVDD2048M800. Nachdem mehrere Anwendungen kontinuierlich abstürzten und ich mit Memtest86+ festgestellt hatte, dass offenbar der Speicher defekt war, entfernte ich ein Modul und alles schien wieder in Ordnung zu sein.
Nach einiger Zeit wiederholte sich das Spiel aber und ich beschloss das Übel loszuwerden und mir neuen Arbeitsspeicher zu kaufen. Da der Hersteller meines Mainboards ASUS war, begab ich mich auf dessen Homepage um mehr über geeigneten RAM für mein P5N73-CM Motherboard herauszufinden. Dort gab es tatsächlich ein PDF-Datenblatt mit einer "Qualified Vendor List".
"Großartig", dachte ich, dort werde ich sicherlich den passenden RAM für mein Board finden. Ich wählte natürlich den schnellstmöglichen PC6400 RAM mit 800Mhz Speichertakt und entschied mich für Kingston KHX6400D2LLK2/1GN. Stutzig machte mich nur, dass der ehemals verbaute RAM von TEAM gar nicht in der Liste auftauchte.
Ich bestellte daraufhin also KHX6400D2LLK2/4G, wobei ich gutgläubig aber leider auch naiv annahm, dass das der gleiche Speicher war, der lediglich als 2x2 GB RAM Kit verkauft wurde. Das 11. IT Gebot lautet aber, "Du sollst dir über Hardware kein Bildnis machen!".
Augenscheinlich funktionierte nur ein Modul gleichzeitig mit meinem Board, so dass ich nur 2 GB installieren konnte. Ein Blick danach auf die Kingston Homepage offenbarte mir dann meine Fehleinschätzung. Ich hatte mir ein Dual-Channel-Memory-Kit gekauft, mein Motherboard unterstützte aber nur Single Channel.
Da ich nun keine Lust mehr auf weitere Experimente hatte, bestellte ich einfach zwei 2GB-Module des Original-TEAM-RAMs. Gleicher Typ, gleicher Hersteller, eine narrensichere Angelegenheit.
Als ich jedoch beide Bausteine eingesetzt hatte und mich schon über die Anzeige 4096 MB im Bios gefreut hatte, wurde mein Freudentaumel jäh durch eine GRUB-Fehlermeldung beendet.
Egal was ich auch tat, entweder startete der Rechner nach dem Erreichen des GRUB-Menüs neu, fror ein oder zeigte mir diese Fehlermeldung. Jedoch mit einem RAM-Modul und 2 GB RAM scheint es keine Probleme zu geben. Möglicherweise ist sogar das Motherboard selbst defekt. Passend dazu bekomme ich seit neustem, aber nur mit dem Nvidia-Treiber, diese Fehlermeldung.

NVRM: Xid (0000:02:00): 13, 0003 00000000 00008297 00001338 0000fd20 0000000c
[28271.390112] NVRM: Xid (0000:02:00): 13, 0003 00000000 00008297 00000e08 0015f404 00000004
[28276.495279] NVRM: Xid (0000:02:00): 13, 0003 00000000 00008297 00000e08 0015ff04 00000004
[28278.719604] NVRM: os_schedule: Attempted to yield the CPU while in atomic or interrupt context

Im offiziellen Nvidia-Forum habe ich diesen Thread dazu gefunden, der aber scheinbar nicht weiterverfolgt wird. Die Symptome sind ein manchmal kurz flackernder Bildschirm und teilweise ein komplettes Einfrieren des gesamten X-Servers, der sich danach nur noch über SSH beenden lässt. Hängt dies nun ebenfalls mit dem RAM-Problem zusammen oder ist das nur eine unglückliche Verquickung von Hardware- und Softwarefehlern?
Ich weiß zur Zeit nur eins. Solange ich 2 GB RAM und die freien Nouveau-Treiber benutze, scheint das System stabil zu laufen, benutze ich hingegen den Nvidia-Treiber ist ein Neustart des X-Servers vorprogrammiert. Für einen Rechner, der mehr als doppelt soviel gekostet hat wie alle gebrauchten Laptops des Haushalts zusammen, eine eher schlechte Nachricht.

Posted on

Nvidia, Xorg 1.11.1 und etwas Licht am Horizont

Es gibt mal wieder etwas Positives von der Bugfront zu berichten. Ich hatte vor kurzem erwähnt, dass nach dem Update auf Xorg 1.11.1 plötzlich Iceweasel und andere Anwendungen heftig in meinem Debian-Testing-System laggten und die CPU-Last stark angestiegen ist.
Bei einem so offensichtlichen Problem kann man sich praktisch immer sicher sein, dass noch viel mehr Leute davon betroffen sind. Ich hatte damals keine Lust tiefer in die Problemlösung einzusteigen, da ein Wechsel zum freien Nouveau-Treiber das Problem für mich gelöst hatte und ich volle 3D-Unterstützung auf diesem System sowieso nicht benötige. Lediglich das laute Lüftergeräusch wegen des mangelhaften Powermanagements des Nouveau-Treibers blieb ein Makel.
Brandaktuell erfuhr ich dann vor einer Stunde beim Überfliegen der Debian-Devel-Mailingliste indirekt von der Lösung des Problems. Debian Bug #642757 beschäftigt sich nämlich mit dem gleichen Übel. Bisher sind schon 13 weitere Fehlerberichte damit zusammengeführt worden.
In Kürze, Xorg ist nicht schuld, sondern der proprietäre Nvidia-Treiber. Moment mal, werden sicher einige sagen. Nvidia funktionierte doch einwandfrei bis zum Update auf X 1.11.1. Das stimmt auch, aber solange der freie Nouveau-Treiber mit dem veränderten Xorg funktioniert, hat der Nvidia-Treiber vorerst die Torte im Gesicht.
Im Nvidia-Forum gibt es hierzu auch einen Thread mit einem offiziellen Beitrag eines Nvidia-Mitarbeiters, der das Problem technisch so erklärt:

I tracked this down to this commit to the X server:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=788ccb9a8bcf6a4fb4054c507111eec3338fb969
It removed our ability to accelerate part of the trapezoid rendering process and forces the whole thing (even the part we can accelerate) to fall back to software on GPUs that do not support full trapezoid acceleration. I've started a discussion on the xorg-devel@lists.x.org mailing list to see how the X community wants to solve this problem:
http://lists.x.org/archives/xorg-devel/2011-October/026050.html

Trapezoid Rendering Process wird mich nun sicherlich noch nächtelang im Schlaf verfolgen...
Im gleichen Thread gibt es auf Seite 2 einen inoffiziellen Patch, der scheinbar für einige dort funktioniert hat. Ich bin bei so etwas immer etwas vorsichtig und ehrlich gesagt kann ich auch noch eine Weile auf den offiziellen Fix warten. Doch für alle, die wirklich dringend eine Lösung suchen, weil sie morgen in der ESL wieder ihren Unterhalt verdienen müssen oder der nächste Raid vor der Tür steht, ist der Fix vielleicht ein Hoffnungsschimmer.
Für mich interessant ist aber die Diskussion, die das Ganze (vermutlich) anstoßen wird. Um solche gravierenden Bugs nämlich vor dem Update zu erkennen, gibt es ein Debian-Programm namens apt-listbugs, welches vor der Installation ausdrücklich warnt, falls ein Paket ein ernstes Problem verursachen würde.
In diesem Fall befanden sich die Fehlerberichte jedoch alle im Nvidia-Paket und nicht in den Xorg-Paketen, weshalb apt-listbug keinen Alarm auslöste. Wie es damit weitergeht? Keine Ahnung. Debian entwickelt sich immer weiter und was scheinbar im ersten Moment einfach nur ärgerlich war, führt plötzlich zu einer Verbesserung des Projekts an einer ganz anderen Stelle.
Übrigens, auf dem gleichen Rechner habe ich das Problem mit Debian Unstable nicht, obwohl ich dort die gleichen Xorg- und Nvidia-Pakete verwende und das verwirrt mich im Moment wirklich am meisten. 😉
Update 07.11.2011: Seit wenigen Tagen gibt es in Debian Sid ein Update der Nvidia-Pakete, welches das Problem beseitigt.

Posted on

Nvidia oder Nouveau: Xorg 1.11.1 und das Dilemma mit den Treibern

Wie einige vielleicht wissen, bin ich im April auf ein Multi-Boot-System umgestiegen. Anstelle von Ubuntu als einziges Betriebssystem auf dem Dual-Core-Rechner, dient dieses nun als Video- und Bildbearbeitungsplattform, Debian Sid in der Minimalinstallation als Spielesystem und Debian Testing erledigt die Hauptarbeit mit Bürosoftware, E-Mail-Programm und Webbrowser. 90 % der Zeit mit dem Dual-Core-Rechner verbringe ich dann auch mit Debian Testing.
Vor wenigen Tagen gab es ein Update auf die aktuelle Version des Xorg-Servers 1.11.1. Seitdem verursachen manche Seiten in Iceweasel und anderen Browsern eine hohe CPU-Last und selbst das kurze Überfahren des AWN-Docks mit dem Mauszeiger bringt die CPU wegen der Compositing-Effekte schon ins Schwitzen.
Da es in mehreren Applikationen auftritt, liegt der Verdacht nahe, dass das letzte X-Update dafür verantwortlich ist. Wie meldet man aber so einen Bug und formuliert das Problem richtig? Immerhin gibt es ja nicht nur ein Paket zum X-Server. Ein simples: "Iceweasel ruckelt. Es muss an eurem X-Server liegen. Macht was" hilft sicher nicht weiter.
Ich suchte erst noch einmal etwas genauer im Netz und fand irgendwo den Hinweis, dass nicht unbedingt X, sondern die Nvidia-Treiber schuld seien. Und tatsächlich, als ich auf die freien Nouveau-Treiber umgestellt hatte, gab es plötzlich kein Geruckel mehr.
Damit wäre die Sache eigentlich erledigt, der Bug und das Problem aber nicht beseitigt. Das X-Team von Debian würde mich mit Sicherheit direkt zu Nvidia verweisen, da unfreie Pakete wegen dem verschlossenen Quellcode nicht von Debian gefixt werden können. Wahrscheinlich könnte Nvidia dann nur sagen, dass vor dem Update der Treiber wie beabsichtigt funktionierte und Xorg der Übeltäter sei.
Hier hilft außer ein Warten auf ein Xorg- oder Nvidia-Update nicht viel. Natürlich könnte man versuchen ein Downgrade auf die letzte Version von X zu machen. Sinnvoller wäre es auf die freien Treiber auszuweichen. Warum nutze ich die eigentlich nicht? Immerhin habe ich ja schon ein parallel installiertes OS für Spiele.
Das große Problem von Nouveau ist weniger der experimentelle 3D-Support, sondern auch die mangelhafte Unterstützung von Powermanagement-Funktionen. Der Lüfter meiner "Nvidia 9600 GT"-GraKa dreht nämlich permanent auf 100%. Hinzu kommen kleinere Fehler z.B. flackert mein Cursor auf manchen Webseiten plötzlich. Mit nvclock gelang es mir bisher leider ebenfalls nicht die Lüftergeschwindigkeit anzupassen.
Für mich heißt das erst einmal warten auf Gnome 3. Sollte Nouveau hier ähnlich gut funktionieren wie bei Arch Linux, erwäge ich den Umstieg, nehme auch das lautere Lüftergeräusch in Kauf und drehe in Zukunft die Musik einfach etwas lauter auf. 😉