AMD und die Grafik...

Hallo beinand'

so, damit wär' so ziemlich die letzte Hürde beim Umbau meiner Kiste auf die
neue Hauptplatine genommen.
Nachedem mit "tatkräftiger Mithilfe" von grml EFI beigegeben und einen
Boot-Eintrag zugelassen hat, war im wesentlichen noch eine Baustelle die
neue Grafik-, naja, nicht -Karte, sondern schon integriert. Eine AMD-Ati,
aus der Radeon-Reihe, die vor langen Jahren mal bei München am Starnberger
See ihren Ursprung genommen hat... ;-)

lspci -nn listet die so:
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]
Nett, nicht? Vor allem das "née";-)

Der erste Ansatz mit dem Radeon-Treiber im Kernel hat bei Xorg nur den
VESA.Treiber angesprochen, der Radeon-Treiber mochte nicht. Auch nicht nach
diversen Überredungsversuchen, es blieb bei VESA.
Aber es gibt da doch den schönen originalen Hersteller-Treiber mit dem
dekorativen Namen "fglrx". Der soll sogar schon diesen Chip unterstützen,
und das sogar im Kernel im Textmode. Also holen und ...

Ja, holen - Arch bietet den nicht an, also vom Hersteller. Der ist da sogar
zu finden, und sogar für mein (immer noch) 32-bittiges System. Nach
Runterladen ans Kompilieren gehen - geht nicht. Na schön, er stört sich am
Radeon-Treiber im Kernel. Also 'runter in'n Textmode, Radeon nicht
mitgeladen, neu versucht. Geht nicht - Fehler beim Kompilieren. Es fehlt
ein Symbol, "TS_USEDFPU". Häh?

Also Suche danach - jibtsnich. Was soll das?
Also internet - doch, das Problem ist schon bekannt, das Symbol gibt's
nicht bei den neueren Kerneln, nicht mehr bei meinem (inzwischen) 3.3er.
Und es gibt sogar einen Patch, zwei Patches, und einen dritten, der den
zweiten automatisiert.

Ja, aber wie einbauen? Patch während der Bearbeitung anwenden geht nicht -
das File ist geändert, aber benutzt wird trotzdem das unveränderte!? Kann
doch nicht sein - Sucherei - jawashamdiedenn da gemacht? Da wird zwar das
ganze Archiv schön in ein Zwischenverzeichnis entpackt, aber _garbeitet_
wird dann aus einem ganz _anderen_ Verzeichnis! Das steck im Modul-
Verzeichnis und bleibt dort auch liegen, aber Hinweis drauf gibt's im
Installationsprozess keinen, nichtmal im ausgegebenen Log...

Nagut, dann erstmal Verfahrensmöglichkeit gesucht, den Installationsprozess
zu übertölpeln - es gibt die Option, das Archiv nur zu entpacken, dort kann
dann gepatcht werden. Es gibt dann aber keine Option, das von dort zu
kompilieren - sehr schlau ausgedacht. Man muß sich da erstmal das
zuständige Skript im Shell-Archiv suchen (ati-installer.sh), seine
Parameter ausfindig machen und decodieren (es möchte als erstes die
Versionsnummer - nicht die, dieim Namen steht, sondern die des Treibers
selber - und dann die Aktion), dann kann das Kompilieren laufen. Damit
geht's dann, aber bevor alles fertig ist, muß noch in einem weiteren
Verzeichnis ein Installationsskript aufgerufen werden - _das_ steht
allerdings sogar direkt im Kompilier-Log.

Danach ist derTextmode kaputt. D.h. die Auflösung stimmt nicht mehr für
meinen Monitor (1600x1200), es wird nur in 1280x1024 angezeigt und läßt sich
in keiner Weise beeinflussen. Unschön. Naja, der Aufwand war ja auch für
X11 gedacht, also testen. Nach einigem Probieren, weil sich der Xorg-Server
reichlich ziert, das Ergebnis: geht nicht.
Nagut, wir haben ja noch einen anderen Patch. Probiert, selbiges Ergebnis:
_Es geht nicht_.

Also wieder VESA eingebaut (inzwischen ist die Xorg-Konfiguration für die
Tests so flexibilisiert, daß da nur noch eine Datei zu kopieren ist;), und
wieder im internet gesucht. Ja, auch _der_ Fehler ist bekannt, aber nur in
ganz anderen Zusammenhängen, mit kdm und so, was ich nicht habe.
Aber da gibt's auch noch einen Bug-Report, der genau mein Problem enthält,
und da gibt's ein paar Kommentare, die die Ursache diskutieren: Xorg.
Xorg hat mal wieder am Server gedreht und eine Inkompatibilität eingebaut,
ab Version 1.12 funktioniert der fglrx-Treiber nicht mehr, er steigt mit
einem "signal 11 (Segmentation fault)" aus. Mit der Vorversion soll's noch
gegangen sein...
Und ich hatte grade alles für das neue Brett "upgedatet" - hicks
('tschullng, bei dem Ausdruck muß ich immer aufstoßen;).

Naschön, kann man ja mal probieren - also alten X-Server wieder reaktiviert.
Ja, was der so alles mitzieht... Aber schließlich ist alles vorhanden und
konsistent, und jetzt noch den flglrx "einladen" - und er kommt!

Funktioniert also alles, nach kaum ein paar Tagen 'rumwerkeln an diversen
Systemfehlern und -inkonsistenzen läßt sich auch ein Linux mit X11 auf
einem aktuellen Mainboard mit AMD-Ati-Grafik richtig betreiben!

Zwar geht die Textmode-Darstellung nicht richtig, KMS wird da großzügig
ignoriert (aber vorausgesetzt), aber unter X11 funktioniert die Karte.
Man darf nur keinen Xorg-Server >= 1.12 benutzen und muß der Treiber-
Installation hinterlistig den _richtigen_ Patch unterschieben, den nämlich,
der die drei Zeilen in der Funktion mit dem Symbol "TS_USEDFPU", die für
32-Bit-Systeme sein sollen, durch zwei andere, ähnliche Zeilen ersetzt. (Der
andere Patch, der einfach die gleiche Funktion wie bei 64-Bit-Systemen
einfügt, funktioniert bei mir _nicht_.)

Alles ganz einfach. Wenn man weiß, wie man's machen muß.
Aber trotzdem furchtbar unnötig umständlich, und obwohl die Fehler bekannt
sind, wurde nicht mal bei der während der o.g. Aktivitäten erschienen
_neuen_ Version des fglrx von AMD das Problem beseitigt. Aber deren
Entwickler haben anscheinend keinen internet-Zugang, das machen dort wohl
die Kaufleute. Ähnlich läuft's scheint's bei Xorg, da sind's dann wohl eher
die Juristen, die das letzte Wort haben...

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
.

Relevant Pages

  • Re: Nautilus Absturz
    ... verschwindet der Desktop und kommt nach einer Weile ... nicht unbedingt den CVS code, ... Die Quellen zum kompilieren bekommen und Dev-Header sind dank Gentoo ... Auch den Bug zu finden und einen Patch zu ...
    (de.comp.os.unix.apps.gnome)
  • Re: Splashscreen in Maverick Meerkat installieren?
    ... Die erste heisst Kernel ... patchen + selbigen neu kompilieren. ... Dazu brauchst du den passenden Patch ...
    (de.comp.os.unix.linux.misc)
  • Re: Installation opensuse 10.2
    ... Naja, bisher kenne ich dazu nur deine Behauptung, dass dieser Patch ... einem Patch für einen einigermaßen aktuellen Kernel und einer Anleitung, ... wie ich das wirklich "GNU-frei" kompilieren kann. ...
    (de.comp.os.unix.linux.hardware)