ATI, dich vergesse ich nie: kaum funktioniert's mal halbwegs, kommt die nächste Verschlimmbesserung und es heisst "Zurück auf Los".
Update: Einen Tag nach diesem Posting wurde Kernel 3.5.3 als stabil freigegeben - dem Changelog nach "drm/radeon: do not reenable crtc after moving vram start address" könnte sich das durchaus als relevant bei eventuell noch bestehenden Problemen (PAE+SMP?) auswirken. Bin noch am Testen - sobald ich damit fertig bin, mein funktionierendes OpenGL für bzflag-Orgien zu missbrauchen...
In diesem Falle war's ein wirklich schwieriges Problem: Meine 32bit-(PAE-)Maschine (IBM zPro, dual Xeon) begann mit sämtlichen Debian-Kernels über Version 3.0 , sowie mehr als 2GB RAM installiert waren, äusserst seltsam auf den Radeon-Treiber zu reagieren. Unverständliche Version-Mismatch-Fehler (die nur beim ersten Start des XServers auftraten) waren noch das geringste Problem. Diese lassen sich BTW durch die Zeile
radeon modeset=1
in /etc/modules beheben. Viel problematischer (neben allerhand "innovativer" Video-Effekte in bzflag und Abstürzen beim Ansehen von Flash-Videos) waren ständige Segfaults in Anwendungen mit hohem Verbrauch an Video-RAM (Firefox. RSSOwl, OOo), deren Ursache weder anhand vorhandener Lognachrichten, noch per Fehlermeldung, strace, ldd, Geisterbeschwörung oder Wünschelrutengang ermittelt werden konnte. Schadhafte Speichermodule (bei "amtlichem" Original IBM ECC-chipkill-RAM ohnehin unwahrscheinlich) wurden bereits im Vorfeld per memtest ausgeschlossen.
Ausgiebiges Googlen brachte zu Tage, dass ähnliche Fehler -auffällig war v.a. der bei Debians 3.2.0-2, nicht aber 3.2.-3(-i686-PAE) Kernel auftretende "Kernel refuses CS" Fehler- auch unter anderen Distributionen und vor allem mit ATIs R6xx GPUs auftraten und wohl mit Memory Corruption aufgrund fehlerhaft erkanntem Video- und Sideport-Memory zu tun hatten, was durch Probleme mit dem Kernel-Modesetting zu verursacht werden scheint. Eventuelle Einflüsse von Sonnenflecken, Orgonenfeldern und Polsprüngen im Magnetfeld von Alpha-Centauri sind nicht ausgeschlossen, aber bisher unerforscht; eine distributionsseitige Lösung ist anhand der Tatsache, dass dieser Bug seit Anfang 2011 immer wieder auftaucht, kaum zu erwarten.
Die Lösung brachte das -offiziell schwerstens diskreditierte- Standard-Nerd-Verfahren: einen Plain-Vanilla-Kernel, neueste Version (dato 3.5.2) direkt beim Erzeuger besorgt, ausgepackt, make oldconfig && make menuconfig und die Option DRM_RADEON_KMS unter "Device Drivers->Graphics" deaktiviert. Normalerweise ist sie (zumindest in der Debian-Konfiguration) an, obwohl in der zugehörigen Hilfedatei ausdrücklich davor gewarnt wird(!), sie zu aktivieren. Den Rest an radeonbezogener Konfig (radeon.ko, drm_BLAHFASEL.ko als Modul) kann man lassen, wie sie ist, evtl. empfiehlt es sich schon aus Zeit- und Platzgründen, Treiber für nicht benötigte Grafikkarten (voodoo, s3, sis, matrox, i915...) zu deaktivieren, wenn man schon mal dabei ist.
make-kpkg --initrd kernel_image
dpkg -i ../linux-image-3.5.*.deb
reboot
Ergebnis:
"works for me". "Works" sogar sehr gut. So gute Performance hatte ich IIRC bisher mit dem Open-Source-Treiber noch nie. Ich vermute mal, "works" für alle ATI (RS6xx/RV6xx/R6xx) GPUs ebenso.
