[fglrx] Pas de 3D

[bouyafa]

Bonjour,

Aujourd'hui j'ai décidé d'enlever une option de mon kernel (celle qui dérangeait udev depuis quelques temps). J'ai donc recompilé mon kernel, puis mon driver ati-drivers. Seulement depuis pas moyen de récupérer la 3D. J'ai recompilé le MEME kernel, et j'ai booté dessus avant de compiler ati-drivers, alors je ne comprends pas trop là ...

[bouyafa]

Euh mais ça interesse si peu de monde que ça ?

[boozo]

'alute

jette un oeil là-dessus voir si c'est mieux ?
_________________
" Un psychotique, c'est quelqu'un qui croit dur comme fer que 2 et 2 font 5, et qui en est pleinement satisfait.
Un névrosé, c'est quelqu'un qui sait pertinemment que 2 et 2 font 4, et ça le rend malade ! "

[bouyafa]

Re,

En fait, non, j'avais déjà vu ça, et contrôlé mes options kernel. Quant à eselect opengl, je l'avais aussi déjà fait. Le plus génant est que c'est le même kernel, et tout est en version identique. Je n'ai fais que enlever une option et j'ai recompilé le noyau. Dans le message que j'ai, il y a un WARNING sur les versions xorg et ati-drivers, mais là aussi je n'ai rien touché, je rajouterai même que j'ai tout maské depuis un certain temps.

Par contre, je n'ai pas écrasé mon ancien kernel. J'ai repoussé le bzImage en /boot/{même kernel}b .

[xelif]

selon le message d'erreur que tu as posté, à savoir :

[boozo]

Bon soit.
Tu dis avoir enlevé une seule et unique option : laquelle ? peut-on voir un diff entre les 2 .config stp histoire de s'en assurer [/quote](tu peux également vérifier depuis les config.gz des 2 versions du noyau par la même occasion)

En subsidiaire même si cela te semble trivial, est-ce que le lien symbolique linux pointe vers les mêmes sources entre la version antérieure qui fonctionne et celle-ci ?
_________________
" Un psychotique, c'est quelqu'un qui croit dur comme fer que 2 et 2 font 5, et qui en est pleinement satisfait.
Un névrosé, c'est quelqu'un qui sait pertinemment que 2 et 2 font 4, et ça le rend malade ! "

[bouyafa]

Re,

Merci pour vos idées ... bien donc oui j'avais module-rebuild et je l'avais déjà exécuté, comme à chaque changement de kernel d'ailleurs.

[bouyafa]

Voici le diff de l'ancien kernel avec le nouveau :

[boozo]

[bouyafa]

Re

En fait, chaque "la*" est formé grâce à un 'zcat /proc/config.gz"

Donc le diff que j'ai donné au dessus, est celui obtenu par zcat en bootant sur chaque kernel.

[boozo]

C'est bien çà alors ?!? et tu n'as aucun moyen d'avoir qqpart la config d'origine cad d'avant de faire le make oldconfig (v.N-2) et où le dri fonctionnait ? Faut a minima reproduire le pb pour voir à chaud les différences éventuelles des fichiers de conf entre le kernel avec dri fonctionnel et sans.

Si oui, alors je ne vois guère d'autres solutions que checker toutes les entrées à la main point par point depuis un menuconfig pour voir si tout est ok et que des valeurs passées par défaut à ce moment là n'aient pas mis le brin qqpart

btw, côté X tout va bien ? (version migrée récemment ? config à jour et/ou testé sans Xorg.conf le cas échéant ? etc...)

Edit: A la relecture j'ai un doute : la config "la" est-elle bien celle issue du bzImage qui est dans /boot et ou le DRI était encore fonctionnel ? si oui tu devrais pouvoir revenir à l'état antérieur alors ? Où tu as également écrasé ce bzImage là ?

*Vais y perdre mon latin à force... *

Edit 2: Je m'excuse si j'insite mais je vais essayer de résumer autrement la séquence des événements pour être sûr qu'on ne râte pas qqch :

1°) Etat initial : bzImage avec DRI fonctionnel et Udev qui râle
2°) Etat M1 : make oldconfig blablabla => là il y a création du .config (aka pour moi v.N-1) et renommage de l'ancien où tout allait bien en .config.old (aka our moi v.N-2) that's all
3°) Etat M2 : make menuconfig pour suppression du sysfs deprecated + make blablabla => dès lors il y a création d'un nouveau .config (aka pour moi v.N) et écrasement de l'ancien .config.old (aka pour moi v.N-1) + création d'un nouveau bzImage et déloyement dans /boot avec renommage de l'ancienne image kernel correspondant à l'état initial 1°)

Ai-je mal compris un truc ? Si la séquence est bonne tu peux donc revenir à l'état initial là sauf si tu as généré et pushé un autre bzImage ente la phase 2°) et 3°)
_________________
" Un psychotique, c'est quelqu'un qui croit dur comme fer que 2 et 2 font 5, et qui en est pleinement satisfait.
Un névrosé, c'est quelqu'un qui sait pertinemment que 2 et 2 font 4, et ça le rend malade ! "

[bouyafa]

En fait tout s'est passé comme ça :

Sous le 2.6.28-r4 j'avais tout qui fonctionnait nickel, sauf ce message d'udev. Je suis donc allé dans mon /usr/src/linux, là en effet j'ai zappé de cp .config (chose que je fais habituellement), et j'ai fais un make oldconfig direct. Après avoir saisi par défaut, j'ai menuconfig, enlevé l'option, et make && make modules_install. J'ai donc 2 bzImage dans /boot, l'ancien 2.6.28-r4 (avec le pb udev) et un autre bzImage du même kernel donc, sans le pb udev. Mais now que celà soit sur un kernel ou un autre, le DRI ne fonctionne plus. Entre deux je n'ai upgradé aucun logiciel encore moins X ou ses drivers, j'ai juste recompilé ati-drivers lors de mon reboot sur le nouveau noyau.

Sinon j'ai bien un .config.old dans mes sources :

[boozo]

En effet, comme signalé plus haut cela reste encore la meilleure façon de s'en assurer.

Une autre chose que tu peux faire par la même occasion, c'est faire un make clean et/ou make mrproper (/!\ Sauver ailleurs le .config avant de faire le second /!\) entre chaque test pour partir d'une base nette
_________________
" Un psychotique, c'est quelqu'un qui croit dur comme fer que 2 et 2 font 5, et qui en est pleinement satisfait.
Un névrosé, c'est quelqu'un qui sait pertinemment que 2 et 2 font 4, et ça le rend malade ! "

[nemo13]

bonjour,

cela ne réssoudra pas ton problème ;
un ruc cool dans le kernel est