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 2×2 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.

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.

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