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,

     kannst du bitte das Reportskript herunterladen und ausführen lassen (Der Report wird hochgeladen):

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

     su -c ’sh ati-report.sh -u‘

     Den ausgegebenen Link bitte hier wieder posten. Dann schaue ich mir den Report mal genauer an, was da los ist.

     Gruß

     Sebastian

     • Schonmal vielen Dank. Der Report konnte erstellt werden:
       http://sprunge.us/cZLX

       • 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 ! Gruß, Erich

   • Hallo Erich,

     danke für dein nettes Feedback zum Skript.

     Gruß

     Sebastian

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.
        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

        • Jupp, hier wäre es angebracht die älteren Dateien zu entfernen.
          Folgender Befehl sollte es tun:

          rm makerpm-ati-10.9.sh*

          Gruß

          Sebastian

          • Genial!
            Hat alles super geklappt. Wieder was dazu gelernt.

            Danke nochmal.

            Schönen Gruß aus Bayern

          • Das ist doch schön, wenn es reibungslos klappt.

            In diesem Sinne: Have a lot of fun.

            Gruß

            Sebastian

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
            Guten Abend/Morgen, je nach dem

          • in etwa so ^^
            http://pastebin.com/uHr72ph3
            (ach ja vorhin bin ich wohl mit dem quoten etwas durcheinander gekommen)

          • 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
      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

    • Und es Geht doch !!!

      Ich hab nochmals das Script in einem neuen Directory downgeloaded und ausgefuhrt.

      Dann gings !

      Nochmal vielen Dank für das tolle Script

      Grüße Jörg

      • Hallo Jörg,

        danke für dein Feedback.

        Gruß

        Sebastian

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

        ich habe das Skript nochmal aktualisiert. Kannst du bitte das Skript nochmal herunterladen und die Installation anstoßen?

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

    • Hallo Steffen,

      danke für dein Lob. Ja, das Skript ist eine sehr feine Sache und nimmt eine Menge Arbeit ab.

      Gruß

      Sebastian

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

      • Hallo Sebastian,

        du findest den Bericht unter

        http://sprunge.us/OBTa

        Schon mal vielen Dank.

        Torsten

      • 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*

      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 angewendet und siehe da: FUNKTIONIERT!!!

    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. Tolles Skript und weiter so!

    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. 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. Aber nichts zu danken, kommt ja schließlich mir und anderen Benutzern auch wieder zugute.

            Grüße, Nino.

          • Okay, ich habe eben das Skript aktualisiert und hochgeladen. In der Changelog habe ich dich auch erwähnt.

            Gruß

            Sebastian

28. FYI: von AMD gibt es mittlerweile einen hotfix-Treiber für 10.9 unter
    http://support.amd.com/us/kbarticles/Pages/GPU83ATICatalystLinuxHotfix.aspx
    -> hat bei mir einige 2D-Performance-Probleme unter openSUSE 11.3 beseitigt, die ich mit 10.8 vor dem kernel-update nicht hatte.
    Den compat_alloc_user_space patch braucht der aber trotzdem noch (in leicht abgewandelter Form).

    • 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.

      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!

29. (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.

    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.

      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.
        

        *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

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

31. 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 Dieter,

      danke für dein Lob.

      Bezüglich auf das Entpacken und Patchen: Alle Wege führen nach Rom. Schau mal im Troubleshooting, dort wird eben eine andere Vorgehensweise praktiziert.

      Gruß

      Sebastian

      • 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

32. 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

33. 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. 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

34. 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

35. 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

36. Pingback: Switching to openSuse

37. 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

38. 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

39. 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.

    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. Ich bin gespannt, ob ein Teil meines Skriptes in ihrem Installer sich wieder findet oder in irgendeiner anderen Art implementiert wurde.

      Gruß

      Sebastian

40. 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

41. Hallo nochmal,

    also war jetzt nicht ganz sicher, aber hab einen Report hochgeladen in INIT 3
    http://sprunge.us/QBdG
    und einen in INIT 5
    http://sprunge.us/JLMi
    ich hoffe das hilft.

42. und schon mal danke fürs schnelle Antworten

43. 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

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

45. 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. 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

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

    Ludger

47. 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
    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

48. 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

49. 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

50. 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.