Mageia Forum

Hallo!

Seitdem ich über radeon-firmware meine Radeon HD 7450 problemlos zum Laufen bekommen habe, erscheint leider rechts unten immer ein äußerst aufdringliches Logo von AMD ... "AMD Unsupported hardware". Ich habe mich in den letzten Tagen dumm und dusselig gesucht. Der vielversprechendste Hinweis war, das folgende Skript ablaufen zu lassen

Code: Alles auswählen

#!/bin/sh
DRIVER=/usr/lib/xorg/modules/drivers/fglrx_drv.so
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do
 sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done


Da bei mir jedoch eine 64Bit-Installation läuft, habe ich es wie folgt geändert

Code: Alles auswählen

#!/bin/sh
DRIVER=/usr/lib64/xorg/modules/drivers/fglrx_drv.so
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do
 sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done


Leider hinterlässt mir dieses Skript immer eine korrupte Bibliothek, mit der KDE nachher (natürlich) überhaupt nicht mehr starten will.

Eine andere Lösungsmöglichkeit lag darin, die Konfigurations-Datei einer früheren (funktionierenden) Catalyst-Version "drüberzukopieren". Auch das war leider ohne Erfolg.

Frage also: Kennt jemand eine funktionierende Möglichkeit, dieses grauenhafte Overlay zu entfernen?

devnull69 hat geschrieben:Da bei mir jedoch eine 64Bit-Installation läuft, habe ich es wie folgt geändert

Code: Alles auswählen

#!/bin/sh
DRIVER=/usr/lib64/xorg/modules/drivers/fglrx_drv.so
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do
 sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done


Leider hinterlässt mir dieses Skript immer eine korrupte Bibliothek, mit der KDE nachher (natürlich) überhaupt nicht mehr starten will.

Da - wenn ich das Skript richtig verstehe - im Treiber ein CALL-Befehl mit NOPs (http://en.wikipedia.org/wiki/NOP)überschrieben wird, Adressen aber auf einem 64Bit-System entsprechend breiter sind, würde ich mal ganz braun noch zwei vier \x90 hinzufügen und schauen, ob das etwas sinnvolles bewirkt. (Und falls der Opcode auf einem 64er-System länger ist, zur Not auch mit noch einmal 1 oder 2 NOPs mehr.)

Auch in eine 64-Bit-System ist NOP x90 eine 1-Byte-Instruktion. Der Fehler wird wohl eher wo anders zu suchen sein.

alf hat geschrieben:Auch in eine 64-Bit-System ist NOP x90 eine 1-Byte-Instruktion. Der Fehler wird wohl eher wo anders zu suchen sein.

Aber das was vorher in der Datei steht, sieht anders aus.

Ja sicher, dort ist die Anweisung das Logo auszugeben und genau diese Anweisung soll durch eine andere ersetzt werden, nämlich durch den NOP ( ="no operation" zu deutsch "do nothing" ). Und das ist nunmal eine 1-Byte-Anweisung(auch bei einer 64-Bit-CPU), es macht wenig Sinn, die mehrfach anzugeben.

[es gibt durchaus auch Multibyte NOP-Anweisungen, die sehen aber anders aus und werden nicht von allen CPU unterstütz; Eine irrtümliche Verwendung könnte fatale Folgen haben http://ref.x86asm.net/coder64-abc.html]

alf hat geschrieben:Ja sicher, dort ist die Anweisung das Logo auszugeben und genau diese Anweisung soll durch eine andere ersetzt werden, nämlich durch den NOP ( ="no operation" zu deutsch "do nothing" ). Und das ist nunmal eine 1-Byte-Anweisung(auch bei einer 64-Bit-CPU), es macht wenig Sinn, die mehrfach anzugeben.

Vielleicht solltest du deine Assemblerkenntnisse des x86 mal wieder entstauben.

Hast du einen Call auf einem 32Bit-System, besteht der aus 5 Byte: 1 Byte Opcode + 4 Byte 32Bit-Adresse
Hast du einen Call auf einem 64Bit-System, besteht der aus 9 Byte: 1 Byte Opcode + 8 Byte 32Bit-Adresse

Und eine entsprechende Anzahl NOPs braucht es, da der Programcounter nach jedem NOP nur ein Byte weiter springt.
Andernfalls interpretiert die CPU Teile der Adresse als Opcode und dann rummst es natürlich.

(Andere CPU-Typen laden immer Befehle gleicher Länge, egal wie der Inhalt aussieht, nicht aber die x86.)

Die Idee fand ich auch ziemlich einleuchtend ... aber leider bekomme ich auch mit 9 Bytes (oder 6, 7, 8, 10 oder 11) kein anderes Ergebnis. Manchmal erhalte ich tatsächlich eine korrekte Bibliotheksdatei, aber das Logo bleibt hartnäckig (auch nach Neustart)

Vielleicht hilft die dort genannte, zweite Version:
http://kaibathelegacy.blogspot.de/2011/08/remove-annoying-amd-unsupported.html
Entweder pur oder mit Aufbohren der %x und x90 auf je 9 Stück.

In einem anderen Forum wird angeführt, dass sich der Patch auf die Treiber für die Serien HD 2../3../4.. beziehe.
Ob das nun bei deiner anders ist, weiß ich nicht.

Default Re: Getting rid of "AMD Unsupported Hardware" overlay message after video driver update

Quote Originally Posted by please_try_again View Post
?
If you looked at the code I posted (post #8 of the thread linked above) , that was not necessary. It was actually the point of this post.
oops

i missed the point of line
DRIVER=$(find /usr/lib*/xorg/modules/drivers -name "fglrx_drv.so" | head -1)

my focus was, this worked for the latest beta 12.6_legacy driver,
due to the thread title referred too,
and it should work for HD2000/3000/4000 series drivers

also should have referred to post
::KaibaTheLegacy::: remove annoying amd unsupported hardware logo in Linux

thx again

http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/476725-getting-rid-amd-unsupported-hardware-overlay-message-after-video-driver-update.html

Hi,

schau mal in diesen Link, im Forum dort wurde das Problem als "gelöst" beschrieben:

http://forum.ubuntuusers.de/topic/howto ... gx-propri/

man-draker hat geschrieben:Und eine entsprechende Anzahl NOPs braucht es, da der Programcounter nach jedem NOP nur ein Byte weiter springt.
Andernfalls interpretiert die CPU Teile der Adresse als Opcode und dann rummst es natürlich.

Ich bin eigentlich davon augegangen, dass das oben angegeben Script genau das macht, oder irre ich mich da?

alf hat geschrieben:

man-draker hat geschrieben:Und eine entsprechende Anzahl NOPs braucht es, da der Programcounter nach jedem NOP nur ein Byte weiter springt.
Andernfalls interpretiert die CPU Teile der Adresse als Opcode und dann rummst es natürlich.

Ich bin eigentlich davon augegangen, dass das oben angegeben Script genau das macht, oder irre ich mich da?

Du irrst dich nicht, wenn du davon ausgehst, dass das Programm den gesamten Platz des Call-Befehls inkl. Zieladresse mit NOPs füllt. Du irrst dich aber, wenn du denkst, dass die breitere Adresse im Call-Befehl auf einem 64Bit-System für die Anzahl der NOPs keine Rolle spielt.

Code: Alles auswählen

344dce:   e8 ad e2 fd ff          callq  323080 <atiddxEnableLogo@plt>

das wäre die fragliche Zeile, wo bitte willst du da mehr als 5 NOPs unterbirngen?

ps:

Vielleicht solltest du deine Assemblerkenntnisse des x86 mal wieder entstauben.

den Satz solltest du freundlicher Weise auch besser streichen.

alf hat geschrieben:

Code: Alles auswählen

344dce:   e8 ad e2 fd ff          callq  323080 <atiddxEnableLogo@plt>

das wäre die fragliche Zeile, wo bitte willst du da mehr als 5 NOPs unterbirngen?

Hm, wenn sie tatsächlich den Treiber im 32Bit-Modus auf einem 64Bit-System laufen lassen, dann ist das so.

ps:

Vielleicht solltest du deine Assemblerkenntnisse des x86 mal wieder entstauben.

den Satz solltest du freundlicher Weise auch besser streichen.

Warum? Du hast doch...

Leider ist das Ausgangsproblem damit noch nicht gelöst.

Nein, gelöst ist das Problem damit nicht.

Der Hinweis hat mich aber dazu gebracht, mal genauer nachzuforschen

Code: Alles auswählen

objdump -d /usr/lib64/xorg/modules/drivers/fglrx_drv.so | grep EnableLogo


ergibt

Code: Alles auswählen

00000000003b5820 <atiddxEnableLogo@plt>:
  3dad4f:       e8 cc aa fd ff          callq  3b5820 <atiddxEnableLogo@plt>
  402b01:       e8 1a 2d fb ff          callq  3b5820 <atiddxEnableLogo@plt>
  40d8af:       e8 6c 7f fa ff          callq  3b5820 <atiddxEnableLogo@plt>
  435ac1:       e8 5a fd f7 ff          callq  3b5820 <atiddxEnableLogo@plt>
  4407ef:       e8 2c 50 f7 ff          callq  3b5820 <atiddxEnableLogo@plt>
  468a01:       e8 1a ce f4 ff          callq  3b5820 <atiddxEnableLogo@plt>
  47372f:       e8 ec 20 f4 ff          callq  3b5820 <atiddxEnableLogo@plt>
  49b701:       e8 1a a1 f1 ff          callq  3b5820 <atiddxEnableLogo@plt>
  4a642f:       e8 ec f3 f0 ff          callq  3b5820 <atiddxEnableLogo@plt>
  4ce1b1:       e8 6a 76 ee ff          callq  3b5820 <atiddxEnableLogo@plt>
  4d8eef:       e8 2c c9 ed ff          callq  3b5820 <atiddxEnableLogo@plt>
  500c71:       e8 aa 4b eb ff          callq  3b5820 <atiddxEnableLogo@plt>
0000000000515860 <atiddxEnableLogo>:
  51587e:       74 50                   je     5158d0 <atiddxEnableLogo+0x70>
  51588b:       74 43                   je     5158d0 <atiddxEnableLogo+0x70>
  515896:       74 38                   je     5158d0 <atiddxEnableLogo+0x70>
  5158a0:       75 14                   jne    5158b6 <atiddxEnableLogo+0x56>
  5158b4:       74 1a                   je     5158d0 <atiddxEnableLogo+0x70>
  5159f3:       e8 28 fe e9 ff          callq  3b5820 <atiddxEnableLogo@plt>
  515af1:       e8 2a fd e9 ff          callq  3b5820 <atiddxEnableLogo@plt>


Also haben die call Anweisungen (auch bei mir auf dem 64-Bit-System) offenbar nur 5 Bytes. Aber das unveränderte Skript (siehe oben) hinterlässt trotzdem eine ungültige SO Bibliothek ...

Weitere Nachforschungen haben ergeben, dass das Skript offenbar gar nicht "so schlecht" läuft. Lediglich beim allerletzen Schleifendurchlauf hinterlässt es eine korrupte Datei. Also bin ich in den "manuellen Debug-Modus" gewechselt und habe die Schleifenteile Schritt für Schritt ausgeführt

Code: Alles auswählen

objdump -d /usr/lib64/xorg/modules/drivers/fglrx_drv.so |awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'

\xe8\xcc\xaa\xfd\xff
\xe8\x1a\x2d\xfb\xff
\xe8\x6c\x7f\xfa\xff
\xe8\x5a\xfd\xf7\xff
\xe8\x2c\x50\xf7\xff
\xe8\x1a\xce\xf4\xff
\xe8\xec\x20\xf4\xff
\xe8\x1a\xa1\xf1\xff
\xe8\xec\xf3\xf0\xff
\xe8\x6a\x76\xee\xff
\xe8\x2c\xc9\xed\xff
\xe8\xaa\x4b\xeb\xff
\xe8\x28\xfe\xe9\xff
\xe8\x2a\xfd\xe9\xff


Daraufhin habe ich in dieser Zeile

Code: Alles auswählen

sed -i "s/$x/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so


das $x durch die einzelnen Ausgaben von "awk" ersetzt und nach jedem Schritt mit "objdump" das Ergebnis geprüft. Alles war prima (incl. der NOP \x90) ... nur nicht beim letzten Schritt. Danach gibt "objdump" nur noch "File format not recognized" aus. Da die Kombination von awk und sed die Anweisungen ja global (und nicht gezielt bei EnableLogo) ersetzt, kann ich mir das sogar erklären. Kann ich irgendwie erreichen, dass ich nur die konkrete Anweisung ersetze?

BINGO!

Die Lösung war, die Schleife aufzulösen und alle bis auf den letzten Schleifendurchgang manuell auszuführen. Nach einem Neustart gibt's dann kein Logo mehr!

Gehackt!


Zusammenfassung:

Code: Alles auswählen

sed -i "s/\xe8\xcc\xaa\xfd\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\x1a\x2d\xfb\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\x6c\x7f\xfa\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\x5a\xfd\xf7\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\x2c\x50\xf7\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\x1a\xce\xf4\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\xec\x20\xf4\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\x1a\xa1\xf1\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\xec\xf3\xf0\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\x6a\x76\xee\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\x2c\xc9\xed\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\xaa\x4b\xeb\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so
sed -i "s/\xe8\x28\xfe\xe9\xff/\x90\x90\x90\x90\x90/g" /usr/lib64/xorg/modules/drivers/fglrx_drv.so


und Neustart.