RSS-Feed anzeigen

mj

Des Rechners neue Kleider: Die fglrx, die!

Bewerten
Tux
Es gibt Tage, da verliert man, und es gibt Tage, da gewinnen die anderen. Und es gibt Tage, da kann man nicht gewinnen. Seit mehreren Tagen schon befinde ich mich im Krieg mit einem schier unbezwingbaren Gegner. Jedes Mal, wenn ich eine Schlacht gewinne, holt mein Nemesis zum Gegenschlag aus und wirft mich zurück. Ich bin nicht meines Gegners erstes Opfer und mit Sicherheit auch nicht sein stärkstes. Vermutlich wirke ich für ihn wie ein 25 Zentimeter großer einäugiger Gnom, der mit einem stumpfen Holzschwert auf seine massive Eisenrüstung einschlägt. Oder wie der schwarze Ritter aus Monty Pythons „Ritter der Kokosnuss“ - ohne Arme, ohne Beine und schwer angeschlagen bin ich bereit, meinem Gegenüber ein Unentschieden anzubieten. Oder wie Don Quijote für Arme. Mein Gegner: niemand geringeres als fglrx. AMDs Inkarnation des puren Bösen, der Sohn Satans auf Erden, die digitale Version des Hauses, das Verrückte macht, entsprungen aus den Untiefen der Büchse der Pandora höchstpersönlich und wie das Teufelchen mit dem Schäufelchen nur aus einem einzigen Grund auf Erden: Um größtmöglichen Schaden anzurichten.

Die großen Schlachten, in chronologischer Reihenfolge:

Die Schlacht um die Darstellung
Nachzulesen im Kriegstagebuch, zweiter Eintrag: installiert man fglrx, funktionieren andere Treiber nicht mehr. Weder radeonhd noch vesa waren zur Mitarbeit zu überreden. Die CPU-Last bei Verwendung von fglrx lag bei 100%, das System war unbrauchbar. Die Buchstaben in der Konsole (tty1-tty6) waren stark verzerrt und teilweise doppelt – arbeiten unmöglich. Umschalten auf reinen Text-Modus beseitigte zwar das Symptom, jedoch auf Kosten der Darstellungsqualität. 80x25 Zeichen wirken auf einem 22“ Monitor irgendwie antik.

Die Schlacht um die Stabilität
Aus heiterem Himmel fror der Rechner ein. Ohne Last und ohne, dass ich daran arbeitete – einfach so. Das war noch nie passiert, der PC war zuvor teilweise wochenlang im Dauereinsatz gewesen und nie abgestürzt. Eingefroren reagierte er auf keinerlei Eingaben mehr, auf dem Bildschirm flimmerte noch die exakte Uhrzeit des Absturzes. Kurzer Test per SSH: der PC war noch ansprechbar! Also angemeldet und versucht, kdm und den X-Server abzuschießen. Wäre aber auch zu schön gewesen, denn selbst ein kill -9 brachte nicht den gewünschten Erfolg (für alle nicht-Linuxer: kill -9 ist auf einen Prozess bezogen das Software-Äquivalent des Reset-Schalters). Auch ein Neustart war also nicht möglich. Einzige Abhilfe war das Hardware-Äquivalent des Software-Äquivalents des Reset-Schalters, nämlich der Reset-Schalter.

In den Logs war übrigens erwartungsgemäß gar nichts zu finden. Einen Hardwaredefekt schloss ich aus, denn wäre dies der Fall gewesen, hätte das System sich auch nicht mehr per SSH ansprechen lassen. Meine Befürchtungen bestätigten sich nach kurzer Recherche: die Foren sind voll von Beiträgen über sporadisch einfrierende Systeme beim Einsatz von fglrx.

Die Schlacht um die Performance
Den finalen Todesschlag versetzte mir fglrx in Zusammenarbeit mit Flash, einem weiteren Erzgegner der Linux-Gemeinde. Anfänglich gab es keine Probleme, bis ich eines Tages auf die geradezu aberwitzige Idee kam, einen schnelleren Prozessor einzubauen. Da ich demnächst mehrere virtuelle Maschinen gleichzeitig betreiben muss, habe ich den energieeffizienten 65W Athlon 64 X2 5200+ gegen einen alles andere als sparsamen 95W Phenom X3 8750 getauscht, der bis zu diesem Zeitpunkt aufgrund seines unersättlichen Energiehungers schon im Leerlauf (25W mehr als der X2 5200+) friedlich im Schrank schlummerte. Großer Fehler, denn fglrx gab sich äußerst pikiert und weigerte sich fortan, Flash-Videos im Vollbild abzuspielen. Meiner täglichen Daily Show beraubt begab ich mich natürlich auf die Suche nach dem Problem und gab zunächst Flash die Schuld. Doch auch ein Downgrade auf eine ältere Version, eine Neuinstallation aus nicht-openSUSE-Quellen und zuletzt sogar eine Neuinstallation des Grafikkartentreibers inklusive der bereits bekannten Probleme brachten keine Besserung: Flash-Videos im Vollbild liefen mit gefühlten 0,5 fps und legten den X-Server lahm.

Da ich mir beim besten Willen nicht eingestehen wollte, dass der Prozessorumbau das Problem ausgelöst hatte, es aber logischerweise ausschließen musste, baute ich den X2 5200+ wieder ein. Und so schnell, wie es gekommen war, war das Problem auch wieder verschwunden. Erneuter Wechsel auf den X3 8750 – Stillstand.

Nach dieser letzten vernichtenden Schlacht, die mich den Tränen nahe aus dem Büro trieb und wütend gegen Wände rennen lies, war mein Wille endgültig gebrochen. Seit gestern Abend hat fglrx endgültig ausgespielt (um nicht zu sagen versch...) und ich bin zurückgekehrt zum zwar etwas langsameren, dafür jedoch deutlich problemloseren radeonhd-Treiber. AMD sollte sich für den fglrx-Pfusch schämen. Der Treiber ist unter aller Sau und für mich ab sofort ein weiterer Grund, keine Grafikkarten dieser Firma mehr zu verbauen.

Oder um es mit Robert Underdunk Terwilligers Worten zu sagen: Die fglrx, die!
Kategorien
Kategorielos

Kommentare

Seite 2 von 2 ErsteErste 12
  1. Avatar von PuckPoltergeist
    Zitat Zitat von mj
    Einfach ist es nicht, das ist richtig. Aber wenn der Nvidia-Treiber einmal installiert ist, dann läuft er. Die Probleme mit Intel kann ich nicht nachvollziehen - ich habe openSUSE auch auf dem Netbook mit Intel 945 Chipsatz installiert und kann dort sogar die Desktop-Effekte aktivieren. Das hat Intels 945 AMDs 780G also schon mal voraus.
    Du hast weder die Nvidia-Treiber noch die von Intel in "Aktion" erlebt, oder?
    Wenn der Bildschirm mit dem aktuellsten Nvidia-Treiber (stable) unter X schwarz bleibt, kann ich das nicht als problemlos bezeichnen.

    Ansonsten finde ich fglrx einfach nur erbärmlich. Deine Theorie klingt logisch - die haben es selber nicht auf die Reihe bekommen und die paar tausend Anwender waren die Investition nicht wert. Also überlässt man eben denen die Programmierung, die ohnehin schon die ganze Arbeit machen. Ein feiner Zug
    Die Theorie ist falsch. AMD entwickelt parallel sowohl den Catalyst als auch den freien Treiber. Es ist nicht wirklich so, dass AMD die Dokumentation raus schmeißt und damit die FOSS-Community alleine lässt. Ein großer Teil wird von AMD-Leuten entwickelt. Alex Deucher als radeon-Maintainer ist dafür extra von AMD angestellt worden.
Seite 2 von 2 ErsteErste 12