AMD Catalyst 12.2 (fglrx 8.950) wurde veröffentlicht. Das Skript makerpm-amd-12.2.sh steht ab sofort zum Download zur Verfügung und unterstützt 11.4 und 12.1.
[UPDATE 25.03.2012]
Das nächste Update vom Skript behebt einen weiteren Kompilierungsfehler beim Bauen eines fglrx-Kernelmoduls auf einem Kernel 3.3 und höher.
Im Wortlaut:
error: 'struct thread_struct' has no member named 'has_fpu'
Linus Torvalds hat es geschafft zum Leidwesen aller Kernel-Nutzer die betreffende Stelle im Git-Repo von Linus Torvalds innerhalb von wenigen Tagen für Kernel 3.3+ nochmal umzubauen, so dass der vorhergehende Patch (wegen TS_USEDFPU) vom 09.03.2012 erneut kaputt gegangen ist. Da sage ich doch mal, herzlichen Glückwunsch. Da braucht man sich nicht zu wundern, dass der Quellcode eines Kernelmoduls von Dritten irgendwann unleserlich wird, weil man versucht die gleiche Funktion für alle (halbwegs aktuellen und vor allem betreuten) Kernelversionen abzudecken. 
[/UPDATE 25.03.2012]
[UPDATE 09.03.2012]
Das Packaging Skript wie auch das makerpm-amd-Skript wurden aktualisiert. Es behebt einen Kompilierungsfehler vom fglrx Kernelmodul auf einem 32bit System, weil ab Kernel 3.2.9 und höher die Konstante TS_USEDFPU entfernt und die Funktion dahinter umgeschrieben wurde. Ich habe über den genannten Fehler im Netz recherchiert und eine Information der Kerneländerung im Git-Repo von Linus Torvalds gefunden. Daraus habe ich einen Patch entwickelt und diesen auch an die AMD-Entwickler zwecks Prüfung geschickt. AMD hat sich das Patch angeschaut und hat ihn als akzeptabel eingestuft und nimmt ihn mit meiner Erlaubnis in den fglrx Quellcode auf. Vielen Dank an dieser Stelle nochmal an Rudolfo Patella für den Hinweis auf diese Problematik.
[/UPDATE 09.03.2012]
AMD hat diesmal etwas verspätet den Treiber veröffentlicht. Der Grund lag einzig daran, dass AMD die Treiber-Version 8.94 wegen möglicher Treiber-Probleme mit einigen Grafikkarten übersprungen hat. Außerdem habe ich das Packaging Skript aktualisiert, weil AMD leider meine Änderung nicht in ihren AMD Installer reingepackt hatte. (Vergessen? Kein Zeit? Wer weiß… Zumal die geschlossene AMD Mailingliste auch ausgefallen war. 
) Es betrifft einmal den atieventsd.sh Init-Skript. Dort wurde für den Start des Skriptes im Runlevel 3 angegeben und zugleich das XDM (X Window Manager) vorausgesetzt, was IMHO keinen Sinn macht. Andererseits ist das Powermode-Skript (ati-powermode.sh) endgültig rausgeflogen. Da der Treiber bereits den Suspend-Modus unterstützt und kein Hilfsskript mehr benötigt.
Der Treiber unterstützt jetzt auch AMD Radeon HD 7950, HD 7970, HD 7990.
Downloads:
- Skript: makerpm-amd-12.2.sh
- SHA1: makerpm-amd-12.2.sh.sha1
Installationsanleitung:
http://de.opensuse.org/SDB:AMD/ATI-Grafiktreiber#Installation_via_makerpm-ati-Skript
Über das makerpm-amd-Skript
Das Skript makerpm-amd-12.2.sh ist sehr mächtig, robust und läuft vollautomatisch. Der AMD-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf Wunsch wird nach dem Bau des RPM-Packages der fglrx-Treiber installiert.
Folgende Argumente können dem Skript übergeben werden:
| -b | Nur das RPM-Package bauen (Standard) |
| -c <type> | Nur X-Server konfigurieren. Monitor-Typ: single = 1 Monitor, dual = 2 Monitore (Wichtig: Nur ausführen, wenn es Probleme mit der Standardkonfiguration des X-Servers auftreten) |
| -d | Nur den ATI-Installer downloaden |
| -i | Das RPM-Package bauen und installieren bzw. updaten |
| -kms <yes|no> | Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren |
| -nohw | Hardware-Erkennung explizit ausschalten. (z.B. beim Bau in einer VM) |
| -old2ddriver <yes|no> | den alten 2D-Treiber aktivieren oder deaktivieren |
| -r|–report | erstellt ein Report und speichert diese in eine Datei namens ati-report.txt |
| -u|–uninstall | entfernt AMD Catalyst restlos vom System. Zuerst wird das fglrx-Package (falls vorhanden) vom System deinstalliert. Danach werden vorhandene ATI-Dateien und -Verzeichnisse entfernt. Hinweis: Falls das Rebuild-Skript installiert wurde, wird es ebenfalls entfernt und das Initskript /etc/init.d/xdm wiederhergestellt. |
| -ur|–uploadreport | wie Option –report nur zusätzlich wird der Report auf einem NoPaste-Service sprunge.us hochgeladen und gibt bei Erfolg den Link zurück. |
| -h | Die Hilfe anzeigen lassen |
| -V | Version des Skript anzeigen |
Hilfe, es funktioniert nicht!
Bitte haltet folgende Regel ein:
- Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
- Möglicherweise ist die Lösung für das Problem im Wiki vorhanden.
- In Kommentaren lesen, ob eine Lösung zu einem Problem bereits existiert.
Wenn keines der o.g. Regel greift, dann könnt ihr mit eurem Anliegen an mich wenden. Damit ich euch helfen kann, müsst ihr erst vorarbeiten. Bitte ladet euch das Skript makerpm-amd-12.2.sh herunter und erstellt einen Report von eurem System in der Konsole:
su -c 'sh makerpm-amd-12.2.sh -ur'
Das Skript lädt das Report auf sprunge.us hoch und gibt anschließend einen Link aus. Diesen Link postet ihr in eurem Kommentar zusammen mit einer Beschreibung zu eurem Problem an mich. Ich werde mir euren Report anschauen und Hilfestellung geben, wo evtl. das Problem liegen könnte.
Feedbacks sind wie immer willkommen. 
Hm, klappt hier nicht. Angeblich wird meine Grafikkarte nicht unterstützt. Die Installation bricht mit folgender Fehlermeldung ab:
ups! Und hier die Fehlermeldung:
cat: VI/amd-12.2-tmp.6bTle/common/lib/modules/fglrx/build_mod/fglrxko_pci_ids.h: Datei oder Verzeichnis nicht gefunden
02:00.0 VGA compatible controller [0300]: ATI Technologies Inc Cedar PRO [Radeon HD 5450] [1002:68f9]
Error: This graphics card is not supported by AMD Catalyst 12.2 [ FAILURE ]
Hallo Edgar,
kannst du bitte das Skript in einem anderen Verzeichnis ausführen. Scheinbar konnten nicht alle Dateien entpackt werden. Ich hoffe nicht, dass dein Dateisystem defekt ist.
Gruß
Sebastian
Hi Sebastian,
danke für die schnelle Antwort. Ich habe das Script jetzt in einem anderen Verzeichnis ausgeführt, und da klappt’s dann auch. Werde dann mal ein bisschen testen….
Hi Sebastian,
ich habe seit letzter Woche von 3.2.8 auf „Linux version 3.2.9-13“ umgestellt und danach lief der fglrx-Treiber nicht mehr. Ich versuchte Catalyst 12.1 neu zu installieren und bekam dabei die Fehlermeldung das das Symbol „TS_USEDFPU“ nicht definiert ist. Ich hatte gehofft, das es jetzt mit Catalyst 12.2 wieder geht. Leider ist dem nicht so. Hier der Log-Report von Deinem “ makerpm-amd-12.2.sh“-File:
Wie gesagt, diese Meldung kommt seit dem ich „Kernel 3.2.9“ benutze, mit den Vorgängerversionen lief es einwandfrei.
Mfg.Rudolfo
Hallo Rudolfo,
vielen Dank für den Hinweis auf den Fehler. Ich habe daraus ein Patch entwickelt und ihn in den Packaging Skript aufgenommen. Einfach nochmal das Skript herunterladen und das Paket nochmal bauen und installieren lassen. Mehr Informationen zu diesem Thema habe ich oben im Artikel hinzugefügt.
Gruß
Sebastian
Hallo Sebastian,
kurze Rückmeldung. Jetzt läuft es wieder einwandfrei. Vielen Dank für den schnellen Support.
Mfg.
Rudolfo
Hallo Sebastian,
hat leider nicht geklappt – sieh selbst …
Check for running this script as root … [ OK ]
Remove the unneeded old rebuild script … [ OK ]
Check for existing AMD-Installer „amd-driver-installer-12-2-x86.x86_64.run“ in current directory … [ MISSING ]
Download the AMD-Installer …
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 102M 100 102M 0 0 1624k 0 0:01:04 0:01:04 –:–:– 1632k
[ OK ]
Compare SHA1 checksum of the AMD-Installer … [ OK ]
Check for existing packaging script tarball „amd-12.2-packaging-script.tar.bz2“ in current directory … [ MISSING ]
Download the packaging script tarball „amd-12.2-packaging-script.tar.bz2“ …
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 24254 100 24254 0 0 148k 0 –:–:– –:–:– –:–:– 149k
[ OK ]
Compare SHA1 checksum of the packaging script tarball „amd-12.2-packaging-script.tar.bz2“ … [ FAILURE ]
offensichtlich stimmt sha Prüfsumme nicht
– was kann ich tun – ich könnte auf die Prüfung verzichten – mit ein wenig Bauchschmerzen würde ich das vielleicht sogar – wichtig ist, ich brauche dringend schnelle Antwort …
Grüße von
Harald Knupp
CROW
LPIC2 certifiziert
Hallo Harald,
bitte einmal das Skript inkl. Prüfsumme löschen und nochmal herunterladen. Ich habe das Packaging Skript wie auch das makerpm-amd-Skript soeben aktualisiert. Das hat sich gerade mit deinem Download überschnitten.
Gruß
Sebastian
Hi Sebastian,
sorry für mein schlechtes Timing;)
Gruß Crow
Hi Sebastian,
ich war mal wieder zu schnell … vielen Dank für die rasche Antwort – das ging wirklich sehr fix – großes Lob und was für ein „timeing“
Gruß
CROW
Hi Sebastian,
habs ausprobiert in Runlevel 5 – Ergebnis:
Summary report: ================================================================================ Kernel => 3.1.9-1.4-debug Detected => RPM package Build => [ FAILURE ] Install => [ FAILURE ] Kernel => 3.1.9-1.4-desktop Detected => RPM package Build => [ OK ] Install => [ OK ] ************************************************************** Building/installation of fglrx kernel module failed! Try again by calling "/usr/bin/fglrx-kernel-build.sh" manually. ************************************************************** ************************************************************* Please read "/usr/share/doc/packages/fglrx/README.SuSE" for configuration details when using SaX2. ************************************************************* Disable KMS to prevent driver issue: Scanning scripts ... Resolve dependencies ... Install symlinks in /lib/mkinitrd/setup ... Install symlinks in /lib/mkinitrd/boot ... Kernel image: /boot/vmlinuz-3.1.9-1.4-debug Initrd image: /boot/initrd-3.1.9-1.4-debug Root device: /dev/disk/by-id/ata-ER-M2S_easyRAID_V.36.M02-part2 (/dev/sdb2) (mounted on / as ext3) /usr device: /dev/disk/by-id/ata-ER-M2S_easyRAID_V.36.M02-part9 (/dev/sdb9) (mounted on /usr as ext3) Resume device: /dev/disk/by-id/ata-ER-M2S_easyRAID_V.36.M02-part3 (/dev/sdb3) Kernel Modules: hwmon thermal_sys thermal processor fan pata_marvell ata_generic rtc-cmos usbcore ohci-hcd uhci-hcd ehci-hcd hid usbhid Features: acpi block usb resume.userspace resume.kernel Bootsplash: openSUSE (1600x1200), openSUSE (1920x1080) Kernel image: /boot/vmlinuz-3.1.9-1.4-desktop Initrd image: /boot/initrd-3.1.9-1.4-desktop Root device: /dev/disk/by-id/ata-ER-M2S_easyRAID_V.36.M02-part2 (/dev/sdb2) (mounted on / as ext3) /usr device: /dev/disk/by-id/ata-ER-M2S_easyRAID_V.36.M02-part9 (/dev/sdb9) (mounted on /usr as ext3) Resume device: /dev/disk/by-id/ata-ER-M2S_easyRAID_V.36.M02-part3 (/dev/sdb3) Kernel Modules: thermal_sys thermal processor fan pata_marvell ata_generic Features: acpi block usb resume.userspace resume.kernel Bootsplash: openSUSE (1600x1200), openSUSE (1920x1080) Check: No fglrx section. Uninitialised file found, configuring. Switch to AMD Switch to AMD speichernCommitResult (total 1, done 1, error 0, skipped 0, updateMessages 0) [ OK ] Check for activated fglrx rebuild init script ... Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. [ OK ] Finish! Please restart your computer and have a lot of funich werd mal neustarten und testen ob alles gut läuft
Bis später dann mal
Gruß
CROW
hat alles bestens geklappt , vielen dank , aber mal ne andere frage , ich hab mit der 12.1. mein system vollig neu aufgesetzt , was ja nu nicht so lange her ist und trotz meiner sparsamen programminstallation lauf ich auf gute 9 gb zu …….kann man da irgendwie mal ,,aufräumen,,…;)
In Zeiten von TeraBytes „beschwerst“ Du Dich über 9 GB?
Mein Suse ist mittlerweile 3 Jahre alt und hat stattliche 60GB ohne /home.
Aber wenn Du unbedingt aufräumen willst….
hin und wieder mal als su /tmp löschen… das wird bei suse immer noch nicht automatisch gemacht. Deshalb hab ich /tmp auch im RAM. Dazu einfach folgendes in /etc/fstab eintragen:
tmpfs /tmp tmpfs rw,mode=1777 0 0
Aber nur wenn Du viel RAM hast (mind. 4GB, besser 8). Nach einem Neustart ist /tmp dann automatisch geleert.
Wenn du viele fotos anschaust, kannst du hin und wieder auch mal die thumbs löschen, unter: /home/user/.thumbnails/.
Dann müssen die Vorschauen für dolphin & co beim nächsten besuch des photo-ordners aber neu berechnet werden.
Hallo Thomas,
in der Regel hast du recht und wegen der heutigen Festplattengröße muss man sich keine Gedanken um die paar Gigabytes machen. Anders sieht es aus, wenn lux11 noch eine ältere SSD-Festplatte verwendet, die gerade mal 16 Gigabyte groß ist. Da zählt jedes Megabyte. Kurz: Wir wissen nicht wie groß seine Festplatte bzw. die Partition ist und wie die Hardwarekonfiguration bei ihm aussieht. Meine Glaskugel muss ich auch nicht herausholen und wild darauf los spekulieren.
Gruß
Sebastian
Es ist nicht ganz richtig, dass Suse die Temp-Odner nicht automatisch löscht. Suse macht es nicht von sich aus, man muss es erst in den Cron-Jobs einstellen, aber dann macht Suse es automatisch.
Mache ich seit 11.1 so und hatte noch nie Anlass zur Klage.
Pingback: openSUSE: neues aus dem “SuS(i)E-Land” … die zweite! | Lisufa' s Blog
Hallo Sebastian,
seit dieser Version kann man wieder weitere X-Sessions (zumindest so viele, wie ich benötige), ohne Fehler anlegen (mit HD 6570). Das Problem seit 11.6 Scheint also bereinigt zu sein (ich hoffe mal, daß es kein Zufall ist).
Die Hardwaredekodierung von mpeg-Files (ISO Media, MPEG v4 system, version 2) via libva funktioniert hier auch wieder.
Gruß,
Stefan
Hallo Stefan,
danke für dein Feedback. Du hast ja Ende Januar/Anfang Februar den Fehler bei mir berichtet. Hierzu hatte ich einen Bugreport direkt an AMD weitergegeben, dass die Entwickler sich das mal anschauen sollen. Anscheinend haben sie den Fehler einkreisen und auch beheben können.
Gruß
Sebastian
Schade, dass Gnome 3.2-Shell immer noch in unregelmäßigen Abständen und ohne erkennbare Auslöser abstürzt und neu startet. Muss auf meinem Produktivsystem daher weiter mit dem freien Treiber arbeiten.
Hallo Edgar,
hast du folgenden Workaround mit dem installierten AMD Catalyst Treiber ausprobiert?
In der Konsole als root ausführen:
Danach den Computer neustarten.
Gruß
Sebastian
Hallo Sebastian,
nee, hatte ich noch nicht. Jetzt aber. Mal sehen, was draus wird.
Danke!
Edgar
Hallo Sebastian,
der Workaround funktioniert — ein bisschen. Die Intervalle zwischen den Abstürzen/Neustarts der Shell sind erheblich länger geworden und damit auch deren Häufigkeit wesentlich geringer. So ganz aus der Welt geschafft sind sie dennoch nicht. In den vergangenen vier Stunden hatte ich immerhin noch zwei.Betroffen scheinen außer mir noch viele weitere Gnome 3.x -User. Den Verdacht legen zumindest die diversen Beiträge in Mint-, Ubuntu- und anderen Foren nahe.
Hi Sebastian,
bei mir bricht die Installation, bzw das bilden der Pakete mit dieser Fehlermeldung ab:
create archive failed on file /usr/src/packages/BUILDROOT/fglrx64_xpic_SUSE121-8.950-2.x86_64/usr/lib64/xorg/modules/glesx.so: cpio: Bad magic
Package build failed!
Downloads (makerpm und checksumme) sind von Heute
Gruß Herbert
hm…:
beim 3. Anlauf hat es jetzt scheinbar geklappt mit der Installation…
mal sehen ob das system auch wieder hoch fährt.
Gruß Herbert
Hi,
System fährt hoch… was das wiedr war?
2x die oben genannte Fehlermeldung, beim 3. Versuch läufts ohne dass ich was anders gemacht habe als vorher
Gruß Herbert
Hallo Sebastian,
ich kann hier zuverlässig X aufhängen (belegt dann eine komplette CPU), indem ich während einem flash-Vollbildvideo den Monitor in Standby schalte. Der Film läuft weiter (Ton) und auch via SSH ist die Büchse noch erreichbar. Sobald ich den X-Prozeß dann kille (kill -9), steht die ganze Büchse.
Ist Dir das Problem bekannt? Kannst Du es nachvollziehen bei Dir oder ist das evtl. ein spezielles Feature bei mir? Oder ist es ein X- bzw. flash-Problem? Mit vlc habe ich in dieser Situation jedenfalls keine Probleme.
Radeon HD 6570
xorg-x11-server-7.6_1.9.3-15.26.1.x86_64
flash 11.1 r102 (64bit)
linux 3.1.10
Danke!
Gruß,
Stefan
Hallo Stefan,
wie schafft man es einen Monitor manuell in den Standby-Betrieb zu setzen, während Flash im Vollbildmodus läuft??? Ich habe es hier anders simuliert und habe bei der Energieverwaltung die Monitor-Abschaltung heruntergestellt. Jedoch konnte ich ohne Problem den Monitor via Mausbewegung oder Tastendruck wieder reaktivieren. Daher kann ich dein Problem anderweitig nicht reproduzieren.
Gruß
Sebastian
Hallo Sebastian,
Danke für Deinen Test. Ich habe das natürlich nicht aktiv eingegeben während dem Vollbildmodus
(wobei das remote über SSH und xset durchaus gehen sollte), sondern genauso, wie Du es intuitiv getestet hast.
xset q
…
DPMS (Energy Star):
Standby: 180 Suspend: 240 Off: 300
DPMS is Enabled
Monitor is On
…
Also ist es schonmal kein grundsätzliches Problem, sondern entweder HW-spezifisch oder Kernel- oder X-spezifisch (wenn ich mich richtig erinnere fährst Du ja openSUSE 12.1). Mal schauen, wo ich eine andere X-Server-Version her bekomme.
Danke!
Gruß,
Stefan
Hallo,
ich habe es mit diesem Script versucht aber leider gibt es immer irgendwelche Fehler beim builden des Kernels, ich habe den Report erstellt auf: http://sprunge.us/QFdc
aber Kernel-source etc habe ich alles installiert
Hallo Frank,
die Kernel-Quellen hast du schon mal installiert. Das ist sehr gut. Nur übersieht man gerne wie man schön im Report nachlesen kann, dass die Kernel-Quellen mit dem laufenden Kernel nicht übereinstimmt.
Bitte einmal das Kernel-Paket „kernel-desktop“ von der Version 3.1.0 auf 3.1.9 aktualisieren und der Spuck ist vorbei.
Gruß
Sebastian
Danke das hat nicht nur funktioniert sondern auch ein anderes Problem gelöst, ich versuche schon seit einer weile mit verschiedenen Methoden diesen Treiber zu installieren, mein Notebook hat aber noch einen Intel Grafikship und es hatte vorher nicht geklappt.
Ist es eigentlich richtig so, dass nach der Installation dieses Treibers in den KDE Systeminformationen, als Hersteller: Intel Corporation steht?
und nur als 2D Treiber: fglrx steht und nichts von 3d?
Wenn ich die andere Karte aktiviere (über das AMD Tool) dann steht da zwar auch Intel als Hersteller und der gleiche 2D Treiber aber es ist immerhin noch ein Fragezeichen hinter der 3d Treiber Information zu sehen.
fgl_glxgears mit beiden Karten ausgeführt deutet aber darauf hin, dass die Karten korrekt gewechselt werden.
Hallo Frank,
die Systeminformationen von KDE 4.7.2 unter openSUSE 12.1 ist leider ungenau. Es kann wegen der internen Namensänderung des Treibers nicht den richtigen 3D-Treiber ermittelt werden. Ich habe vor einiger Zeit ein Patch für kio_sysinfo eingeliefert, dass heute schon im KDE-Repo (auch für die kommende openSUSE 12.2) eingesetzt wird.
https://bugzilla.novell.com/show_bug.cgi?id=746599
Mutige User können z.B. auf KDE 4.8.1 upgraden (bitte vorher ein Backup erstellen):
http://de.opensuse.org/SDB:KDE_Upgrade#Upgrade_auf_Release:48
Gruß
Sebastian
D.h. es ist nur ein Anzeigeproblem? Also es wird schon der richtige Treiber mit der richtigen Grafikkarte benutzt?
Wenn dem so ist, dann warte ich lieber auf eine neue opensuse Version.
aufjedenfall schonmal vielen Dank für die Hilfe, nach drei Tagen erfolglosen Versuchens kann ich das Notebook jetzt endlich vernünftig einsetzen.
Hallo,
habe Problem mit dem installieren des Amd-Treibers bei openSuse 12.1.
Bei 11.4 hatte ich garkein Problem aber jetzt geht garnichts -> schwarzer Bildschirm,
komme nur mit Failsafe ins System.
fglrxinfo:
X Error of failed request: BadRequest (invalid request code or no such operation)
Major opcode of failed request: 135 (GLX)
Minor opcode of failed request: 19 (X_GLXQueryServerString)
Serial number of failed request: 12
Current serial number in output stream: 12
Ich weiß mir keinen Rat?
Gruß U.
Hallo Udo,
kannst du bitte ein Report von deinem System via makerpm-amd-Skript erstellen? Anleitung befindet sich oben im Artikel. Dann schaue ich es mir gerne mal an.
Gruß
Sebastian
Hallo Sebastian,
http://sprunge.us/GMPc
muß noch dazu sagen das eigentlich „garnichts“ richtig läuft/lief…
das Verhalten des Systems war vollkommen willkürlich, so schien es, mal gings dann wieder nicht….
Muß auch erwähnen das ich zwar nun schon die dritte oder vierte Generation von opensuse nutze , aber immernoch keine tieferen Kenntnisse erworben habe…
11.4 lief bei mir tadellos…
bin mal gespannt was da rauskommt
Vielen Dank schon mal im Voraus
mfg
U.
hab mal das kompl. Os aktualisiert und dann Dein Script nochmal
laufen lassen, das hat dann einige kernelmodule nachgeladen und scheint jetzt ,
zumindest mit Gnome zu funktionieren…
unter KDE komme ich nicht rein , ksmserver startet nicht ?
linux:~ # fglrxinfo
display: :0 screen: 0
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: ATI Radeon HD 4550
OpenGL version string: 3.3.11554 Compatibility Profile Context
mfg
Hallo Udo,
dann logge dich mal bitte mit root in die Konsole ein und lösche manuell einmal die temporären KDE-Sachen und starte anschließend neu.
Sollte es nicht fruchten, kannst du auch alternativ die KDE-Einstellung umbenennen, um eine frische KDE-Konfiguration erzeugen zu lassen. Deinen Benutzernamen setzt du bitte in username ein.
mv /home/username/.kde4{,.old}Gruß
Sebastian
Hallo,
ein tolles Skript hast du, aber ich habe da mal 2 Fragen. Was genau bringt dein Skript dem Nutzer für Vorteile? Ich mein, das Installationsskript von AMD selbst kann ja auch distributionsspezifische RPM-Pakete bauen.
Zum anderen habe ich ein kleines Problem: Ich habe auf meinem Notebook einen Vanilla 3.2.5er Kernel, da die 3.1er Reihe irgendeinen Bugs enthält der mein Notebook einfrieren lässt.
Nun erstellt aber wieder AMDs noch dein Skript mir ein RPM-Paket das mir für meinen Kernel ein Treibermodul baut. Jedes mal beim installieren (per „rpm -ihv fglrx64[usw..].rpm“) bekomme ich die Ausgabe, dass mein Kernel „2.6.37.6-0.11.1-desktop“ sei.
Irgendeine Idee wie ich das „fixen“ kann?
Vielen Dank!
Hallo Christian,
zuerst muss ich sagen, dass das Packaging Skript im AMD Installer von mir auch offiziell betreut wird und habe bei der Entwicklung der Skripte für openSUSE recht freie Hand. Lies dir einfach meinen Artikel „AMD hat einen neuen openSUSE Packaging Script Maintainer für den ATI Installer“ durch.
Der Vorteil von dem makerpm-amd-Skript liegt auf der Hand und zwar, dass ich hier das Packaging Skript außerhalb der Reihe aktualisieren kann. AMD hat immer ein sehr knappes Zeitfenster zum Testen der Beta-Treiber und zum Einchecken eines aktuellen Packaging Skript in das Git Repository. Sehr oft beträgt die Deadline dafür nur 2 Wochen und dann dauert es ungefähr nochmal 3 Wochen bis der Treiber veröffentlicht wird. In den 3 Wochen kann einiges passieren, wie z.B. ein spezielles Update für openSUSE, dass nicht mehr berücksichtigt werden konnte oder sogar wie jetzt aktuell ein Kernel-Update vom Tumbleweed-Repo, dass den Bau eines fglrx Kernelmodul verhindert. (Siehe oben im Artikel die Update-Meldung)
Jetzt zu deinem Vanilla-Kernel Problemchen:
Starte einfach YaST den „Editor für /etc/sysconfig“ und gehe im Menü-Baum auf System / Kernel / Graphics card / ATI / USE_VANILLA_KERNELS. Dort schaltest du einfach auf „yes“ um. Wichtig: Die Kernel-Quellen von den Vanilla-Zeugs muss im Verzeichnis /usr/src vorhanden sein. Danach kannst du das fglrx-Kernelmodul mit folgendem Befehl bauen lassen:
Die Vanilla-Sachen habe ich vor langer Zeit im Packaging Skript implementiert und muss explizit eingeschaltet werden. Die Unterstützung ist bereits vorhanden.
Das fglrx-Kernelmodul wird bei jedem AMD Catalyst Update auch entsprechend neu gebaut.
Gruß
Sebastian
Hallo Sebastian,
danke für deine Antwort.
Das wusste ich nicht, das erklärt aber, wieso man hier die besten Informationen zum AMD-Treiber für openSUSE findet.
Ersteres habe ich eingestellt. Ich musste den Kernel leider neu kompilieren, da ich die Source-Dateien vom 3.2.5er Kernel nicht mehr hatte. Nun befindet sich der Quellcode in /usr/src/linux-3.2.13 und einen Symlink von /usr/src/linux auf den 3.2.13er Kernel habe ich auch eingerichtet. Ich habe auch die Konfigurationsdatei die ich zum Bauen verwendet habe, in den Sourceordner gepackt.
Wenn ich nun fglrx-kernel-build.sh ausführe, wird mir gesagt, dass das Modul schon existiert. Ich habe es also mit den Parametern -a -f ausgeführt und dennoch erstellt das Skript ausschließlich für den Standard 3.1.9er Kernel von openSUSE 12.1.
Ich wüsste nicht, was ich vergessen haben soll…
Irgendwelche Ideen?
Danke
Hallo Christian,
Jepp, richtig erkannt.
Zu dem Vanilla-Kernel:
Also, ich habe vorhin ebenfalls den Kernel 3.2.13 heruntergeladen und nach /usr/src entpackt. Ich habe in meinem Fall einfach die Kernel-Konfiguration vom laufenden Kernel genommen.
Ich habe folgende Schritte unternommen, um den Kernel + Module zu bauen und zu installieren:
Dann erst habe ich das fglrx-Kernelmodul bauen lassen:
Ergebnis:
Bei mir hat es funktioniert.
Gruß
Sebastian
Hast du noch einen der anderen Kernel installiert gehabt? Ich musste den Standardkernel wieder neuinstallieren, da das Script das fglrx-Modul nicht bauen wollte, da ich die Pakete kernel-devel, kernel-syms und andere Kernel-Pakete per „zypper lock“ gesperrt und nicht installiert hatte.
Ich versuche nebenbei noch mal den Kernel am Notebook zu bauen, was jedoch gut 2 Stunden dauern kann. Aber ich habe ja Zeit.
Eine Sache die ich anders gemacht hatte war, dass ich nicht direkt in /usr/src/linux den Kernel gebaut habe, sondern in meinem home-Verzeichnis, da / bei mir „nur“ 20 GB hat und ich ca. 1 GB zu wenig freien Speicherplatz hatte zum bauen. (unglaublich, der Kernel braucht mit openSUSE-Desktop-Konfiguration fast 7 GB Speicherplatz zum Bauen).
Müssen die .o Dateien und was nicht sonst noch alles von gcc angelegt wird, im Source-Ordner vorhanden sein?
Danke noch mal.
So, der Kernel ist fertig. Ich habe das System mit dem neuen Kernel gestartet, fglrx installiert (mittels deines makerpm-Skripts), /etc/sysconfig/fglrxconfig geprüft ob USE_VANILLA_KERNELS auf „yes“ steht und dann habe ich fglrx-kernel-build.sh -f -a ausgeführt, und wieder wurde nur für den 3.1.9-desktop-Kernel ein Modul erstellt… Also irgendetwas muss da doch wohl kaputt sein? :\
Soo… Habe es gelöst!
Da ich den Kernel nicht in /usr/src selbst gebaut habe und dementsprechend die generierten Dateien fehlten, musste ich in /usr/src/linux noch einmal make prepare_modules ausführen.
Danke für die Hilfe!
Hallo Christian,
sehr schön. Dann mal viel Spaß damit.
Gruß
Sebastian
Hi Sebastian,
ich habe heute von 3.2.9-13-pae auf “Linux version 3.3.0-16-pae ″ umgestellt und danach lief der fglrx-Treiber nicht mehr. Ich versuchte Catalyst 12.2 neu zu installieren und bekomme die Fehlermeldung “struct thread_struct‘ has no member named ‚has_fpu’” . Hier der Log-Report von Deinem ” makerpm-amd-12.2.sh”-File:
.... LD /usr/src/kernel-modules/fglrx/2.6.x/built-in.o CC [M] /usr/src/kernel-modules/fglrx/2.6.x/kcl_acpi.o CC [M] /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.o /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c: In function 'KCL_GetInitKerPte': /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c:2384:5: warning: return makes integer from pointer without a cast [enabled by default] /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c:2385:5: warning: return makes integer from pointer without a cast [enabled by default] /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c:2386:5: warning: return makes integer from pointer without a cast [enabled by default] /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c: In function 'KCL_GetPageTableByVirtAddr': /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c:2431:5: warning: return makes integer from pointer without a cast [enabled by default] /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c:2434:5: warning: return makes integer from pointer without a cast [enabled by default] /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c:2435:5: warning: return makes integer from pointer without a cast [enabled by default] /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c: In function 'KCL_TestAndClearPageDirtyFlag': /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c:2609:5: warning: return makes integer from pointer without a cast [enabled by default] /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c: In function 'KCL_fpu_begin': /usr/src/kernel-modules/fglrx/2.6.x/firegl_public.c:5812:25: error: 'struct thread_struct' has no member named 'has_fpu' make[3]: *** [/usr/src/kernel-modules/fglrx/2.6.x/firegl_public.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [_module_/usr/src/kernel-modules/fglrx/2.6.x] Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 make: Leaving directory `/usr/src/linux-3.3.0-16-obj/i386/pae' ****************************** Build of kernel module failed! ****************************** rm -rf *.c *.h *.o *.ko *.a .??* *.symvers / Calling 'depmod -a 3.3.0-16-pae' this may take a while... Summary report: ================================================================================ Kernel => 3.2.10-15-default Detected => RPM package Build => [ FAILURE ] Install => [ FAILURE ] Kernel => 3.3.0-16-pae Detected => RPM package Build => [ FAILURE ] Install => [ FAILURE ] ************************************************************** Building/installation of fglrx kernel module failed! Try again ....Gleicher Verlauf bei mir.
Hallo zusammen,
ich werde da mal ein Auge drauf werfen, was da genau beim Bau schief läuft. Dieser Kernel im Tumbleweed-Repo macht mich noch wahnsinnig.
Gruß
Sebastian
Hallo Rudolfo und Hennes,
ich habe das Skript soeben aktualisiert. Mehr Informationen hierzu oben im Artikel. Wie immer bitte ich um euer Feedback. Danke.
Gruß
Sebastian
Hallo Sebastian,
ist okay, läuft wieder. Vielen Dank! Es tut mir Leid, dass wir immer wieder Kummer machen, aber vielleicht erreichen die kommenden Kernel jetzt eine gewissen Stabilität.
Mfg.
Rudolfo
Hallo Rudolfo,
vielen Dank für dein Feedback. Gut zu wissen, dass es bei dir wieder läuft.
Sehen wir mal positiv. AMD hat von mir ebenfalls den Patch erhalten. Sie haben sich bei mir heute morgen kräftig bedankt und nehmen ihn für AMD Catalyst 12.4 auf. Für AMD Catalyst 12.3 werde ich noch die beiden Patches in das Packaging Skript aufnehmen.
Gruß
Sebastian
Ganz, ganz, ganz vielen lieben Dank.
Läuft 100%ig durch und funktioniert. (Soweit der fglrx-Kram halt mit Gnome läuft.)
Du lieferst wirklich immer und immer wieder top Qualität ab.
Bleibt nur die Frage offen ab wann sich die Kernel-Hacker und AMD mal deiner Arbeitsleistung anpassen.
gruß Hennes
Moin Hennes,
stimmt, so einen Service findet man nicht überall. Ob die Kernel-Hacker und AMD an meiner Leistung messen können, steht wohl in den Sternen.
Ich denke mal, dass nachher noch der 8.96 Branch im Git Repository erzeugt wird, dann füge ich die Kernel-Patches zum Packaging Skript hinzu. Für AMD Catalyst 12.3, welches in den nächsten Tagen kommen soll, wird es dafür schon zu spät sein. Deshalb haben wir ja noch das makerpm-amd-Skript, der diese Manko ausgleicht. Jedoch für AMD Catalyst 12.4 im April sind die Kernel-Patches definitiv On-Board. 
Gruß
Sebastian
Hallo Sebastian,
eine Frage zu zwei Dingen, die mir heute aufgefallen sind:
In Catalyst wird mir nur 256 MB Speicher angezeigt, obwohl ich mir sehr sicher bin, dass es 512 MB sein müssten (jedenfalls hat mir das Catalyst unter Win immer angezeigt). Gibt es eine eindeutige Möglichkeit, das zu überprüfen?
Als ich mit aticonfig etwas herumgespielt habe, wurde ich auf folgenden Befehl aufmerksam:
Test out 3D : atiode -P60 -H localhost:0; echo $?
Bei mir gab’s eine „2“ als Rückmeldung (2: Test failed because of rendering errors). Eine kleine Ahnung, warum?
Danke und Gruß
Sebastian
Hallo Sebastian,
ich habe deine Mail erhalten. Da habe ich gleich mal nachgeschaut, ob ich auf deinen Post schon geantwortet habe. So, wie es aussieht noch nicht.
Zum Grafikspeicher: Hierzu werde ich mal AMD ansprechen, ob es evtl. ein Fehler beim Auslesen ist.
Zum Grafiktest: Das muss ich mal testen und kann erst nächste Woche näheres dazu sagen.
Gruß
Sebastian
Hallo Sebastian,
Früher hatten ja einige mit dem Vollbildmodus bei Flash Probleme (sehr starkes ruckeln, PC reagiert kaum mehr). Das war für mich der Grund, die proprietären Treiber vorerst wieder vom PC zu verbannen. Nun habe ich auf oS 12.1 die ATI 12.2 Treiber probiert und habe immer noch dasselbe Problem, jedoch scheint sich darüber kein anderer bisher in den Kommentaren beschwert zu haben.
Wurde das offiziell gefixt oder gibt es einen Workaround, von dem ich nichts mitbekommen habe?
Viele Grüße,
Dennis
Hallo Dennis,
ich teste regelmäßig die Treiber und auch die Beta-Treiber auf meiner Maschine und habe bisher kein ruckeln mit dem Flash-Player und dem AMD Treiber feststellen können. Welche Flash Version hast du im Einsatz? Wieviele CPU-Kerne hat der PC?
Gruß
Sebastian
Hallo Sebastian,
Zum Zeitpunkt des Test:
flash-player 11.1.102.63-9.1 aus openSUSE Update
Firefox 11.0
Seit dieser Woche gibt es jedoch den flash-player 11.2.202.228-12.1, mit diesem habe ich es noch nicht getestet, ich bezweifel aber, dass es gerade in dieser Woche weg geht, wo doch das Problem schon seit Monaten besteht und ich jede Woche die Pakete aktualisiere.
CPU: AMD Phenom II X4 920 mit 4 Kernen
Viele Grüße,
Dennis
Hallo Dennis,
welchen Desktop verwendest du nochmal?
Gruß
Sebastian
Hallo Sebastian,
Sorry, ich denke irgendwie immer KDE sei der Standard bei oS
KDE 4.7.4 release 13, jedoch aus diesem Repository: http://download.opensuse.org/repositories/KDE:/Release:/47/openSUSE_12.1
Bis auf LibreOffice und Packman habe ich nur die Standard-Repos.
Viele Grüße,
Dennis
Ergänzung:
Bei der Grafikkarte handelt es sich um eine
ATI Technologies Inc RV770 [Radeon HD 4850]
laut lspci. Das Ruckeln tritt ausschließlich im Vollbildmodus und nicht mit den oss-Treibern auf.
Hi Sebastian,
die ständigen Freezes in Gnome 3.2 machen das Arbeiten mit dem proprietären Treiber zur Qual. Deswegen wollte ich zurück zum freien Treiber. Das scheint aber nicht ganz so einfach zu sein.In Runlevel 3 habe ich das Skript mit der Option -u ausgeführt und auch die Rückmeldung erhalten, dass die Deinstallation erfolgreich verlaufen sei. Nur weigerte sich der Rechner dann anschließend, nach Neustart eine sinnvolle Umgebung zu starten. Nicht einmal auf den Textbildschirm komme ich. Was ist hier passiert? Auf der Box läuft eine Standard- Opensuse 12.1 Installation mit Gnome 3.2, der verwendete freie Treiber sollte also radeonhd sein.
Beste Grüße
Edgar
Hallo Edgar,
der radeonhd Treiber ist veraltet und sollte auch nicht mehr verwendet werden. Der aktuelle Treiber heißt nun radeon.
Evtl. solltest du KMS (Kernel Mode Settings) wieder einschalten und die Initial Ramdisk neu bauen lassen. Manche Leute haben mit dieser Option Probleme gehabt. Evtl. ist es heute genau umgekehrt.
„YaST Editor für /etc/sysconfig“ starten:
Im linken Menü-Baum navigieren zu:
System / Kernel / NO_KMS_IN_INITRD
Dort für NO_KMS_IN_INITRD auf no einstellen.
Danach in der Konsole die Initial Ramdisk neubauen:
Gruß
Sebastian
Danke Sebastian,
das hat funktioniert. Weisst du zufällig, ob AMD das Problem mit der gnome-shell irgendwann mal in den Griff bekommen will?
Gruß
Edgar