openSUSE 11.3 – proprietären Grafik-Treiber ATI Catalyst 10.9 als RPM installieren

Hinweis: Dieser Artikel ist veraltet. Ein neuer Artikel befindet sich hier: openSUSE 11.3 – proprietären Grafik-Treiber ATI Catalyst 10.10 als RPM installieren

ATI Catalyst 10.9 (fglrx 8.771) wurde veröffentlicht. Das Skript makerpm-ati-10.9.sh habe ich ebenfalls aktualisiert und steht ab sofort zum Download zur Verfügung.

Laut der Release Notes wurden folgende Bugs behoben:

  • System no longer fails while launching fgl_glxgears window when Anti-Aliasing and Desktop Effects are enabled
  • [SUSE 11.1] Hardware playback now functions properly
  • [openSUSE 11.3] Corruption no longer visible on Firefox while scrolling the window by dragging the scrollbar
  • [SUSE 11.2] With a DP display connected to the adapter, a hot-plugged DFP display will now light up properly in clone mode

[UPDATE 24.09.2010]
Seit dem neuen Kernel 2.6.34.7-0.3 wird der Bau eines fglrx-Kernelmodul fehlschlagen.

/usr/src/kernel-modules/fglrx/kcl_ioctl.c:196:5: error: implicit declaration of function ‘compat_alloc_user_space’

Die Ursache ist, dass die Funktion compat_alloc_user_space() für proprietäre Software/Treiber aus lizenzrechtlichen Gründen nicht mehr zur Verfügung steht.

Aus diesem Grund habe ich ein Patch generiert, um die Funktion compat_alloc_user_space() gegen arch_compat_alloc_user_space() zu ersetzen.

Patch: ati-10.9-replace-function-compat_alloc_user_space.patch

Das Skript makerpm-ati-10.9.sh habe ich angepasst. Es lädt automatisch den Patch herunter und wendet es an den Quellcode vom fglrx-Kernelmodul an. Bevor man das neu generierte Paket installiert, sollte man das alte Paket deinstallieren. Achtung: Bitte eine Sicherung von /etc/X11/xorg.conf machen, weil die Konfigurationsdatei bei der Deinstallation gelöscht wird.

Wer das RPM manuell baut, muss sich im Troubleshooting einlesen, wie man den Patch anwendet.
[/UPDATE 24.09.2010]

[UPDATE 26.09.2010]
Ich habe das Skript erneut aktualisiert. Der Patch für den o.g. Compiler-Fehler ist nicht mehr auf openSUSE 11.3 beschränkt.

Zudem habe ich noch ein sehr interessantes Feature zu verkünden, dass Zeit und Nerven spart. Denn ich habe ein Rebuild-Skript programmiert, dass sich im xdm-Initskript (wird vom X-Server für KDE, GNOME, etc. benötigt) einklinkt und so automatisch bei jedem neuen Kernel-Update das fglrx-Kernelmodul neu baut.

Der Vorteil ist, dass man nach einem Kernel-Update nicht (vielleicht auch nie) mehr in der Konsole landet oder ohne 3D-Unterstützung in die Desktopumgebung startet.

Das Rebuild-Skript kann man wie folgt herunterladen und installieren lassen:

./makerpm-ati-10.9.sh -irs

Falls man das Rebuild-Skript nicht mehr benötigt, so kann man es einfach restlos deinstallieren:

./makerpm-ati-10.9.sh -urs

Wenn es doch mal Probleme mit dem automatischen Bauen eines fglrx-Kernelmodules geben sollte, wird dazu eine Logdatei /var/log/fglrx-build.log mit den Compiler-Meldungen angelegt.

Ich habe soeben mit der Entwicklung einer GUI im Systemtray-Modus (für Update-Benachrichtigung und Installation) begonnen. Das Tool sollte hoffentlich Anwender wie auch Anspruchsvolle gleichermaßen zufrieden stellen. ;-)
[/UPDATE 26.09.2010]

Inhaltsverzeichnis

Einleitung

*** Wichtiger Hinweis zum ATI-Repo ***
Im ATI-Repo befindet sich noch der ältere ATI-Catalyst 10.6 (fglrx 8.741) Treiber. Daher empfehle ich den Treiber nicht unter openSUSE 11.3 zu installieren. Wenn man trotzdem diesen Treiber installiert, kann es unter Umständen passieren, dass das grafische Desktopsystem komplett ausfällt und nicht selten wird auch die Konsole völlig verzerrt, wobei man nur noch über den Failsafe-Modus wieder ins System kommt.

Diese Anleitung wie auch das Skript werden regelmäßig aktualisiert. Es lohnt sich daher öfter mal vorbeizuschauen oder im Feedreader zu speichern.

Es gibt 2 Wege den Bau des RPM-Packages durchzuführen.

  1. das RPM mit dem Skript makerpm-ati-10.9.sh bauen (empfohlen)
  2. das RPM manuell bauen (für Fortgeschrittene)

Der Vorteil zu Punkt 1: man muss sich nicht um die nötigen Packages für den Bau kümmern und man spart sich die Tipparbeit, die Zeit und die Nerven. ;-)

Die Anleitung funktioniert mit geringer Abweichung auch unter openSUSE 11.2 und openSUSE 11.1.

Alle genannten Schritte müssen in der Konsole im Root-Modus ausgeführt werden. Die Installation des RPM-Package „fglrx“ kann im Runlevel 3 oder auch im Runlevel 5 durchgeführt werden. Danach ist ein Neustart des Computers auf jeden Fall erforderlich.

Vorhandene fglrx-Treiber aus dem ATI-Repo sind auf jeden Fall zu deinstallieren, sonst kommt es zu Konflikten bei der Installation dieses selbstgebauten RPM-Package.

Mit vorhandene fglrx-Treiber sind z.B. folgende gemeint:
ati-fglrxG01-kmp-{default,desktop,pae,…}
ati-fglrxG02-kmp-{default,desktop,pae,…}
x11-video-fglrxG02

Vorhandene fglrx-Treiber auflisten lassen:

rpm -qa | grep -E 'fglrxG01|fglrxG02'

Wenn hier von RPM eine Ausgabe erscheint, müssen diese Package deinstalliert werden:

zypper rm `rpm -qa | grep -E 'fglrxG01|fglrxG02'`

Alternativ kann man auch in YaST nach fglrxG01 bzw. fglrxG02 suchen und entfernen lassen.

Hilfe, es funktioniert nicht!

Bitte haltet folgende Regel ein:

  1. Bei der Eingabe der Befehle auf mögliche Tippfehler überprüfen.
  2. Möglicherweise ist die Lösung für das Problem im Troubleshooting vorhanden.
  3. 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-ati-10.9.sh herunter und erstellt einen Report von eurem System in der Konsole:

su -c 'sh makerpm-ati-10.9.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.

RPM mit dem Skript bauen

Das Skript makerpm-ati-10.9.sh ist sehr mächtig, robust und läuft vollautomatisch. Der ATI-Installer wird automatisch heruntergeladen, falls er nicht schon im Verzeichnis liegt. Zudem wird geprüft, ob die Grafikkarte vom Treiber unterstützt wird. Auf dem System werden nach den nötigen Entwicklungspaketen geprüft und ggfs. installiert. 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
-irs Das Rebuild-Skript /etc/ati/fglrxrebuild.sh installieren und im Initskript /etc/init.d/xdm einklinken. Das Skript sorgt dafür, dass bei jedem Kernel-Update das fglrx-Kernelmodul vor dem Start der Desktopumgebung gebaut wird. Es wird auch eine Logdatei /var/log/fglrx-build.log angelegt, um mögliche Compiler-Fehler festzuhalten.
-kms <yes|no> Kernel-Mode-Setting (KMS) aktivieren oder deaktivieren
-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 ATI 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.
-urs Das Rebuild-Skript /etc/ati/fglrxrebuild.sh deinstallieren und das Initskript /etc/init.d/xdm wiederherstellen.
-ux openSUSE 11.2: Nur den gepatchten X-Server installieren. Verbessert die Zusammenarbeit mit dem fglrx-Treiber. (dringend zu empfehlen)
-h Die Hilfe anzeigen lassen
-V Version des Skript anzeigen

Downloads:

Empfohlene Vorgehensweise:

Man benötigt hierfür die Konsole mit root-Rechten, um das Skript auszuführen.

Das System im Runlevel 3 starten oder wechseln:
Beim Booten: Im Bootmenü den Eintrag von openSUSE 11.3 selektieren und auf der Tastatur die Zahl „3“ und Enter drücken und als „root“ einloggen
Im laufenden Desktopsystem: Bitte vom System abmelden. Sobald die grafische Anmeldung erscheint den Tastenkürzel ALT+N oder STRG+ALT+F1 drücken, um in die Konsole umzuschalten. Dann mit dem User „root“ einloggen und mit folgendem Befehl in den Runlevel 3 wechseln:

init 3

1. Das Skript herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.9.sh

2. Die Prüfsummendatei herunterladen:

wget http://www.sebastian-siebert.de/downloads/makerpm-ati-10.9.sh.sha1

3. Die Prüfsummendatei gegen das Skript prüfen:

sha1sum -c makerpm-ati-10.9.sh.sha1

Idealerweise sollte folgende Ausgabe erscheinen, andernfalls stimmt etwas mit dem heruntergeladenen Skript nicht:

makerpm-ati-10.9.sh: OK

4. Die Rechte des Skriptes ändern und ausführbar machen:

chown root:root makerpm-ati-10.9.sh && chmod 744 makerpm-ati-10.9.sh

5. Das Skript mit dem Argument -i ausführen. Das RPM-Package wird im Anschluß automatisch installiert.

./makerpm-ati-10.9.sh -i

6. Optional, aber empfohlen: Das Rebuild-Skript herunterladen und installieren. Das Skript klinkt sich vor dem Start von KDE, GNOME, etc. ein und baut automatisch nach jedem Kernel-Update das fglrx-Kernelmodul neu.

./makerpm-ati-10.9.sh -irs

7. Den Rechner neustarten:

reboot

RPM manuell bauen

Das ist der etwas schwierigere Teil. Aber es ist nicht unmöglich. :-)

Für den Bau des RPM-Packages werden folgende Entwicklungswerkzeuge bzw. -packages benötigt:

  • gcc
  • make
  • patch
  • kernel-devel (openSUSE 11.2 / openSUSE 11.1: linux-kernel-headers)
  • kernel-source
  • kernel-{default,desktop,pae,rt,vanilla,xen}-devel
  • kernel-syms

Beim Kernel-Entwicklungspackage ist zu beachten, dass man die richtige installiert hat. Welchen Kernel zur Zeit auf dem System läuft, kann man in der Konsole abfragen:

uname -r

Bei mir ergibt beispielsweise diese Ausgabe:

2.6.34.4-0.1-desktop

Also muss im o.g. Fall der Kernel-Entwicklungspackage kernel-desktop-devel installiert sein.

Folgende Schritte werden auf einem 32-bit wie auch 64-bit openSUSE-System durchgeführt:

1. Den Installer des proprietären Treiber von ATI herunterladen:
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-9-x86.x86_64.run

Optional: Das System im Runlevel 3 starten und als „root“ einloggen oder per init 3 wechseln.

2a. (openSUSE 11.3 32-bit) Den Bau des RPM-Packages anstoßen:
(openSUSE 11.2: SuSE/SUSE112-IA32, openSUSE 11.1: SuSE/SUSE111-IA32)

sh ./ati-driver-installer-10-9-x86.x86_64.run --buildpkg SuSE/SUSE113-IA32

2b. (openSUSE 11.3 64-bit) Den Bau des RPM-Packages anstoßen:
(openSUSE 11.2: SuSE/SUSE112-AMD64, openSUSE 11.1: SuSE/SUSE111-AMD64)

sh ./ati-driver-installer-10-9-x86.x86_64.run --buildpkg SuSE/SUSE113-AMD64

3a. Das RPM-Package installieren (Neuinstallation):

rpm -ihv fglrx*SUSE113-8.771*.rpm

3b. Das RPM-Package installieren (Update):

rpm -Uhv fglrx*SUSE113-8.771*.rpm

4. Den Rechner neustarten:

reboot

Troubleshooting:

  1. Nach dem Booten sieht man die Konsole (Problem mit der Konfiguration des X-Servers)
  2. Nach dem Booten hat man einen schwarzen Bildschirm (Problem mit dem Kernel-Mode-Setting)
  3. Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 ist nicht aktiviert
  4. Arbeitsflächen-Effekte (Compositing) in KDE 4.5 lassen sich gar nicht mehr aktivieren
  5. In Firefox oder Thunderbird erscheinen schwarze Flächen
  6. Im ATI Catalyst Control Center zeigt mir im Abschnitt „Informationen“ noch die alte ATI-Version an, obwohl ich den neuen Treiber installiert und neugestartet habe.
  7. Mein Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt?
  8. Wenn ich den Treiber unter openSUSE 11.3 (Kernel 2.6.34.7-0.3) baue, dann bricht er immer wegen der Funktion compat_alloc_user_space ab.
  1. Sollte man nach dem Booten in der Konsole landen, dann erstellt man besser eine Konfigurationsdatei des X-Servers. In diesem Fall bitte als „root“ in die Konsole einloggen und folgende Schritte durchführen.

    einfache Variante:

    Vorher noch in den Runlevel 3 wechseln:

    init 3

    Bei einem Monitor (Single-Modus):

    ./makerpm-ati-10.9.sh -c single

    Bei zwei Monitore (Dual-Modus):

    ./makerpm-ati-10.9.sh -c dual

    Danach den Rechner neustarten.

    Fortgeschrittene Variante:

    1. X-Server-Konfiguration verschieben, falls vorhanden:

    mv /etc/X11/xorg.conf /etc/X11/xorg.conf.backup

    2. Von aticonfig eine neue Konfigurationsdatei erzeugen lassen: (Das Tool aticonfig kann mittlerweile auch eine X-Server-Konfiguration from Scratch erzeugen, jedoch speziell auf den fglrx-Treiber zugeschnitten. Die restliche Hardware wird vom X-Server automatisch erkannt und geladen. Dies sollte in Zukunft vorgezogen werden, falls die Autoerkennung für den fglrx-Treiber oder X -configure nicht funktioniert):

    Bei einem Monitor (Single-Modus):

    aticonfig --initial --input=/etc/X11/xorg.conf

    oder bei zwei Monitore (Dual-Modus):

    aticonfig --initial=dual-head --input=/etc/X11/xorg.conf
  2. Wenn man vor einem schwarzen Bildschirm sitzt und man weder die Konsole noch den Desktop sieht, dann liegt es höchstwahrscheinlich am neueingeführten Kernel-Mode-Setting (auch KMS genannt). Das Problem läßt sich durch Deaktivierung des KMS beheben.

    einfache Variante:

    Mit dem Skript das KMS dauerhaft deaktivieren:

    ./makerpm-ati-10.9.sh -kms no

    Fortgeschrittene Variante:

    Es gibt 2 Möglichkeiten KMS zu deaktivieren:

    • Als Bootparameter in GRUB oder LILO: nomodeset
    • KMS im Initial Ramdisk grundsätzlich deaktivieren. Der nachfolgende Befehl schaltet das KMS in der Konfiguration /etc/sysconfig/kernel auf NO_KMS_IN_INITRD=“yes“ aus.
      sed -i 's/NO_KMS_IN_INITRD=.*/NO_KMS_IN_INITRD="yes"/g' /etc/sysconfig/kernel

      Anschließend die Initial Ramdisk neubauen lassen:

      mkinitrd
  3. Falls die Arbeitsflächen-Effekte (Compositing) in KDE 4.4 bzw. 4.5 nicht mehr aktiviert sind, weil vermutlich die Erkennung der OpenGL-Schnittstelle von AMD/ATI Catalyst 10.9 fehlschlägt. Hierzu gibt es eine einfache Lösung:
    1. Im KDE-Menü auf Systemeinstellungen klicken
    2. Unter Allgemein / Erscheinungsbild & Verhalten auf Arbeitsfläche klicken
    3. In Arbeitsflächen-Effekte einrichten auf den Tab Erweitert klicken
    4. Die Checkbox Funktionsprüfungen deaktivieren aktivieren
    5. Im Tab Allgemein prüfen, ob Compositing aktiviert ist. Falls nicht, bitte aktivieren.
    6. Abschließend auf Anwenden klicken

    Jetzt sollen die Effekte in KDE wieder funktionieren. Die 3D-Anwendungen bzw. 3D-Spiele sind von diesem Problem nicht betroffen.

  4. Wenn das Compositing im OpenGL-Modus in KDE 4.5 nicht mehr aktivierbar sein sollte, dann wurde möglicherweise von KWin das Compositing komplett deaktiviert. Schuld ist die Einstellung OpenGLIsUnsafe=true in der Konfiguration /home/USERNAME/.kde4/share/config/kwinrc. Leider gibt es noch keine Möglichkeit diese Option in den Systemeinstellungen von KDE zu ändern.

    Man kann in der Konsole schnell und komfortabel für jeden User im Home überprüfen, ob man von dem Problem betroffen ist. Wenn bei dem nachfolgenden Befehl eine oder mehrere Dateien aufgelistet werden, so ist die Option von KWin bei dem jeweiligen User scharf geschaltet worden:

    grep -l "OpenGLIsUnsafe=true" /home/*/.kde4/share/config/kwinrc

    Es ist wichtig, dass der folgende Befehl im Runlevel 3 ausgeführt wird, sonst werden die Einstellungen von KWin wieder überschrieben. Wie man in den Runlevel 3 kommt, wird oben im Artikel beschrieben. Um das Problem mit „OpenGLIsUnsafe“ für alle User im Home-Verzeichnis zu beheben, gibt man folgenden Befehl als root in der Konsole ein:

    sed -i '/OpenGLIsUnsafe=.*/d' /home/*/.kde4/share/config/kwinrc

    Hintergrundinfo:
    Die Option OpenGLIsUnsafe kam mit der Revision 1079919 und wurde vom Autor Lucas Murray (lmurray) geschrieben. Allerdings ist ein Recheck-Button in der KDE-Einstellung laut einer TODO-Anmerkung im Quellcode in Zeile 156 geplant, um ggfs. die Option OpenGLIsUnsafe zurückzusetzen, was leider bisher noch nicht umgesetzt wurde.
    Quellcode von kwincompositing
    der Diff vom Quellcode zur Revision 1079919

  5. Falls unter Firefox oder Thunderbird schwarze Flächen erscheinen, dann liegt es in erster Linie an den neuen 2D-Treiber. Um den alten 2D-Treiber zu verwenden, führt man folgende Kommando aus.

    einfache Variante:

    ./makerpm-ati-10.9.sh -old2ddriver yes

    Fortgeschrittene Variante:

    aticonfig --set-pcs-str=DDX,ForceXAA,TRUE

    Hinweis: Falls das Problem mit den schwarzen Flächen in 2D-Anwendungen in der nächsten Version behoben wurde, kann man es wieder deaktivieren:

    einfache Variante:

    ./makerpm-ati-10.9.sh -old2ddriver no
  6. Fortgeschrittene Variante:

    aticonfig --del-pcs=DDX,ForceXAA
  7. Im ATI Catalyst Control Center zeigt mir im Abschnitt „Informationen“ noch die alte ATI-Version an, obwohl ich den neuen Treiber installiert und neugestartet habe.

    Bitte in den Runlevel 3 starten und dort den Treiber mit dem Skript komplett entfernen lassen:

    ./makerpm-ati-10.9.sh -u

    Danach mittels mit dem Skript neuinstallieren:

    ./makerpm-ati-10.9.sh -i

    Abschließend neustarten.

  8. Mein Treiber unterstützt meine Grafikkarte nicht. Was mache ich jetzt? Hier kann man leider nur den Radeon-Treiber verwenden. Man öffnet die Konfigurationsdatei /etc/X11/xorg.conf.d/50-device.conf mit root-Rechten, um diese bearbeiten zu können. Einfach den Krunner mittels Tastenkürzel ALT+F2 öffnen und folgende Befehlszeile eingeben und abschließend mit Enter bestätigen:
    kdesu kwrite /etc/X11/xorg.conf.d/50-device.conf

    In der Zeile 4 bei Driver „radeon“ nimmt man vorne die Raute weg und speichert die Datei ab. Anschließend alle Anwendungen schließen und neustarten.

    Sollte man beim Neustart einen schwarzen Bildschirm bekommen, dann muss das KMS abgeschaltet werden. Bitte einmal diesen Workaround zum Abschalten von KMS im Failsafe-Modus durchführen.

  9. Wenn ich den Treiber unter openSUSE 11.3 (Kernel 2.6.34.7-0.3) baue, dann bricht er immer wegen der Funktion compat_alloc_user_space ab.

    Wer das Skript makerpm-ati-10.9.sh verwendet, ist davon nicht betroffen, weil das Skript automatisch das Patch einpflegt.

    Für alle, die manuell das Paket bauen, gilt diese Anleitung:

    1. Patch herunterladen:

    wget http://www.sebastian-siebert.de/downloads/ati-10.9-replace-function-compat_alloc_user_space.patch

    2. den ATI-Installer auspacken:

    ./ati-driver-installer-10-9-x86.x86_64.run --extract ati-10.9

    3. Patch anwenden:

    patch -p0 <ati-10.9-replace-function-compat_alloc_user_space.patch

    4. in den ATI-Verzeichnis wechseln:

    cd ati-10.9

    5. vom ATI-Installer das RPM-Paket generieren lassen:
    unter openSUSE 11.3 (32-bit)

    ./ati-installer.sh `./ati-packager-helper.sh --version` --buildpkg SuSE/SUSE113-IA32

    unter openSUSE 11.3 (64-bit)

    ./ati-installer.sh `./ati-packager-helper.sh --version` --buildpkg SuSE/SUSE113-AMD64

    Danach das generierte RPM wie gewohnt installieren.

Feedbacks sind wie immer willkommen. :-)

131 thoughts on “openSUSE 11.3 – proprietären Grafik-Treiber ATI Catalyst 10.9 als RPM installieren

  1. (Habe das gleiche Problem auch schon mit der vorherigen Treiberversion gehabt)

    Hallo Sebastian,

    ich habe seit dem letzten Kernel-Update auch Probleme mit dem Treiber (schwarzer Bildschirm nach dem Booten, nomodeset hilft nicht). Vorher ging der Treiber bei mir.

    Ich bin wie folgt vorgegangen:
    1) makerpm-ati-10.9.sh -u
    2) reboot
    3) makerpm-ati-10.9.sh -i
    4) cp gesichterteXorg.conf /etc/X11/xorg.conf
    (4.5) Ich hab an dieser Stelle auch versucht, die xorg mit dem ati-Tool zu erstellen – ohne Erfolg)
    5) reboot
    6) schwarzer Bildschirm

    Ich habe auch noch ein wenig mehr herumexperimentiert – alles ohne Erfolg. Deshalb schreibe ich dir jetzt hier. Ein weiteres Problem ist, dass ich dir keinen Report schicken kann: beim Erstellen des Reports bleibt er in dieser Zeile stecken:
    Output: /usr/sbin/hwinfo –monitor

    Bevor ich diese Seite gefunden hatte, habe ich einfach immer den Installer von ATI genutzt. Diesmal funktionierte das nicht: beim Schritt “postprocessing kernel module” bleibt er stecken und u.A. folgende Meldung erscheint in der Konsole:
    Can’t create //usr/X11R6/lib/modules/dri/fglrx_dri.so: File exists

    Hast du eine Idee, wie ich weiter vorgehen könnte?

    Hier noch ein paar Infos, die helfen könnten (u.a. aus dem teilweise erstellten Report entnommen):
    – openSUSE 11.3 (x86_64)
    – 2.6.34.4-0.1-desktop
    – ATI Radeon HD 3470 (Dual Head)
    – /usr/bin/fglrxinfo: Error: unable to open display (null)
    – cat: /proc/pci: No such file or directory

    Vielen Dank
    Sebastian

        • Hallo Sebastian,

          also, der Treiber wird korrekt geladen und auch vom X-Server initialisiert. Wahrscheinlich scheint es bei der Einstellung Probleme zu geben. Daher würde ich erstmal versuchen, die Einstellungen komplett zurück zu setzen.

          Bitte mal openSUSE in den Runlevel 3 neustarten und als root einloggen.

          Die folgende Dateien einmal umbenennen:

          mv /etc/X11/xorg.conf{,.old}
          mv /etc/ati/amdpcsdb{,.old}

          Danach aticonfig mit folgender Konfiguration starten:

          aticonfig --initial=dual-head --screen-layout=right --xinerama=on

          Gruß

          Sebastian

          • Hallo Sebastian,

            ich habe gerade alles so ausgeführt, wie du gesagt hast und rebootet. Leider gehen beide Monitore wieder in den Ruhezustand und nichts passiert. Wenn ich per SSH als root das Script (sh ati-report.sh -u) ausführen will, bleibt er bei
            OUTPUT: /usr/sbin/hwinfo –monitor
            stehen.

          • Hallo Sebastian,

            gerade bei hwinfo –monitor sollte er gar nicht stehen bleiben?! Kannst du bitte nachschauen, ob die Monitore korrekt verbunden sind.

            Gruß

            Sebastian

          • Das sollten sie auf jeden Fall sein. Wenn ich von einer Knoppix CD boote, dann klappt das und auch hwinfo –monitor kann ausgeführt werden.

          • Moin Sebastian,

            gibt es eine Möglichkeit openSUSE 11.3 inkl. aller Updates auf deinem Rechner parallel zu installieren und danach das Skript ausführen? Dann kann man schon mal ausschließen, dass irgendein fremdes Paket die ganze Geschichte sabotiert oder ob der fglrx-Treiber selber die Probleme verursacht.

            Gruß

            Sebastian

          • Kleine Ergänzung:
            führe ich hwinfo –monitor manuell aus, bleibt er beim Schritt „misc.3.4: RTC“ hängen.

  2. Hallo Sebastian,

    so langsam nimmt das Zusammenspiel zwischen Linux (openSUSE) und ATI (AMD) Formen an.

    Seit dem neuen Treiberupdate funktioniert fast alles so, wie ich es mir auch vorstelle. Zwar ist das Thema Flash und Linux noch nicht ausgestanden aber man merkt doch schon deutliche Verbesserungen was die Performance und Stabilität betrifft.

    Zu Deiner Arbeit (besonders das Skript sei hier zu erwähnen) und all den anderen Themen bezüglich openSUSE kann ich wie immer nur sagen….fantastisch.

    Bislang hatten sämtliche Deiner Anmerkungen, Tipps und Ratschläge Hand und Fuß.

    Bleibt mir nur zu sagen: „Bitte, bitte mach weiter so.“

    Gruß Hennes

    • Moin Hennes, ;-)

      so langsam nimmt das Zusammenspiel zwischen Linux (openSUSE) und ATI (AMD) Formen an.

      Seit dem neuen Treiberupdate funktioniert fast alles so, wie ich es mir auch vorstelle. Zwar ist das Thema Flash und Linux noch nicht ausgestanden aber man merkt doch schon deutliche Verbesserungen was die Performance und Stabilität betrifft.

      Ich muss wirklich sagen, dass der Treiber noch nie so stabil war wie er jetzt ist. Selbst die Darstellungsfehler in Firefox und Thunderbird wurden ausgemerzt. ;-)

      Nach meiner Analyse sind 37 Grafikkarten anhand der ASIC-ID hinzugekommen. AMD gibt da mal richtig Gas. ;-)

      Jedoch ist der Installer in der Konsole wie auch als GUI für die Erstinstallation immer noch verbesserungswürdig. Es wird leider immer noch unzureichend nach installierten Paketen für den Bau des fglrx-Kernelmodul abgefragt. Wenn jedoch alles vorhanden ist, geht es ruck zuck und ohne mucken.

      Zu Deiner Arbeit (besonders das Skript sei hier zu erwähnen) und all den anderen Themen bezüglich openSUSE kann ich wie immer nur sagen….fantastisch.

      Bislang hatten sämtliche Deiner Anmerkungen, Tipps und Ratschläge Hand und Fuß.

      Bleibt mir nur zu sagen: “Bitte, bitte mach weiter so.”

      Danke. ;-) Früher gab es interessante Zeitschriften mit abgedruckten Codezeilen oder Anleitungen zum Ausprobieren, die ich gerne gekauft habe. Heute ist das kaum vorhanden oder wird nur angerissen, was ich sehr schade finde. Daher recherchiere ich selber und halte die interessanten Themen mit Anleitung im Blog fest. ;-)

      Schauen wir mal, was als nächstes kommt. :-)

      Gruß

      Sebastian

  3. Hallo Sebastian,

    kann mich nur und wieder bedanken. Ich habe das neue Script zu 10.9 natürlich sofort genutzt. Mit dem gleichen Ergebnis. Der Link ist http://sprunge.us/ZVDP. Ich füge mal ein Installationsprotokol an:

    0. SuSE 11.3 bleibt installiert
    1. ./makerpm-ati-10.8.sh -u
    2. Probe:
    rpm -qa | grep -E ‚fgl..‘
    -> keine Ausgabe
    3. ./makerpm-ati-10.9.sh -i
    ->einige Warnmeldungen beim kompilieren
    ->Neustart
    4. fglrxinfo
    -> keine Ausgabe
    fgl_glxgears
    ->“Using GLX_SGIX_pbuffer“ – sonst nix
    -> Neustart
    5. aticonfig –initial
    -> „Uninitialised file found, configuring‘
    „Using /etc/X11/xorg.conf“
    „Saving…“
    6. fglrxinfo usw -> s.Punkt 4
    -> Neustart
    7. ./make… -c single
    -> … „unitialised file found…“
    -> Neustart
    8. s.P. 4.
    9. ./make… –kms no
    -> Neustart
    10. s. P. 4.
    ->Neustart
    11. Zum Überfluss:
    ./make– ux
    -> „…doesn’t need…‘
    reboot und
    12. aticonfig –intital
    -> „found fglrx primary divice section“
    „Using /etc/X11/xorg.conf“
    „Saving…“
    -> Neustart
    13. s.P.4.

    Puuuh! Eigentlich hatte ich gehofft weniger Probleme zu haben als bei nvidia mit dem kompilieren und vdpau und …. aber es bleibt sich wohl gleich. Trotzdem glaube ich das die lüfterlose Ati-Karte
    schon gut ins Wohnzimmer-Pc paßt.

    Danke nochmals für Deine superschnelle Reaktion und all Deiner Arbeit am Script.

    Grüsse Klaus

    • Hallo Klaus,

      ich habe dein Bericht eingehend studiert und kann keine Auffälligkeit erkennen. Der Treiber ist korrekt geladen und der X-Server hat ihn auch eingebunden und geladen. Soweit ist alles richtig!

      Kannst du bitte einmal diesen openGL-Test aufrufen:

      glxgears

      Hier sollten 3 Räder mit einer angenehmen und ruckelfreien Geschwindigkeit laufen.

      Und rufe nochmal zur Sicherheit auch nochmal das hier auf:

      glxinfo -l | grep rendering

      Es sollte eine Ausgabe im günstigsten Fall wie diese erscheinen:

      direct rendering: Yes

      Wenn bis hier hin alles in Ordnung ist, dann hat wohl der fglrxinfo und fgl_glxgears eine Macke.

      Gruß

      Sebastian

      • Hallo Sebastian!

        Nein, keine der Befehlszeilen bringen irgendeine Ausgabe und arbeiten auch nach Minuten noch im Nirvana, also Abbruch mit STRG-C. (Als User eingeloggt)

        Das fglinfo oder fgl_glxgears eine Macke haben, ich weiß nicht. Ich habe 2 SuSE-Versionen mit mehreren Deiner Scripts (10.7-10.9) durchlaufen lassen: Mit gleichem Ergebnis.

        glxgears lief allerdings nach der Installation von 11.3 mit dem Treiber von SuSE. Aber ich weiß jetzt keine Zahlen mehr zu nennen, die im Terminal angezeigt worden sind.

        Dank
        Klaus

        • Hallo Klaus,

          was sich mir jetzt die Frage stellt, ob du vielleicht irgendetwas außer ATI-Treiber aktualisiert hast?

          Welche Repos hast du eingebunden?
          zypper lr -d | curl -F ’sprunge=<-‚ http://sprunge.us -s 2>&1

          Kannst du bitte die Liste der installierten Pakete von deinem Rechner hochladen lassen:
          rpm -qa | sort | curl -F ’sprunge=<-‚ http://sprunge.us -s 2>&1

          Bitte die beiden ausgegebenen Links hier posten. Danke.

          Gruß

          Sebastian

          • Guten Morgen!

            Ich habe die gewünschten Daten nach sprunge geschickt. Mit -s am Ende bekam ich aber den Link nicht ausgegeben, hab’s also weggelassen.

            Die Repos findest Du auf http://sprunge.us/EMLF und die rpm-Pakete auf http://sprunge.us/SYKS.

            Inzwischen wird die letzte Liste wohl sehr lang sein, weil ich mich bei Packman ‚umsehe‘ was es für kde4 so gibt. Den Ati Treiber habe ich aber vorher, gleich nach der Installation von SuSE 11.3, installiert. Aber -wenn nötig- installiere ich nochmal neu.

            Schönen Sonntag
            Klaus

          • Moin Klaus,

            mir ist gerade beim Durchgehen der Liste aufgefallen, dass du Compiz installiert hast. Kannst du bitte einmal Compiz deinstallieren? Evtl. hängt es damit zusammen.

            Folgender Befehl löscht die Compiz-Pakete:

            zypper rm compiz compiz-branding-openSUSE compiz-gnome compiz-kde4 compiz-manager compiz-plugins-main

            Gruß

            Sebastian

  4. Pingback: openSUSE 11.3 – proprietären Grafik-Treiber ATI Catalyst 10.8 als RPM installieren

  5. Hallo,

    nee, keine Änderung bei fglrxinfo usf. nach dem Löschen der compiz-Pakete und Neustart.

    Aber heute morgen gab’s ein Kernelupdate. Danach erzeugten alle immerhin Fehlermeldungen. Irgendetwas geschieht also. Nach dem löschen (./make… -u) und dem erneuten installieren des Treibers (./make … -i Neustart aticonfig –initial) war alles wieder im alten Zustand: Keine Ausgabe.

    Gruß
    Klaus

    • Moin Klaus,

      Wenn es auch nicht funktioniert, dann wäre mein nächster Schritt testweise auf einer anderen Partition oder anderen Festplatte openSUSE 11.3 + Updates jedoch keine weiteren Repos aufzuspielen und das Skript einmal durchlaufen zu lassen. Wenn es dann einwandfrei läuft, dann sabotiert ein fremdes Paket den X-Server bzw. die Initialisierung des Monitors.

      Gruß

      Sebastian

  6. Pingback: Cannot get into KDE after update

  7. Hallo Sebastian,

    zuerst möchte ich mein Respekt an dich aussprechen, denn was du hier leistest ist SUPER dein Script funktioniert beim mir Hervorragend.

    nur würde ich gerne wissen warum die KDE Effekte Kugel und Explosion usw. mit ATI nicht gehen !!! hättest du ein Tipp für mich ?

    Gruß Hakan

    • Hallo Hakan,

      danke für dein Lob. ;-)

      Ich vermute mal, dass die Effekte in gewissermaßen nicht ganz kompatibel mit der OpenGL-Schnittstelle vom AMD/ATI-Treiber ist und daher nicht aktiviert werden kann. Wann diese Effekte einwandfrei funktionieren werden, kann ich leider nicht sagen und liegt in der Verantwortung von AMD.

      Gruß

      Sebastian

  8. Hallo Sebastian,
    dein Script ist echt der Hammer. So easy das Ganze. Die Installation hat perfekt geklappt. Jetzt läuft auf meiner Radeon 4250 IGP endlich der fglrx 10.9 Treiber statt dem alten 10.6 ! Danke ! :mrgreen: Gruß, Erich

  9. Hallo Sebastian!
    Ich hatte es vor Wochen schon mal mit opensuse und anderen Distris versucht, bin aber jeweils am proprietären Grafiktreiber gescheitert, die letzten Versionen gingen nicht gut. Und der freie Treiber war auch nicht prickelnd. Erst durch Deine Seite hab ich Problem und Lösung erkannt.
    Das Skript ist super! Treiber ist installiert, einiges Andere ebenso, echt easy. Endlich läuft „mein“ suse! (integrierte Grafik 4200)
    Vielen Dank!
    Gruß
    marvins

    • Hallo Marvins,

      danke für dein Feedback. Also, bist du Dank des Skriptes bei openSUSE geblieben. ;-)

      Darf ich fragen, welche Distris du ausprobiert hast?

      Gruß

      Sebastian

      • Hallo Sebastian!
        Jau, ohne Deine Hilfe wär opensuse für mich nichts gewesen, bis ein Treiber in den Repos aufgetaucht wäre, der für meine IGP passt.

        Ich habe die letzten Wochen und Monate auf einer zweiten Festplatte alle möglichen Dsitris aus Neugier und auf der Suche nach einer Distri mit passenden Treibern ausprobiert.
        Sabayon – Grafik-Treiber ging bei mir nicht, sonst sehr schön.
        Kubuntu und Linux Mint KDE und Kanotix- wie oben.
        Mandriva One – Graka-Treiber ging, aber ich fand die Einstellung nicht, auf daß die CPU im Leerlauf heruntertaktet; Mandriva find ich ansonsten klasse.
        Fedora – die Sache mit den Repos und dem Installieren war mir zu aufwendig. Sicher ne gute Distri für Leute mit mehr Durchblick.
        Und dann noch ein paar Abkömmlinge mit XFCE und ähnlichen Desktops, zwar sehr schnell aber im Vergleich zu KDE und Gnome mir zu unkomfortabel.

        „Produktiv“ setz ich grade auf der „richtigen“ Festplatte Windows 7 64bit und Linux Mint Gnome ein. Das Windows 7 ist, wie ich finde, recht gut geworden, allerhand Software läuft gut drauf; aber es ist halt wieder die Welt der langen Lizenztexte für allerhand Software, die man mal kostenfrei, mal nicht zur Nutzung überlassen bekommt (ich würd auch in der Linuxwelt Geld berappen, so ist das nicht, aber man verschone mich bitte mit diesem exklusiven Lizenzengejodel selbst für Freeware). Und Linux Mint mit Gnome war eine Flucht aus KDE, nachdem dieser in den ersten 4er-Versionen bei mir doch recht instabil war, zudem funzte hier der Grafiktreiber. Außerdem ist Linux Mint für mich komfortabel zu bedienen.

        Linux war für mich „früher“ immer gleich zu setzen mit suse.
        Ich bin froh, diese Umschau gemacht zu haben: Es gibt inzwischen viele Distris, die sich schnell installieren und einfach bedienen lassen, die Zeiten, in denen Anfänger wegen kryptischer Befehle flüchteten, sind (fast) vorbei. Das läßt mich hoffen, dass Linux mehr Verbreitung findet.
        Und nachdem ich nun weiß, wie ich für opensue den Grafiktreiber installiert krieg und KDE 4 nicht nur schön, sondern auch stabil geworden ist, steht einem Umzug nichts mehr im Wege.

        Und dann ham wer wieder opensuse mit KDE und allet löppt gut iss!
        Dir nochmals vielen Dank!

        Gruß
        marvins

  10. Hi Sebastian,
    habe nach einiger Zeit suchen deine Seite gefunden und find sie echt gut. Auch das erstellen der rpm hat gut funktioniert, aber ich kann die rpm nicht insallieren. Die Konsole gibt aus
    „bild of kernel module failed“
    „Building/installation of fglrx kernel module failed! try again by calling „/usr/bin/fglrx-kernel-build.sh“ manually“
    doch auch wenn ich das mache kommt nur ein failed.
    kannst du mir weiter helfen?

    Gruß
    Alex

    • Hallo Alexander,

      hast du ein Update auf den neuen Kernel 2.6.34.7-0.3 gemacht?

      Wenn ja, dann benötigst du ein Patch. Das Skript makerpm-ati-10.9.sh habe ich heute morgen aktualisiert und beinhaltet schon den Patch.

      Falls du das RPM selber baust, dann schau mal im Troubleshooting.

      Gruß

      Sebastian

  11. Hallo Sebastian!
    Danke für die schnelle Antwort und Aktualisierung des Skripts. Ich hab noch eine Frage dazu.

    Hab ich es richtig verstanden, dass ich die „xorg.conf“ Dateie kopieren soll und nach der
    Deinstallation und späteren Installation des Treibers wieder in den selben Ordner kopieren soll?

    Oder wird bei der Neuinstallation nicht eine neue Konfigurationsdatei generiert, wie sonst auch?

    Im Voraus Danke für deine Antwort.
    Gruß
    Bernhard

    • Hallo Bernhard,

      falls du die Konfiguration manuell angepasst hast (z.B. Modeline, HorizSync, VertRefresh, Mode, usw.), dann solltest du sie sichern. Andernfalls brauchst du es nicht zu sichern.

      Bei einer Neuinstallation wird keine Konfiguration mehr angelegt. Das war einmal. :-)

      Gruß

      Sebastian

      • Vielen Dank nochmal!
        Und schon wieder muss ich dich nerven. :mrgreen:
        Wenn ich jetzt das neue Skript herunterlade wird es unter „sh.1“ und „sha.1“ gespeichert.
        Bsp. Ausgabe nach dem Download: „makerpm-ati-10.9.sh.1“ saved

        Sollte ich vllt. vorher das alte Skript löschen und wenn ja wie, oder muss ich da irgendwie bei den Befehlen etwas anpassen?

        gruß
        Bernahrd

  12. Vielen Dank für den Patch
    Ich arbeite schon lange mit Linux, aber der compile-error hat mich vor ein großes Problem gestellt, für das du mit deinem Script eine einfache und schnelle Lösung bereitgestellt hast!
    Heute morgen noch, habe ich mir überlegt, woher ich jetzt den patch herkriege und schon heute Vormittag hast du die Lösung!
    Auf den proprietären Treiber bin ich noch wegen seiner guten Stromsparmechanismen angewiesen, die open-source Treiber sind da leider noch nicht so gut.

    Vielen Dank noch mal
    Wolfgang

    • Hallo Wolfgang,

      das nenne ich doch mal schnell! ;-) Dieser Patch wurde auf der LKML und auf der openSUSE-ML angesprochen und eine Teillösung vorgestellt. Ich habe daraus einen Patch für den ATI-Installer erstellt und getestet. Nach einer Reihe von Grafiktests habe ich es für stabil befunden und online gestellt. ;-)

      Gruß

      Sebastian

      • Eben, derartigen Support bekommt man sonst eigendlich nur als gut zahlender Geschäftskunde, andererseits ist es schon irgendwie frech, dass das openSUSE Team einfach so ohne Vorwarnung geschätzte 30% aller user-Installationen unbenutzbar macht…
        Wie auch immer, das einzige, was ich mir noch gerne zusammenbasteln würde, wäre, dass nach jeglichen Kernelupdates automatisch fglrx-kernel-build.sh ausgeführt wird, inzwischen wird das nämlich fast schon anstrengend, nach jedem Kernelupdate…
        Ich bin hier für 4 Opensuse Rechner verantwortlich, teilweise als Server, Teilweise als Office Systeme ;)
        Hab mir schon überlegt, die updates automatisch durchzuführen, allerdings kann dann sowas passieren wie bei dem letzten Update, aber auch schlimmeres ^^
        Werd mich mal umsehen, vielleicht vermissen auch andere so ein Feature, wenn ich fündig werde, werde ich es hier posten.
        Grüße
        Wolfgang

        • Hallo Wolfgang,

          Eben, derartigen Support bekommt man sonst eigendlich nur als gut zahlender Geschäftskunde, andererseits ist es schon irgendwie frech, dass das openSUSE Team einfach so ohne Vorwarnung geschätzte 30% aller user-Installationen unbenutzbar macht…

          Das openSUSE-Kernel-Team bzw. das openSUSE-QA-Team testen den Kernel bevor er freigegeben wird. Leider haben sie den ATI-Treiber zum Selberbauen nicht getestet. Da wäre erst recht der Compiler-Fehler aufgefallen und ggfs. ein Workaround hätte im Security-Note stehen müssen, was ja nicht der Fall war.

          Wie auch immer, das einzige, was ich mir noch gerne zusammenbasteln würde, wäre, dass nach jeglichen Kernelupdates automatisch fglrx-kernel-build.sh ausgeführt wird, inzwischen wird das nämlich fast schon anstrengend, nach jedem Kernelupdate…

          Werd mich mal umsehen, vielleicht vermissen auch andere so ein Feature, wenn ich fündig werde, werde ich es hier posten.

          Ich bin zur Zeit an der Implementation dieses Feature, dass bei einem Rechnerstart überprüft, ob ein fglrx-Kernelmodule vorliegt. Falls es nicht existiert, wird das fglrx-Kernelmodule automatisch neu gebaut UND geladen. Nur Geduld. ;-)

          Falls dir dazu noch was einfällt, was man umsetzen kann. Nur her damit. :-)

          Ich bin hier für 4 Opensuse Rechner verantwortlich, teilweise als Server, Teilweise als Office Systeme ;)
          Hab mir schon überlegt, die updates automatisch durchzuführen, allerdings kann dann sowas passieren wie bei dem letzten Update, aber auch schlimmeres ^^

          Da bin ich ja mit 3 openSUSE-Rechner noch im Rückstand. :-)

          Gruß

          Sebastian

          • Verdammt, hätte ich das gewusst ;) hab mich gerade hingesetzt und etwas mit sowas rumexperimentiert, allerdings habe ich mit dem coden noch wenig Erfahrung und komme deshalb langsam voran.
            Besonders, wie man auf die richtige Weise herausfindet, ob der Kernel geupdated wurde, frage ich mich…
            Wo speichert man nur die alte Kernel-Version? Ich hab mir einen Spaß gemacht und versucht, sie direkt in dem Script selbst zu speichern und mit sed zu ersetzen, aber das ist ein ziemlicher Hack und unübersichtlich :D
            Guten Abend/Morgen, je nach dem ;)

          • Hallo Wolfgang,

            ich finde es schon klasse, dass du dich mit awk und sed auseinandersetzt. :-) Aber das ist im Grunde gar nicht nötig. ;-) Denn der Pfad zum fglrx /lib/modules/$(uname -r)/extra/fglrx.ko ist immer gleich. Man muss nur prüfen, ob das Kernelmodul noch existiert.

            Ich habe das kleine Rebuildskript schon fertig. Nur an der Implementierung eines Initskript bin ich gescheitert, weil in der Regel xdm (kdm) sofort gestartet ist, obwohl die Abhängigkeit zum Rebuildskript gegeben war. Also, war KDE schon fertig geladen, während das neue fglrx-Kernelmodul erst später fertig war. So, konnte der X-Server den fglrx-Treiber gar nicht erst laden. Könnte auch wegen Upstart ein Problemchen werden. Für mich war die einzige Lösung es direkt im Initskript vom xdm das Rebuildskript zu starten, dann klappte es 1A.

            Jetzt bin ich an der Installation des Rebuildskript dran. Danach werde ich es ausgiebig testen und stelle es dann online zum Download. Das Sorglos-Paket ist bald vollständig. ;-)

            Gruß

            Sebastian

          • Hallo Wolfgang,

            ich habe das Skript aktualisiert und es bringt jetzt die Installation eines Rebuild-Skript mit. :-) Ich habe es die ganze Zeit mehrfach ausprobiert und er baut jedes Mal das fglrx-Kernelmodul nach einem Neustart neu, sobald ein Kernel-Update durchgeführt wurde. ;-)

            Die Installation des Rebuild-Skript ist denkbar einfach:

            ./makerpm-ati-10.9.sh -irs

            Du kannst auch ein Kernel-Update simulieren. :-) Starte den Rechner im Runlevel 3 und führe folgende Kommandos aus:

            rmmod fglrx
            rm /lib/modules/$(uname -r)/extra/fglrx.ko

            Dann starte den Rechner per reboot nochmal neu und *tata* der X-Server startet mit dem neugebauten fglrx-Treiber. :-)

            Gruß

            Sebastian

  13. Pingback: Anonymous

  14. Moin Sebastian, hab gestern Abend / Nacht nach mehreren Versuchen von 10.7 auf 10.9 upzudaten (hab Deinen Blog von oben bis unten studiert und nix half, controll center zeigte beständig 10.7) ein neues System 64-bit aufgesetzt, allerdings von Anfang an die Standarttreiber ATI/Nvidia ebenfalls nicht installiert! komplett upgedatet (neuer Kernel) und Deinem Hinweis folgend KDE 4.5 aufgespielt. Danach dein „neues“ Skript angewendet (sonst installiere ich eigentlich immer zu Fuß, war aber schon spät in der Nacht) und was soll ich sagen einfach klasse!
    Noch eine kleine Frage, ich habe eine Datenpartition die ich als user mounten möchte, und bekomme immer die Meldung das nur Root das tun kann (etc/fstab ist entsprechend bearbeitet) Bei älteren Versionen von SUSE war das kein Problem eine IDEE??? Will diese Partition weiterhin zur Datenspeicherung benutzen (Bilder …) und nur bei bedarf einbinden!

    Grüße
    Frank

    • Das hier ist zwar kein Supportforum, aber Sebastian ist bestimmt nicht sauer :D
      Poste bitte erst mal deine fstab (wenn du das aus datenrechtlichen Gründen nicht willst, wenigstens die entsprechende Zeile),
      du kannst auch mal den Yast2- Partitionierer ist ausprobieren:
      Partition bearbeiten, mount at sonstwas auswählen
      fstab optionen -> Durch Benutzer einhängbar machen, Nicht bei Systemstart einhängen
      dann klappt es auch, habs gerade versucht, ansonsten wären die richtigen Einstellungen
      /dev/deinepladde /dein/mountpoint ext3 noauto,user,acl 1 2

  15. Hallo

    Erstmal höchtes lob für die tolle Website !

    Leider funktioniert bei mir der Patch auch nicht. Ich bin aber auf den ATI-Treiber angewiesen, weil ich meinen HTPC an einem Fernseher betreibe.

    Folgen die Fehler-Ausgabe
    /usr/src/kernel-modules/fglrx ~/Downloads
    make: Entering directory `/usr/src/linux-2.6.34.7-0.3-obj/x86_64/desktop‘
    make -C ../../../linux-2.6.34.7-0.3 O=/usr/src/linux-2.6.34.7-0.3-obj/x86_64/desktop/.
    CC [M] /usr/src/kernel-modules/fglrx/kcl_ioctl.o
    make: Leaving directory `/usr/src/linux-2.6.34.7-0.3-obj/x86_64/desktop‘

    ******************************
    Build of kernel module failed!
    ******************************

    Was mach ich falsch.

    LG Jörg

  16. Hallo Sebastian!

    Heute möchte ich mich zweimal für Deine Arbeit am ATI-Grafiktreiber bedanken.

    Ich hatte mir im Juli einen neuen Rechner gekauft und wie auf alle meine Rechner als Betriebssystem Linux (hier Opensuse 11.3) draufgespielt. Ein klein wenig 3D sollte schon sein und die Qual der Wahl führte zu einer Grafikarte von ATI, einer Radeon HD 5700 Series.
    Nach der Installation lief der Standard-Treiber und mein Graka-Lüfter auf Höchstdrehzal.

    Nach ewigem hin und her im Internet und auf den ATI-Seiten, da war nix was mit meiner ATI laufen wollt. Dann fand ich Deine Seite:

    OpenSUSE 11.3 – proprietären Grafik-Treiber ATI Catalyst 10.7 als RPM installieren
    Von Sebastian Siebert | Veröffentlicht am: 26. Juli 2010

    Ausgeführt und die Graka lief! Danke!

    Alle Kernel-Updates habe ich mit dem script makerpm-ati-10.7 überstanden, bis gestern 2.6.34.7-0.3-desktop x86_64 mein System grafisch zum erliegen brachte. Und wieder hat mir Deine Seite mit dem script makerpm-ati-10.9.sh zu einem funktionierenden System verholfen. Dafür nochmals Danke!

    Aber es ist schon eine worse situation ohne vernünftige Unterstüzung der Hersteller und der Kernelverwalter.

    Gruss
    michael

    Aktuelle Konfiguration:
    Mainboard: GIGABYTE GA-X58A-UD3R

    Prozessor (CPU): Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
    GeschwiKdigkeit: 1 596,00 MHz
    Kerne: 8

    Grafikarte:ATI Radeon HD 5700 Series

    Gesamter Arbeitsspeicher: 5,8 GiB
    Kernel: Linux 2.6.34.7-0.3-desktop x86_64
    Distribution: openSUSE 11.3 (x86_64)
    KDE: 4.4.4 (KDE 4.4.4) „release 2“

    • Hallo Michael,

      danke für dein Lob. ;-)

      Naja, solange AMD in Sachen Linux-Treiber ein eigenes Süppchen kocht, wird sich die Situation leider auch nicht verbessern. Das openSUSE-Kernel-Team fühlt sich da leider nicht zuständig und das openSUSE-QA-Team kann in kurzer Zeit nicht alles durchtesten. Ich kann höchstens nur die Umstände abmildern.

      Gruß

      Sebastian

  17. Hi Sebastian,
    danke erstmal für Deine Mühe, solch einen Service unentgeltlich hier im Netz anzubieten!
    Deine Skripte haben bis dato immer perfekt funktioniert. Ich hatte bis zum aktuellen Update die 10.8er Version drauf. Nach dem Update war dann Schluss mit lustig und die Kiste startete in die Konsole. Hm, also 10.8 deinstalliert und neu gestartet und mal beim Sebastian nach einer neuen Version geschaut, Volltreffer. Jetzt bekomme ich aber trotz deines Skriptes den oben beschriebenen Compilerfehler, X-Windows startet auch, aber mit allerlei seltsamen Nebeneffekten, wie z.B. äußerst träges Scrolling im FF, keine graphischen Effekte und keine korrekte graphische Unterstützung für mein VM-Ware usw.. Ich hatte zwischenzeitlich für eines deiner Skripte die gepatchte X-Server Variante installiert und für die 10.8 eigentlich wieder runtergekickt, weil auch die Repo nicht mehr erreichbar war. Danach gab’s dann Probleme mit den Updates, so dass ich die RPM db reparieren musste. vielleicht hatte ich zu viel deinstalliert, keine Ahnung. Ich wollte Dir nur die Vorgeschichte schildern vielleicht hängt das alles zusammen. Den Link mit den 10.9er Skript generierten Infos findest du unter http://sprunge.us/hQLG

    Danke für deinen Enthusiasmus!
    Gert

    • Hallo Gert,

      ich muss mal schauen, ob der Patch auch für openSUSE 11.2 (64-bit) gelten muss (wovon ich ausgehe) und werde das Skript entsprechend aktualisieren. Danke für die Rückmeldung.

      Gruß

      Sebastian

        • Hallo Sebastian,
          deine Bemühungen sind von Erfolg gekrönt, super Job!!!

          Ich sitze hier wieder vor einem vernünftig arbeitenden System. Was mich allerdings noch beschäftigt: Ich muss immer die xorg.conf umbenennen oder wegschmeissen, damit ich nach der ATI-Installation nicht in der Konsole lande, hast du eine Ahnung, woran das liegen könnte? Ich hatte mir Ende des Sommers statt der X1650 die HD3450 eingebaut und seitdem tritt das auf. Mit Sax2 und -a -r -u usw. hatte ich schon versucht, erstmal ohne den ATI-Treiber eine neue xorg.conf zu erstellen und dann den Treiber nochmal installiert. Hat aber alles nix gebracht. Nur ohne die conf boote ich in die GUI.

          Gruß

          Gert

          • Wenn man schlauer ist als ich 8) , liest man das Troubleshooting, bevor man überflüssige Fragen stellt: mit dem -c single parameter hat sich das Problem xorg.conf erledigt!

            Nochmals danke für diese Seite!!!

  18. Lieber Sebastian
    Leider hatte ich mit deinem Skript kein Glück. Hier der Verlauf:

    Suse 11.3 64 neu installiert
    ati-driver-installer-10-9-x86.x86_64.run ausgeführt. Alles läuft perfekt volle 3D Unterstützung.
    Nach dem ersten Update geht alles nur noch langsam. Also dein Skript ausprobiert (makerpm-ati-10.9.sh)
    Fehlermeldungen:
    mktemp: zu viele Schablonen (was immer das auch heißen mag) – temp Verzeichnis wird trotzdem angelegt.
    Patch Datei nicht gefunden (Error: Patch doesn’t applied) , obwohl sie im selben Verzeichnis wie makerpm-ati-10.9.sh lag.
    Daraufhin Fehlermeldung im Skript abgeschaltet.
    Neuer Fehler:
    ./makerpm-ati-10.9.sh: Zeile 1002: ./ati-installer.sh: Datei oder Verzeichnis nicht gefunden
    Datei war im temp-Verzeichnis.
    Skript von dort aufzurufen versucht:
    ./ati-installer.sh –buildandinstallpkg
    Fehlermeldung:
    Unrecognized parameter “ to ati-installer.sh
    Nach einigem Herumprobieren mit
    ./ati-installer.sh — –buildandinstallpkg
    folgende Fehlermeldung erhalten:
    Error: Packaging scripts failed to identify current distro/version. Please provide a distro/version from –listpkg as a parameter
    –listpkg liefert alle möglichen Distributionen, außer Suse. Offenbar kann der ATI-Installer gar keine Suse-Packages erzeugen.
    Nun bin ich vollig ratlos.

    Weißt du einen Rat?

    LG
    Paul

    • Hallo Paul,

      nach deiner Schilderung hört sich das nach einem etwas größeren Schaden an. Entweder ist die Festplatte, das Dateisystem (auf der openSUSE liegt) oder der Arbeitsspeicher betroffen. Hast du sie alle schon überprüfen lassen? Ist der Rechner evtl. übertaktet worden?

      Gruß

      Sebastian

      • Lieber Sebastian!

        Meine Hardware ist kerngesund. Die Radeon HD 5770 gerade mal einen Monat alt. Übertaktet ist nichts. Alles läuft perfekt, bis auf die 3D Treiber, die nach Installation der Catalyst Treiber via ATI Installer vorerst auch perfekt liefen, bis eben zum ersten Kernel-Update. Aber bis dahin ist Tux in Tuxracer Extreme nur so über die Piste gerutscht!

        Dein Skript erkennt allerdings meine Grafikkarte erst gar nicht. Deshalb habe ich begonnen es zu editieren und nach und nach die Fehlermeldungen abzuschalten, was zum schrittweise geschilderten Ergebnis geführt hat.
        Vielleicht hilft dir (und mir!) der Output deines (ungeänderten) Skripts weiter:

        Check for supported graphics card on this machine …
        mktemp: zu viele Schablonen
        „mktemp –help“ gibt weitere Informationen.
        Created directory fglrx-install.QGBEZP
        cat: /common/lib/modules/fglrx/build_mod/fglrxko_pci_ids.h: Datei oder Verzeichnis nicht gefunden
        05:00.0 VGA compatible controller [0300]: ATI Technologies Inc Juniper [Radeon HD 5700 Series] [1002:68b8]
        Error: This graphics card is not supported by ATI Catalyst 10.9 [ FAILURE ]

        In der Hoffnung auf eine Lösung
        Paul

        • Hallo Paul,

          dann stimmt etwas mit dem Tool mktemp aus dem Paket coreutils nicht. Wenn das Tool kein Verzeichnis zurück liefert, dann fliegt auch das Skript auf die Nase.

          Kannst du bitte folgendes in der Konsole als root testen, ob er ein temporäres Verzeichnis ausgibt oder wieder nur meckert:

          mktemp -d -u --tmpdir=/tmp

          und auch die Ausgabe von RPM bitte hier posten:

          rpm --whatprovides --info -q `which mktemp`

          Gruß

          Sebastian

          • Problem gelöst!

            LEERZEICHEN im Pfadnamen deines Skripts führten zu all den Fehlern!
            Aus einem Verzeichnis ohne Leerzeichen im Namen gestartet funktioniert alles wunderbar.

            Vielen Dank für dein Engagement und die Hilfe.
            LG
            Paul

  19. Pingback: ATI Drivers - New Release, 10.9

  20. Hallo Sebastian,

    danke für Deine ausgezeichnete Arbeit. Habe Dein Script zum 2. Mal für einen Rechner mit ASUS M2N-E SLI / AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ / 4GB RAM / ASUS EAH 5570 / openSUSE11.2 genutzt. Das Kernelupdate vom 24.9. war der Anlass. Hatte am 25.9. noch Probleme mit dem Scrollen (sehr langsam) und entstellten Bildern (dvbcut). Nach der heutigen Treiberinstallation läuft das System wieder bestens.

    Gruss,
    Steffen

  21. Pingback: openSUSE 11.3 – Kernel 2.6.34.7 im Update-Repo verfügbar

  22. Hallo,
    auch von mir als erstes ein Danke für
    a) Das Script
    b) Die möglichen Fehler und deren Behebung (Ursache).

    Leider bekomm ich aber auch damit das Compositing nicht zum laufen.
    fglrxinfo zeigt mir brav den ati-treiber an, das konfigurationsprogramm zeigt 10.9 an.
    OpenGLIsUnsave hab ich nicht in der Config stehen, aber der Reiter für Erweitert ist ausgegraut und ich bekomme nur die Meldung „Compositing is not supported on your system.“

    Irgend eine Idee wie ich Compositing wieder aktivieren kann?

    Gruß
    Torsten

    • Hallo Torsten,

      um das Problem mit dem Compositing auf die Spur zu kommen, benötige ich einen umfassenden Bericht von deinem System. Daher bitte einmal folgendes in der Konsole ausführen und den ausgegebenen Link hier posten:

      su -c 'sh makerpm-ati-10.9.sh -ur'

      Gruß

      Sebastian

      • Mit dem Infos habe ich gerade heraus gefunden, das ich in der kwinrc Compositing einfach auf true setzen kann, dann funktioniert es. Aber eine wirkliche Lösung des Problems ist es meiner Meinung nach nicht?!

        • Hallo Torsten,

          danke für den Bericht.

          Folgendes ist mir aufgefallen:

          /etc/X11/xorg.conf.d/50-device.conf
          Bitte mal bei Driver „radeon“ eine Raute vorne weg setzen, um die Option zu deaktivieren.

          Ansonsten hast du ja schon in der kwinrc das Compositing auf true gesetzt. Ist denn der Reiter „Erweitert“ nun aktiv, oder immer noch nicht?

          Gruß

          Sebastian

          • Hallo Sebastian,

            ich habe den radeon-treiber jetzt deaktiviert. Der Reiter „Erweitert“ ist nun aktiv, und ich kann einstellungen vornehmen. Auch scheint das Compositing zumindest teilweise zu funktionieren.

            Allerdings ist auf dem Tab „Alle Effekte“ die Liste leer, und ich schaff es auch nicht die Kontrollleiste durchsichtig zu bekommen, während ich inzwischen zumindest die Fenster Transparent bekomme, wenn ich sie verschiebe (das war vorher nicht).

            Ob alles Ok ist weiss ich deshalb leider noch immer nicht :)

            Gruß
            Torsten

  23. Hallo Sebastian,
    nach dem letzten Kernelupdate bei 11.3 war es schier zum Verzweifeln, Deine Bemühungen rund um ati, fglrx und Dein Script mit Patch haben meine Kiste wieder flott gemacht, ich hätte es nicht hinbekommen. Also besten Dank für Deine Arbeit, Du hilfst vielen.
    Gruß Martin

    • Hallo Martin,

      es freut mich, dass ich dir auch mit meinem Skript helfen konnte. :-)

      Apropos: „Also besten Dank für Deine Arbeit, Du hilfst vielen.“
      Ich habe ganz ehrlich nicht gedacht, dass es weit aus mehr sind, die davon betroffen sind. In diesem Monat knacke ich die 10 GB-Traffic alleine für diese Webseite und 15.000 Besucher alleine im September. *schluck* 8-O

      Trotzdem bleibt mir treu. ;-)

      Gruß

      Sebastian

  24. Ich habe eine propietäre FGLRX-Version des FirePro-Treibers. Dieser ist insbesondere für die OGL-optimierten Graka-Versionen von ATI wie die meinige von Bedeutung. Auf diesen habe ich dein „Trouble-Shoot“ Punkt 8) angewendet und siehe da: FUNKTIONIERT!!! :-P

    Habe Dank für die ausführliche Anleitung und Deine Unterstützung für uns (l)user! Ich habe nach dem letzten Kernel-Patch an meiner Linux-Eignung und an DER Linux-Eignung für PRODUKTIVSYSTEME allgemein gezweifelt, aber es zeigte sich wieder: es gibt doch immer wieder Kompetenz, Fleiß und Hilfe bei „Open-Source“! Damit ist zumindest der letztere Zweifel wieder einigermaßen „behoben“. Ich wundere mich nur warum es bei so wenigen Probleme gibt. Haben die keinen Kernel-Patch???

    Gruß,
    Ichae

    • Hallo Ichae,

      danke für dein Lob. ;-)

      Nun ja, die Anleitung ist einfach so entstanden und durch die vielen Rückmeldungen wurde das eine oder andere ergänzt. ;-) Dabei war die 1. Anleitung zu ATI Catalyst 9.11 noch recht rudimentär. :-)

      Deine Frage zu den wenigen Problemen: Evtl. haben die anderen User andere Quellen, woraus sie ihre Treiber bauen können. Aber ich habe die letzten Tage festgestellt, dass der Kernel-Bugfix in allen Distros für Probleme mit dem ATI-Treiber gesorgt haben. Nur die schnelle Nachricht kann schlimmeres verhindern, wie man mögliche Probleme beim Kernel-Update aus dem Weg geht. ;-)

      Gruß

      Sebastian

  25. It works! Although I had to use translate.google.com to translate it in English, thanks a lot!

  26. Pingback: PLEASE HELP! Graphics Driver Not Loading

  27. Hallo Sebastian,

    mir ist noch eine kleine Sache bei der Deinstallation der ATI Treiber aufgefallen. Zumindest bei meinem Uninstall durch dein Skript bleiben die (dann verwaisten) Links in /etc/init.d/* auf ein ATI Skript übrig. Ansonsten habe ich nix zu meckern. :wink: Tolles Skript und weiter so! :-D

    Grüße, Nino.

    • Hallo Nino,

      danke für dein Lob. Kannst du mir noch den Link zu einem ATI-Skript in /etc/init.d/* nennen. Ich war mir eigentlich sicher gewesen, dass ich alle Dateien und Verzeichnisse vom ATI-Installer erwischt habe. :-)

      Gruß

      Sebastian

      • Hallo Sebastian,

        ich habe heute keinen Zugriff mehr auf den Rechner, deshalb muss ein etwas schwammiges Gedächtnisprotokoll ausreichen. :wink: Ich meine dass die Links in den Runleveln 3 u. 5 existieren (also /etc/init.d/3 u. /etc/init.d/5) und auf ein Skript namens /etc/ATI/atievent (oder so ähnlich) verweisen. Falls dich diese Angaben nicht weiterbringen kann ich morgen Abend nochmal genauer nachschauen.

        Grüße, Nino.

        • Hallo Nino,

          jetzt verstehe ich dich. ;-)

          Da fehlt vor dem Löschen die Ausführung von „insserv -r atieventsd“, um auch die angelegten Links des Initskriptes zu löschen. Danke für den Hinweis. ;-)

          Gruß

          Sebastian

          • Hallo nochmals,

            genau das war es. 8) Aber nichts zu danken, kommt ja schließlich mir und anderen Benutzern auch wieder zugute. :wink:

            Grüße, Nino.

    • Hallo Nico,

      vielen Dank für den Hinweis.

      Der Hotfix sollte auch das Problem mit dem Bau eines Kernelmoduls wegen dem neuen Kernel-Update beheben, was aber leider total vermurkst wurde und so überhaupt nicht funktioniert. :roll:

      Deswegen stand auch auf der Webseite:

      Note! This hotfix is provided as is and is not supported by AMD. It has not completed full AMD testing and is only a driver update.

      Das war eindeutig ein Schnellschuss gewesen und wurde auch so gar nicht getestet.

      Gruß

      Sebastian

      PS: BTW, hat AMD gestern das Skript „makerpm-ati-10.9.sh“ heruntergeladen. Ich würde mal sagen: AMD, du wurdest erwischt. :-)

      @AMD: I know you have downloaded the script „makerpm-ati-10.9.sh“. Caught with the hand in a cookie jar! ;-)

  28. (Für SuSE 11.2ler)

    Hallo Sebastian,

    Zunächst auch von mir nochmal meine Anerkennung für Deine Bemühungen. Vor einem Jahr oder etwas mehr hatte sich schon der Besuch bei Dir gelohnt und auch diesmal bin ich wieder voll belohnt worden. Habe nach Deinem letzten Script keine Probleme mehr – wollte aber dennoch meinen Fall kurz schildern, da er einigen Nutzern von SuSE 11.2 helfen könnte.

    Habe also noch 11.2 laufen und einen Kernelupdate verpasst (bekommen)
    wonach der installierte Treiber 10.6 nicht mehr lief. Das Modul wurde nicht mehr geladen. Folgendes ist immerhin entgegen einem Beispiel irgendwo weiter oben konsistent:


    uname -a:
    Linux linux-e8l7 2.6.31.14-0.1-desktop #1 SMP PREEMPT 2010-09-17 11:32:00 +0200 x86_64 x86_64 x86_64 GNU/Linux

    rpm -qa kernel*

    kernel-debug-devel-2.6.31.14-0.1.1.x86_64
    kernel-desktop-devel-2.6.31.14-0.1.1.x86_64
    kernel-source-2.6.31.14-0.1.1.noarch
    kernel-syms-2.6.31.14-0.1.1.x86_64
    kernel-xen-devel-2.6.31.14-0.1.1.x86_64
    kernel-desktop-2.6.31.14-0.1.1.x86_64
    kernel-default-devel-2.6.31.14-0.1.1.x86_64

    Poste das nur weil an irgendeiner Stelle der Bau des Modules fehlschlug. Jedenfalls wollte der alte nicht mehr und so habe ich mich durch Deine einzelnen „veralteten“ Beiträge zu diesem hier gehangelt mit dem Gefühl, dass das alles für meine SuSE 11.2 nicht mehr gültig ist. Stimmt aber nicht. Alles hat für die SuSE 11.2 genauso geklappt wie für die eigentlich angesprochene SuSE 11.3 – Inklusive des ‚arch_compat_alloc_user_space()‘-Patch und des automatischen ‚re-build‘-Patches. Wobei ich letzteres ja erst nach einem weiteren Kernel-Update beurteilen kann. :wink:

    Kann mir natürlich vorstellen, dass Du nicht auch noch einen Rüchwärts-support für all Deine Arbeit geben kannst und willst. Wenn es allerdings allgemeine Gültigkeit hat, könnte man ja vielleicht irgendwo etwas auffälliger ein Hinweis anbringen, dass sich mit den neuesten Scripts auch Nutzer von älteren SuSE 11.x angesprochen fühlen dürfen. Oder kann man das so pauschal nicht sagen?

    Gruß und vielen Dank jedenfalls

    Matthias

    • Hallo Matthias,

      Zunächst auch von mir nochmal meine Anerkennung für Deine Bemühungen.

      Danke. ;-)

      Vor einem Jahr oder etwas mehr hatte sich schon der Besuch bei Dir gelohnt und auch diesmal bin ich wieder voll belohnt worden.

      Vor einem Jahr? Öhm … da gab es dieses Blog noch gar nicht, sondern erst seit dem 05.12.2009. ;-)

      Poste das nur weil an irgendeiner Stelle der Bau des Modules fehlschlug. Jedenfalls wollte der alte nicht mehr und so habe ich mich durch Deine einzelnen “veralteten” Beiträge zu diesem hier gehangelt mit dem Gefühl, dass das alles für meine SuSE 11.2 nicht mehr gültig ist. Stimmt aber nicht. Alles hat für die SuSE 11.2 genauso geklappt wie für die eigentlich angesprochene SuSE 11.3 – Inklusive des ‘arch_compat_alloc_user_space()’-Patch und des automatischen ‘re-build’-Patches. Wobei ich letzteres ja erst nach einem weiteren Kernel-Update beurteilen kann. :wink:

      Lass dich nicht von dem Titel verwirren. Denn eigentlich betrifft dieses Problem ebenfalls auf openSUSE 11.2 und daher gilt auch dort der Patch. :-) Das Rebuild-Skript wird beim nächsten Kernel-Update die Bewährungsprobe bestehen, so oft wie ich das getestet habe. ;-)

      Kann mir natürlich vorstellen, dass Du nicht auch noch einen Rüchwärts-support für all Deine Arbeit geben kannst und willst. Wenn es allerdings allgemeine Gültigkeit hat, könnte man ja vielleicht irgendwo etwas auffälliger ein Hinweis anbringen, dass sich mit den neuesten Scripts auch Nutzer von älteren SuSE 11.x angesprochen fühlen dürfen. Oder kann man das so pauschal nicht sagen?

      Schau mal oben in der Einleitung im 5. Absatz. Dort steht schon seit längerem geschrieben, dass es auch für openSUSE 11.1 und 11.2 gilt. In der Anleitung habe ich auch bei speziellen Befehlen die zugehörige openSUSE-Version erwähnt. Kann man das wirklich überlesen?! Sonst muss ich das mal auffällig einfärben oder entsprechende openSUSE-Symbole am Textanfang einfügen. :-)

      Ich bemühe mich hin und wieder auch unter openSUSE 11.2 zu testen, ob es dort funktioniert und auch die gleiche Gültigkeit besitzt.

      Also, solange openSUSE 11.1, 11.2, 11.3 offiziell unterstützt wird, werden auch meine jeweils neusten Skripte darauf laufen. Daher kannst du ruhig alle kommenden Skripte auch auf openSUSE 11.2 verwenden/anwenden.

      Gruß

      Sebastian


      • Schau mal oben in der Einleitung im 5. Absatz. Dort steht schon seit längerem geschrieben, dass es auch für openSUSE 11.1 und 11.2 gilt. In der Anleitung habe ich auch bei speziellen Befehlen die zugehörige openSUSE-Version erwähnt. Kann man das wirklich überlesen?! Sonst muss ich das mal auffällig einfärben oder entsprechende openSUSE-Symbole am Textanfang einfügen. :-)

        :oops: *hüstl* – also ich habs jedenfalls geschafft, die Stelle zu überlesen. Tut mir leid. Brauchst das bestimmt auch nicht deutlicher hervorzuheben an dieser Stelle. Hab die Einleitung wohl deswegen übersprungen, weil ich die Prozedur mit den Skripten ja schon kannte und da wird man wohl übermütig.

        Matthias

  29. Pingback: Permanent solution to FGLRX/Kernel 2.6.34.7-0.3.1 issue?

  30. Hallo Sebastian,
    noch ein Hinweis zu dem Patch: patch -p0 funktioniert nur im bezug auf die Namensgebung bei Dir, im Beispiel ati-10.9.

    Wenn ich den Ati-Installer „entpacken“ lasse, so generiert er ein Verzeichnis fglrx-install.XXXXX, XXXXX ist das Resultat von (vermutlich …) mktmp.

    Also heißt es: cd fglrx-install.XXXXX, dann patch -p1 < ../ati-10.9-replace-function-compat_alloc_user_space.patch

    sonst klappt es nicht.
    Unabhängig davon: herzlichen Dank für die Mühe mit der Seite und Deine Ausführungen – super!

    Dieter

      • Hallo Sebastian,
        tja, wer lesen kann :-). Firefox hat bei mir die Zeile umgebrochen, daher bin ich nur bis –extract gekommen ;-))).

        Davon abgesehen macht „meine“ Zeile aber genau davon unabhängig.

        Trotzdem, prima Seite – wenn der fglrx mit der 11.3 auf meiner Maschine nur ansatzweise so gut liefe, wie er mit der 10.3 performt hat, könnte ich richtig zufrieden sein.

        Bis irgendwann mal,

        Dieter

  31. hi Sebastian,

    ich hoffe du kannst mir helfen.

    mein frisch installiertes suse 11.3 incl updates bleibt nach der ati treiberinstallation einfach schwarz, weiß echt nicht mehr weiter.
    hab alles streng nach Anleitung mit deinem Script installiert und auch schon „./makerpm-ati-10.9.sh -kms no“ probiert aber leider ohne erfolg.

    hier mein

    Merci schonmal

    • Hallo Alex,

      bei dir ist der fglrx-Kernelmodul nicht geladen.

      Kannst du bitte im Failsafe-Modus booten und in der Konsole als root folgendes eingeben:

      modprobe fglrx

      Danach mal testen, ob das fglrx-Kernelmodul geladen wurde:

      lsmod | grep fglrx

      Danach nochmal neustarten.

      Gruß

      Sebastian

      • moin,

        so nach modprobe spuckt lsmod folgendes aus:

        fglrx 2239301 0

        hoffe du kanst was damit anfangen

        Gruß Alex

        • Hallo Alex,

          hat der Neustart gar nichts gebracht?

          Ansonsten mal das Rebuild-Skript installieren, es prüft beim Start, ob der fglrx-Kernelmodul gebaut bzw. geladen ist.

          ./makerpm-ati-10.9.sh -irs

          Gruß

          Sebastian

          • ne hat leider alles nix gebracht…

            Rebuildt -Script ist auch schon installiert. Weiß echt ned was ich machen soll =(
            wie kann ich denn den ursprünglichen Treiber wiederherstellen ? so das ich wenigstens KDE wieder starten kann

            Gruß Alex

          • Hallo Alex,

            vielleicht hilft diese Lösung. Im Runlevel 3 alles vom ATI Catalyst komplett entfernen zu lassen und erneut installieren:

            ./makerpm-ati-10.9.sh -u
            ./makerpm-ati-10.9.sh -i
            ./makerpm-ati-10.9.sh -c single

            Dann neustarten:

            reboot

            Falls nach dem Schritt immer noch nicht funktioniert, dann würde ich vorerst auf den Radeon-Treiber ausweichen. Siehe im Troubleshooting Punkt 7. Vorher aber den ATI Catalyst entfernen lassen.

            ./makerpm-ati-10.9.sh -u

            Gruß

            Sebastian

  32. Hallo Sebastian!
    Ich möchte mich sehr herzlich für deine Arbeit bedanken. War schon kurz davon die ATI Radeon HD in die Tonne zu kloppen, Durch Deine Scripte/Patches läuft das Ding endlich so wie erwartet. Ich habe leider nicht mehr die Zeit mich stundenlang mit Fehlersuche zu beschäftigen („Selbst, und das ständig“) Nochmals vielen Dank!!
    MfG
    Markus

    • Hallo Markus,

      danke dir auch für dein Feedback. ;-) Deine Schilderung kommt mir sehr bekannt vor und hatte die gleiche Erfahrung vor 2-3 Jahren auch gemacht. Mit einem Unterschied, dass sich keiner für ATI + openSUSE zuständig gefühlt hat und ich die Lösung mühsam zusammen suchen (frickeln) musste. :evil: Heute sieht die ganze Geschichte anders aus. Seit ich von Windows XP auf openSUSE 11.0 umgestiegen bin, habe ich eine Menge Erfahrung mit dem System (bis einschließlich openSUSE 11.3) sammeln können. Irgendwann muss ja mal einer mit einem (ultimativen) Skript für die einfachere Installation des ATI Catalyst Treiber anfangen. ;-) Dank zahlreicher Feedbacks von den openSUSE-User ist das Skript heute recht robust geworden. Aber das hast du sicherlich schon gemerkt. :-)

      Gruß

      Sebastian

  33. Hallo Sebastian!

    Ein ganz dickes Dankeschön für dein Script makerpm-ati-10.9.sh!

    Als nach dem Kernel-Update und Neustart nur die Konsole hochkam, dachte ich „Stimmt, da war ja was mit der ati“ … als dann aber das Bauen des fglrx-Treibers abbrach, dachte ich nur an die Worte eines Freundes „Ach, du und dein Frickel-Linux“.

    Danke, dass du mir die Arbeit abgenommen hast!

    Gruß aus HH,
    Jan

  34. Hallo Sebastian,

    erst einmal herzlichen Dank für Dein prinzipiell sehr hilfreiches Script. Nachdem ich jahrelang mit SuSE und nVidia zufrieden war, habe ich mich jetzt für eine ATI – Graka entschieden und nach dem Einbau auch gleich die damals brandneue SuSE 11.3 installiert.
    Jetzt sollte endlich auch der „richtige“ Treiber zur bestmöglichen 3D – Leistung führen und dabei stösst man natürlich unweigerlich auf Dein Script.

    Mein erster Versuch schlug fehl, weil meine Kernel – Version nicht zu den zusätzlich installierten kernel-source, kernel-devel, etc. Paketen passte.

    Nachdem ich alle Versionen auf 2.6.34.4-0.1 gebracht hatte, lief das Script durch. Nach dem Neustart erschien der (leicht defekte) Login – Screen, aber meine Tastatur (Cherry G85) war komplett deaktiviert.
    Beim Neustart im „safe mode“ wurden mir dann Dateisystemfehler in /usr, /var und /tmp gemeldet. Sonst lief alles (bis auf die zu geringe Auflösung).
    Ich habe daraufhin versucht im normalen Modus in den Runlevel 3 zu booten und konnte nachvollziehen, dass die o.g. Dateisysteme offenbar read-only eingehängt waren.
    Vermutung: HDD-Fehler (war schon etwas älter).

    Heute habe ich SuSE 11.3 auf einer brandneuen Platte installiert und wiederum Dein Script laufen lassen, wobei ich dieses Mal darauf geachtet habe, dass alle kernel-* Versionen übereinstimmten. Diesmal ging die Sache mit dem Patch in die Hose. Die erste 11.3 – Version (DVD – Image vom 17.07.2010) verwendet einen Kernel 2.6.34-12-desktop. Offenbar meint Dein Script, dass diese Version den Patch benötigt, was natürlich nicht stimmt.

    Ich habe daraufhin die aktuellen Kernel – Pakete (2.6.34.7) installiert und Dein Script erneut laufen lassen. Ergebnis: alles läuft durch, aber nach dem Neustart ist die Tastatur für einige Minuten nicht verfügbar, beim Login bekomme ich eine Meldung über einen schwerwiegenden Fehler und Dateisystemfehler nach dem Neustart. Wie immer läuft im „safe – mode“ alles, wenn auch mit geringerer Auflösung.
    Ich kann wiederum nachvollziehen, dass beim Booten im „normalen“ Mode die Dateisysteme schreibgeschützt sind und somit natürlich allerlei Dienste hängenbleiben.

    Nun bin ich irgendwie mit meinem Latein am Ende. Was bitte hat der fglrx mit meinen Dateisystemen zu tun?
    Vielleicht siehst Du ja einen Zusammenhang. Hier ist jedenfalls der Report, den ich allerdings nur im „safe-mode“ erstellen kann.

    http://sprunge.us/SchO

    Vielen Dank und Gruß,
    Marc

    • Hallo Marc,

      deine Schilderung ist ja wirklich abenteuerlich.

      Also laut deinem hochgeladenen Bericht sieht es mit dem fglrx-Treiber gut und korrekt aus. Meine Antwort zu deiner Frage, ob der fglrx mit dem Dateisystem zu tun hat, lautet: gar nichts.

      Wenn das Dateisystem als Read-Only gemountet wird, dann stimmt da definitiv etwas mit dem Dateisystem nicht und würde mir an deiner Stelle da genauer hinschauen.

      Hast du die Festplatte/Partition auch von einer Rettungscd prüfen lassen?
      Wie hast du das Dateisystem formatiert und eingebunden?

      fdisk -l
      mount | sort
      cat /etc/fstab

      Gruß

      Sebastian

      • Hallo Sebastian,
        Du bist ja richtig fix! Danke für die schnelle Antwort. Ich verwende beruflich Software für mehrere 10k€ und da ist der Support oft deutlich schlechter.

        Wenn ich das System im Safe-mode boote, kann ich mir natürlich alle Partitionen ansehen. Alle sind mit ext4 (bis auf Swap) formatiert und ordnungsgemäß eingebunden (rw, acl, user_xattr). Hier die Ausgabe von „mount | sort“:

        debugfs on /sys/kernel/debug type debugfs (rw)
        devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
        /dev/sda1 on / type ext4 (rw,acl,user_xattr)
        /dev/sda3 on /usr type ext4 (rw,acl,user_xattr)
        /dev/sda5 on /opt type ext4 (rw,acl,user_xattr)
        /dev/sda6 on /tmp type ext4 (rw,acl,user_xattr)
        /dev/sda7 on /var type ext4 (rw,acl,user_xattr)
        /dev/sda8 on /local type ext4 (rw,acl,user_xattr)
        /dev/sda9 on /home type ext4 (rw,acl,user_xattr)
        devtmpfs on /dev type devtmpfs (rw,mode=0755)
        fusectl on /sys/fs/fuse/connections type fusectl (rw)
        proc on /proc type proc (rw)
        rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
        securityfs on /sys/kernel/security type securityfs (rw)
        sysfs on /sys type sysfs (rw)
        tmpfs on /dev/shm type tmpfs (rw,mode=1777)

        Auch in /var/log/boot.msg gibt’s keine Auffälligkeiten.

        Beim „normalen“ Booten habe ich das Problem, dass ich mich nicht einloggen kann und Dateien wie /var/log/boot.msg nicht erstellt werden. Die Partition ist ja – warum auch immer – offenbar nicht beschreibbar.

        Um den Fehler einzukreisen, habe ich mal ausprobiert, welcher Bootparameter dafür verantwortlich ist, dass man im „failsafe-Modus“ arbeiten kann. Es ist einzig „x11failsafe“. Scheint also doch irgendwas mit dem Grafiktreiber zu tun zu haben. Hast Du eine Idee?

        Leider ist es heute schon wieder recht spät geworden. Ich werde morgen Abend nochmal die Platte leerputzen, SuSE installieren, erst auf den aktuellen Kernel updaten und dann den fglrx mit Deinem Skript installieren. Damit kann ich sicher ausschließen, dass noch irgendwelche Artefakte von meinem ersten vergeblichen Versuch im System herumgeistern.

        Gruß,
        Marc

  35. Pingback: Switching to openSuse

  36. Hallo Sebastian!
    Yuuhuu, ich bekomme endlich eine Fehlermeldung unter fglrxinfo, fgl-glxgears ruckelt mit 633.800FPS und glxgears rast mit 2538.197FPS! Vielmehr als Nix!

    Nach vielen Versuchen und Extrem-Stöbern im Internet haben folgende Zeilen in der xorg.conf geholfen:

    Section „DRI“
    Mode 0660
    EndSection

    Um es nochmal zu verifizieren, habe ich erneut SuSE 11.3 installiert, Dein Script laufen lassen und aticonfig (http://sprunge.us/XfiL. Danach habe ich (nur noch) diese Zeilen in die xorg.cong eingefügt. (http://sprunge.us/idGV).

    fglrxinfo gibt jetzt folgende Meldung:

    libGL error: open uki failed (Operation not permitted)
    libGL error: reverting to (slow) indirect rendering
    display: :0.0 screen: 0
    OpenGL vender string usf.

    Hast Du vielleicht eine Idee welcher error das ist? Und natürlich wie ich ihn beseitigen kann?! Stimmen die Benutzerrechte immer noch nicht?

    Nun bekommst Du soviel Dank in den Mails zu lesen, trotzdem nochmal:
    Danke Sebastian

    Klaus

    • Moin Klaus,

      ja, da stimmt offenbar mit den Rechten noch nicht so ganz.

      Füge noch in deiner Konfigurationsdatei /etc/X11/xorg.conf in der Section „DRI“ noch folgende Zeile ein:

        Group "video"

      Im Endeffekt sollte es so aussehen:

      Section "DRI"
        Group "video"
        Mode 0660 
      EndSection

      Prüfe bitte in der Konsole, ob der aktuelle User auch in der Gruppe „video“ ist:

      groups

      Dann nochmal den Rechner neustarten.

      Gruß

      Sebastian

  37. Hi,
    leider führt die Zeile in der xorg.conf:

    Group „video“

    zum alten Zustand zurück und ich erhalte keine Ausgabe mehr von fglrxinfo usf. Selbst

    Mode 0666

    führt zu diesem Zustand, obwohl ich doch mehr Rechte erteile. Als User gehöre ich aber zur Gruppe „video“ (laut yast).

    Langsam verzweifle ich doch. Hm, warum ist das mit ATI so schwer, eine GraKa zu installieren? Und was ist atiuki? Fragen, fragen… -ich hoffe natürlich, Du weißt die Antworten.

    Grüße Klaus

    • Hallo Klaus,

      momentan bin ich selber auf dem Schlauch, wo da das Problem liegen könnte. Denn laut diesem Troubleshooting lässt sich das Problem mittels Mode 0666 beheben, was du ja schon durchgeführt hast. Aber das scheint bei dir überhaupt keine Wirkung zu haben.

      In wenigen Tagen, vielleicht auch schon morgen, wird ein neuer AMD-Treiber (ATI Catalyst 10.10) veröffentlicht. Evtl. ist das Problem bei deiner Grafikkarte bekannt und haben es da schon behoben.

      Gruß

      Sebastian

  38. Hallo Sebastian.

    Habe mich heute mal wieder dran gesetzt und Dein neu überarbeitetes Skript ausprobiert.

    Bislang kann man alles unter die Kategorie „Hervorragend“ einsortieren.

    Durch die Deinstallation des alter alten Version wurde auch der Anzeigefehler im amdccle aufgehoben. Hatte sich mal wieder eine falsche Version eingeschlichen. (10.8 obwohl 10.9 installiert war.)

    Aber wie gesagt, bis jetzt alles super. Hoffen wir mal, dass die AMD-Entwickler sich beim nächsten Treiber auch so ins Zeug legen wie Du. :wink:

    Besten Dank.

    • Hallo Hennes,

      dein Lob reißt ja gar nicht ab und nehme es gerne zur Kenntnis. ;-)

      In den nächsten Tagen kommt ein neuer ATI-Treiber von AMD. Mal schauen, was bis dahin alles verbessert wurde. AMD hat ja bereits schon das Skript von mir heruntergeladen und getestet. :mrgreen: Ich bin gespannt, ob ein Teil meines Skriptes in ihrem Installer sich wieder findet oder in irgendeiner anderen Art implementiert wurde. ;-)

      Gruß

      Sebastian

  39. Hallo Sebastian,

    danke für das Skript lief problemlos durch nur eine Sache is noch kryptisch. Wenn ich normal als User eingeloggt bin die Tests mache kommt folgendes:
    peter@darkthrone:~> glxinfo -l | grep rendering
    direct rendering: No
    peter@darkthrone:~> fgl_glxgears
    Using GLX_SGIX_pbuffer
    8369 frames in 5.0 seconds = 1673.800 FPS
    10379 frames in 5.0 seconds = 2075.800 FPS
    11166 frames in 5.0 seconds = 2233.200 FPS
    11181 frames in 5.0 seconds = 2236.200 FPS
    XIO: fatal IO error 11 (Resource temporarily unavailable) on X server „:0.0“
    after 320908 requests (320904 known processed) with 0 events remaining.
    peter@darkthrone:~> fglrxinfo
    display: :0.0 screen: 0
    OpenGL vendor string: ATI Technologies Inc.
    OpenGL renderer string: ATI Radeon HD 5700 Series
    OpenGL version string: 1.4 (4.0.10188 Compatibility Profile Context)

    und jetzt das ganze mit su in root gewechselt:
    peter@darkthrone:~> su
    Passwort:
    darkthrone:/home/peter # glxinfo -l | grep rendering
    direct rendering: Yes
    darkthrone:/home/peter # fgl_glxgears
    Using GLX_SGIX_pbuffer
    10573 frames in 5.0 seconds = 2114.600 FPS
    XIO: fatal IO error 104 (Connection reset by peer) on X server „:0.0“
    after 44165 requests (44164 known processed) with 0 events remaining.
    darkthrone:/home/peter # fglrxinfo
    display: :0.0 screen: 0
    OpenGL vendor string: ATI Technologies Inc.
    OpenGL renderer string: ATI Radeon HD 5700 Series
    OpenGL version string: 4.0.10188 Compatibility Profile Context

    Das interessante ist Rendern als root funktioniert als user nicht. Heisst als root laufen alle auf Linux zum Laufen gebrachten Spiele als user nicht. Was kann man da tun?

    Schöne Grüße

    Peter

    • Hallo Peter,

      kannst du bitte ein Bericht vom Skript erstellen und hochladen lassen:

      su -c 'sh makerpm-ati-10.9.sh -ur'

      Den ausgegebenen Link bitte hier posten, dann schaue ich es mir gerne an.

      Gruß

      Sebastian

  40. Hallo nochmal,

    manchmal ist es wie verhext. Ich danke dir wenn du schon angefangen hast diese 1000 Zeilen zu lesen. Naja jedenfalls hab ich mal das mit dem Hotfix gelesen :-). Sehr spassig wenn große firmen auch mal auf freie mitarbeiter zugreifen … . Jedenfalls probierte ich den aus . Zudem war da noch ein nvidia-nouveau- treiber der da glaub ich nix verloren hat. Interessanterweise hat er nicht funktioniert. also deswegen hab ich dann nochmal fglrx deinstalliert und installiert mit einem funktionierenden HOtfix namens makerpm-ati-10.9.sh :-) und Neustart und siehe da.
    peter@darkthrone:~> glxinfo -l | grep rendering
    direct rendering: Yes
    naja is wohl wie in der chemie der Katalysator geht (fast) unverändert aus der Reaktion hervor.

    Danke trotzdem und nochmals gute arbeit ein grundsolides bash Skript.

    Grüße
    Peter

    P.S.: Hoffentlich kommt das wirklich das Kernelupdate im Ati treiber pack

    • Hallo Peter,

      es freut mich, dass es bei dir doch noch geklappt hat. ;-)

      Der Hotfix von AMD funktioniert trotz integriertem Kernel-Patch bei unserem neuen Kernel gar nicht. Eigentlich sollte er das Problem ja beheben. Schauen wir mal, ob AMD fristgerecht heute ein weiteren funktionierenden ATI-Treiber hinterher schiebt. Falls es nicht funktionieren sollte, dann nehme ich es auseinander und lasse es von meinem Skript erneut patchen. ;-)

      Gruß

      Sebastian

  41. Pingback: openSUSE 11.3 – Kernel 2.6.34.7-0.4 im Update-Repo verfügbar

  42. Hallo Sebastian,

    jetzt da die neue Kernelversion da ist war ich gespannt was dein rebuild Skript leistet.
    Phänomenal!! Mal schauen was ATI da jetzt liefert. :-D Nochmals Lob für so ein geniales Skript.

    grüße
    Peter

    • Hallo Peter,

      ja, danke für dein Lob. ;-) Ich hatte schon vorher eine ganze Reihe von Tests mit dem Rebuild-Skript durchgeführt und war guter Dinge, dass es klappen wird. Die Bewährungsprobe mit dem gestrigen Kernel-Update hat das Skript bestanden. :-) Dann kann man sich ja jetzt entspannt zurücklehnen.

      Gruß

      Sebastian

  43. Klasse Jetzt habe ich wieder 3D und Ati Treiber Danke Sebastian weiter so !

    Ludger

  44. Hallo Sebastian,
    tolles Script, hat auch sofort funktioniert. Mein Problem liegt vielleicht auch woanders. wenn ich den Xen-Kernel starte bekomme ich einen schwarzen Schirm. Keine Änderung bei nomodeset. Schalte ich kms aus mit ./makerpm-ati-10.9.sh -kms no, dann kommt schwarzer Schirm mit sichtbaren Cursor links oben.
    Über ssh komme ich natürlich an die Maschine ran und gebe ein:
    su -c ’sh makerpm-ati-10.9.sh -ur‘
    script bleibt stehen bei
    OUTPUT: /usr/sbin/hwinfo –monitor
    Die Prozesse Xorg und hwinfo belegen je 100%, gut dass 4 Kerne verhanden sind :wink:
    hwinfo abgewürgt, xorg schleift weiter, normalen Kernel gebootet und script lokal ausgeführt.
    Ergebnis auf http://sprunge.us/LLBe

    Übrigens bin ich früher mit Xen noch nie bis zum Einrichten einer VM gekommen, ich wollte nach dem Kernelwechsel nur mal sehen, ob ich jetzt weiter komme. Schwarzer Schirm war allerdings noch nie dabei.
    Wäre toll, wenn du einen Tipp für mich hast.

    Vielen Dank und Grüße
    Franz

    • Hallo Franz,

      da du leider nur den Bericht vom Kernel-Desktop hast, läuft es dort auch einwandfrei.

      (Glaskugel-Modus an) Ich tippe auf ein nicht gebautes fglrx-Kernelmodul zum Kernel-Xen. (Glaskugel-Modus aus) :-)

      Daher würde ich folgendes machen. In den Runlevel 3 mit dem Kernel-Xen booten und dann sich als root einloggen. In der Shell gibst du noch folgendes ein:

      fglrx-kernel-build.sh
      modprobe fglrx

      Dann zum Abschluss noch überprüfen, ob das gebaute fglrx-Kernelmodul geladen werden konnte:

      lsmod | grep fglrx

      Ergänzung:
      Übrigens habe ich gerade gesehen, dass noch ATI Catalyst 10.7 drauf ist. Ggfs. vorher mal ATI Catalyst 10.7 komplett löschen lassen (Nicht vergessen /etc/X11/xorg.conf sichern):

      ./makerpm-ati-10.9.sh -u

      Dann erneut ATI Catalyst 10.9 installieren:

      ./makerpm-ati-10.9.sh -i

      Gruß

      Sebastian

  45. Hallo Sebastian,
    danke für die Tipps. Es wird verworrener.

    1) wo finde ich die alte version? ich habe bereits vor der 1. Nachricht
    ./makerpm-ati-10.9.sh -u
    ./makerpm-ati-10.9.sh -i
    durchgeführt und dies gestern mit dem xen-kernel nochmals wiederholt
    ich probier mal, die Ausgabe alc code zu quoten:
    Check for running this script as root ... [ OK ]
    Grab openSUSE Version ...
    openSUSE Version = 11.3 (113) [ OK ]
    Get the architecture of this machine ...
    Architecture: x86_64 (AMD64) [ OK ]
    Remove the ATI Catalyst from this system ...
    Following package will be removed:
    => Name: fglrx64_7_5_0_SUSE113
    Summary: X Window display driver for the ATI graphics accelerators
    Version: 8.771
    Release: 1
    Architecture: x86_64
    Size: 131226158 bytes
    Installed on: Sun Oct 17 19:05:58 2010

    Are you sure to remove the above-named package? yes/no [y/n]: y
    The package was removed successfully!
    [ OK ]
    Try to remove the existing ATI files and directories manually ...
    Remove /etc/ati ... [ OK ]
    Remove /usr/share/ati ... [ OK ]

    dh. es wurde der aktuelle driver gelöscht und anschließend wieder installiert.

    Der schwarze Schirm mit dem Cursor links oben erscheint bei Starting kdm.
    2) xenkernel init 3
    clara:~ # lsmod | grep fglrx
    fglrx 2522457 7
    agpgart 42985 1 fglrx
    clara:~ # rpm -qa | grep -E ‚fglrxG01|fglrxG02‘
    clara:~ # rpm -qa | grep -E ‚fglrx‘
    fglrx64_7_5_0_SUSE113-8.771-1.x86_64
    nicht mehr durchgeführt:fglrx-kernel-build.sh, da dies sicher Teil von
    ./makerpm-ati-10.9.sh -i
    ist.
    3) Infos mit xenkernel, init 3
    su -c ’sh makerpm-ati-10.9.sh -ur‘
    bleibt wieder bei hwinfo stehen. hwinfo direkt aufgerufen ergibt:
    >bios.4.3: ddc info
    angeschlossen ist ein alter mitsubishi diamond pro 1010e analoger Monitor. Wieso hwinfo da hängt und mit dem Desktopkernel nicht, ist mir unverständlich.

    Aufruf von hwinfo –monitor auskommentiert ergibt: http://sprunge.us/ESLO

    Du bist nicht zufällig auch ein Xen-Meister?

    Grüße aus dem sonnigen Süden
    Franz

    • Hallo Franz,

      ich habe gestern abends nochmal Tante Google gefragt und die Ergebnisse recherchiert und eingelesen. Wie es aussieht, unterstützt der fglrx-Kernelcode noch kein XEN, was auch dein hochgeladener Bericht beweist.

      Ich habe versucht im Quellcode des fglrx-Kernelcode einige Schalter umzulegen. Er konnte es zwar unter dem Kernel-Xen bauen. Jedoch nach einem Reboot startet er mitten im Bootvorgang wieder neu. Da scheinen einige Funktionen nicht ganz kompatibel zu sein. Ein Patch könnte evtl. Abhilfe schaffen. Leider gibt es zur Zeit keinen für den aktuellen Treiber. :-(

      Gruß

      Sebastian

  46. Hallo Sebastian,
    vielen Dank für deine vorbildliche Unterstützung. Xen muss also noch etwas warten.

    Eine Problem habe ich noch. Ich möchte den proprietären Driver nur beim xen-kernel entfernen.

    Ich habe mir die Ausgaben deines Scripts gespeichert und etwas angesehen:
    Während beim Buildprozess immer xen-Verzeichnisse angegeben waren, kommt
    INSTALL /usr/src/kernel-modules/fglrx/fglrx.ko
    was nicht xenabhängig ist.
    Zum Schluss werden beide Kernelvarianten angezeigt, ein Liste die mich an menu.lst erinnert, aber viel mehr Module enthält. flgrx ist aber nicht dabei, das wird nachgeladen.
    fglrx.ko ist vorhanden in:
    clara:/etc/modprobe.d # ls -l $(locate fglrx.ko)
    -rw-r–r– 1 root root 4819799 Aug 5 17:24 /lib/modules/2.6.34-12-desktop/extra/fglrx.ko
    -rw-r–r– 1 root root 4946269 Oct 17 21:35 /lib/modules/2.6.34.7-0.4-desktop/extra/fglrx.ko
    -rw-r–r– 1 root root 4994740 Oct 18 19:56 /lib/modules/2.6.34.7-0.4-xen/extra/fglrx.ko

    Wo kann ich das Nachladen von den proprietären Driver beim Xen-Kernel verhindern bzw. den Standard Opensourcedriver statt dessen eintragen?
    Über .xinitrc ließe sich benutzerabhängig was einstellen, aber das kommt zuspät, denn ich seh ja den Anmeldeschirm nicht mehr, wenn ich mit runlevel5 starte.

    Es ist länger her, dass ich mich so tief eingewühlt habe. Ohne deine Hilfe wäre gar nichts gelaufen.

    Grüße
    Franz

    • Moin Franz,

      du kannst auch zur Bootzeit mit dem Kernel-Xen in den Runlevel 3 gehen. Im Bootmenü die Bootoption unter „module“ die Zahl 3 ergänzen.

      Das fglrx Kernelmodul vom Kernel-Xen-System entfernen:

      rmmod fglrx

      Dann das fglrx Kernelmodul löschen:

      rm /lib/modules/2.6.34.7-0.4-xen/extra/fglrx.ko

      Das war es eigentlich schon.

      Das Laden des Standard Open-Source-Treiber (hier: radeon) im Xen wird durch die systemweite Konfiguration /etc/modprobe.d/fglrx.conf per Blacklist verhindert, um gewisse Konflikte mit dem fglrx-Kernelmodul zu umgehen.

      Also musst du die Datei /etc/modprobe.d/fglrx.conf entfernen und ersatzweise in Grub in der Datei /boot/grub/menu.lst die Bootoption vom Kernel-Desktop mit folgender Option ergänzen:

      radeon.blacklist=yes

      Ich erlaube mir mal ein paar Zeilen der /boot/grub/menu.lst aus deinem Bericht zu entnehmen und die entsprechende Änderung als Beispiel einzupflegen:

      ###Don't change this comment - YaST2 identifier: Original name: linux###
      title Desktop -- openSUSE 11.3 - 2.6.34.7-0.4
          root (hd0,0)
          kernel /vmlinuz-2.6.34.7-0.4-desktop root=/dev/system/root resume=/dev/system/swap splash=silent quiet showopts vga=0x345 radeon.blacklist=yes
          initrd /initrd-2.6.34.7-0.4-desktop
      

      Somit hast du den radeon-Treiber beim Kernel-Desktop ausgeschlossen und beim Kernel-Xen kann er ohne Probleme geladen werden.

      Vorsorglich kannst du auch den fglrx-Treiber in Grub für den Kernel-Xen ausschließen lassen:

      fglrx.blacklist=yes

      Gruß

      Sebastian

  47. Hallo Sebastian,

    Super: die Driverauswahl über das Bootmenü!

    menu.lst angepasst, desktop hat funktioniert, bei xen musste ich kurz durchatmen, da ich wieder vor einem schwarzen Schirm war. Natürlich xorg.conf, logo!

    Keine Zeit, um xorg.conf zu zusammenstellen, dass es für beideVarianten passt. Aber ein kleines script kopiert mir gerade den gewünschten Inhalt auf xorg.conf.

    Als guten Abschluss kann ich noch berichten, dass ich auch bei xen weitergekommen bin. Offensichtlich haben die Updates meine Hürden aus dem Weg geräumt.

    Nochmals vielen Dank und Grüße
    Franz

Die Kommentarfunktion ist geschlossen.