AMD und die Grafik...

29/04/2012 - 22:28 von Sieghard Schicktanz | Report spam
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
 

Lesen sie die antworten

#1 Andreas Hartmann
30/04/2012 - 07:57 | Warnen spam
Sieghard Schicktanz schrieb:
Hallo beinand'



[...]
lspci -nn listet die so:
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices
nee ATI BeaverCreek [Radeon HD 6530D] [1002:964a]

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.



nicht überraschend.

[...]

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?



Falsche Distri :-). Hàttest mal openSUSE verwendet, hàttest Dir viel
Zeit erspart. Siehe:

http://www.sebastian-siebert.de/201...tallieren/


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.



Bekannt. Reife Leistung von Torvalds:

http://www.sebastian-siebert.de/201...tallieren/

[...]

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



Auch bekannt :-).

[...]

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),



fglrx unterstützt kein kms - das muß explizit abgeschaltet sein. V.a.
auch in der initrd (das wird manchmal vergessen).

[...]

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.



Du beschimpfst die Falschen ... .

Ähnlich làuft's scheint's bei Xorg, da sind's dann wohl eher
die Juristen, die das letzte Wort haben...




Gruß,
Andreas

Ähnliche fragen