• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Kernel 2.6.31 ATI Treiber Installation scheitert [gelöst]

C

Critter

Member
Aus versch. Gründen habe ich jetzt bei meinen Suse 11.1 den Kernel auf 2.6.31... upgedated. Der Kernel stammt aus den Repositories/Kernel/Head
Das Problem ist jetzt aber dass ich den ATI Treiber fglrx nicht mehr kompilieren kann. Im Konsolenfenster tut er erst mal so als kompiliert er, dann beim bei Postprozessing bricht er ab und mein Konsolenfenster ist Zerschossen.
Installiert habe ich passend zum Kernel das kernel-devel Paket dass dann die Sourcen nachgezogen hat.
 
OP
C

Critter

Member
Ich konnte das Problem lösen indem ich eine Datei mithilfe der das Kernelmodul gebildet wird gepatch habe und dann neu kompiliert. Wem es interessiert

Code: 
diff -ruN fglrx-8.620.orig/firegl_public.c fglrx-8.620/firegl_public.c
--- fglrx-8.620.orig/firegl_public.c    2009-07-30 02:29:19.000000000 +0100
+++ fglrx-8.620/firegl_public.c 2009-07-30 02:47:43.000000000 +0100
@@ -1292,7 +1292,10 @@
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,26)
    p = find_task_by_pid( pid );
 #else
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,30)
    p = find_task_by_vpid( pid );
+else p = pid_task( pid, PIDTYPE_PID );
+#endif
 #endif
    if (p)
    {
 
T

Tooltime

Advanced Hacker
Warum hast du es nicht mal mit einem neueren Treiber probiert? Die aktuelle Version ist 8.65 oder Catalyst 9.9, je nach Zählweise. Einen neuen Kernel sollte man immer mit einen möglichst neuen Treiber kombinieren.
 
OP
C

Critter

Member
Also so schlau war ich auch. Das Problem hatte ich ja mit dem 9.9er
Wahrscheinlich ist der Kernel einfach zu neu. Na egal. Jetzt weis ich wo ich drehen muss.
 
T

Tooltime

Advanced Hacker
Hätte vielleicht etwas ausführlicher fragen sollen, damit es sich nicht so dämlich anhört.
Critter schrieb:
Also so schlau war ich auch.
Zum Vergrößern anklicken....
Aber erwähnt hast du das nicht. Und die interessante Frage ist halt, warum einen alten Treiber patchen anstatt den aktuellen oder wenigstens die Vorgängerversion, zumal ich mindestens 9.7 brauche damit keine Darstellungsfehler unter KDE 4.3 auftreten.
Critter schrieb:
Na egal. Jetzt weis ich wo ich drehen muss.
Zum Vergrößern anklicken....
Interessante Einstellung, denn meiner Meinung nach funktioniert das Patch nicht da es einen syntaktischen Fehler ergibt. Alternativ besteht die Möglichkeit das es mir entgangen ist, das ANSI C mittlerweile ein case-Statement kennt, ohne ein zugehörigen if-Statement zu definieren. Aber es macht dann keinen Sinn weiter zu diskutieren, getreu deinem Motto, ich weiss ja wo der Fehler liegt.
 
OP
C

Critter

Member
Also folgendes. Wenn ich hier in den Kernel Hacking Thread was rein schreibe dann nicht weil ich gestern erst den Computer entdeckt habe. Klar das wenn man einen neuen Kernel ausprobiert und man plötzlich seinen ggf. vorhandenen Grafikkartentreiber darauf kompilieren will dass man den aktuellen ausprobiert da dieser vielleicht schon an den neuen Kernel angepasst ist. Da hatte ich mir (fälschlicherweise) erspart zu erwähnen dass es sich um den 9.9er Treiber handelt.
Den Patch habe ich in einem anderen Forum gefunden und da stand dass es nicht die saubere Lösung ist, aber funktioniert.

Hmm, ok jetzt habe ich glaube verstanden was du meinst. Dir ist dieses fglrx-8.620 aufgefallen was zu einem älteren Treiber gehört. Ich habe mit diesem Patch den 9.9er gepatcht und dazu natürlich die -p1 Option des Patch Kommandos genommen.
 
T

Tooltime

Advanced Hacker
Critter schrieb:
Hmm, ok jetzt habe ich glaube verstanden was du meinst. Dir ist dieses fglrx-8.620 aufgefallen was zu einem älteren Treiber gehört.
Zum Vergrößern anklicken....
Exakt, aber es hätte ja wirklich einen triftigen Grund geben können, warum neuere Versionen nicht funktionieren können, daher die Nachfrage.
Tooltime schrieb:
as ANSI C mittlerweile ein case-Statement kennt, ohne ein zugehörigen if-Statement zu definieren.
Zum Vergrößern anklicken....
Ist natürlich Blödsinn, meinte else-Statement ohne if. Meiner Meinung nach müsste das Patch etwa so aussehen:
Code: 
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,26)
    p = find_task_by_pid( pid );
 #else
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,30)
    p = find_task_by_vpid( pid );
+#else 
    p = pid_task( pid, PIDTYPE_PID );
+#endif
 #endif
Das eingefügte #-Zeichen macht aus dem C-Code else eine Präprozessordirektive.
Hintergrund der Fragen:
  • Beim letzten Release hat es fast 2-3 Monate gedauert bis der Ati-Treiber im Repo war. Da der 9.9 auch gerade neu ist, ist wohl in nächster Zukunft auch nicht mit einem neuen Treibern von AMD zu rechnen. Ergo für das nächste Release oder für neugierige Blicke in das factory-Repo könnte eine funktionierende Anleitung nützlich sein, daher auch mein Interesse an der Sache. Bis jetzt haben mich mögliche Probleme mit Kernel Mode Settings abgeschreckt. Um so mehr war ich verwundert das ein alter Treiber funktionieren sollte
 
OP
C

Critter

Member
Mit der Änderung in eine Präprozessor Direktive könntest du recht haben. Aber da das System stabil läuft werde ich diese Version des Treibers so lassen.

Stimmt auch das ATI/AMD manchmal etwas langsam ist. Bspw als bei Suse 11.1 das Xorg 7.4 integriert wurde war der Treiber gerade so fertig geworden. Vorher hatte ich das Xorg nur aus Neugier über die repositories installiert, konnte aber den Treiber nicht kompilieren.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben