Méthode pour changer temporairement de pilote graphique [Résolu]

[mont29]

Bonjours, et désolé si ce point a déjà été abordé, mais je n’en ai pas trouvé trace…

Donc, j’ai besoin d’utiliser GDB pour débogguer Blender, hors j’ai un gros problème : dès qu’une segfault est levée, 9/10 mon affichage se fige totalement. Le PC continue à tourner normalement (téléchargements, uploads fonctionnent, par exemple), mais l’affichage est totalement boqué sur une belle image fixe (’y a que la souris qui continue à se balader comme si de rien n’était ). Mais rien à faire, même pas moyen de revenir sur une console texte pure (shift-F1), etc. N’y a que le reset méchant qui marche (et j’aime pas faire ça à mon PC/OS).

Bon, je me dis, ’y a incompatibilité entre les drivers ati propriétaires, et le déboggage de Blender, pour une raison ou pour une autre, et j’aimerais bien revenir au pilote libre readon, le temps d’en finir avec mon deboggage… Seulement j’aime pas bidouiller sur le système graphique de ma distrib, c’est toujours délicat…

Donc je voudrais savoir si l’un d’entre vous a une technique simple et sûre pour temporairement repasser en readon, sans avoir à désinstaller fglrx…

Merci d’avance pour vos réponses

PS*: Je suis sous testing.

[mont29]

Bah, j’ai fini par trouver (pour faire court, renommage de xorg.conf + redémarrage), mais ça ne résout hélas pas mon problème de départ

[frp31]

tu peux pas prendre la mains sur la machine via SSH plustot que de rebooter pour tuer les processus en cause.
et libérer la machine figée...

[kiluak]

Ah, quand X plante des fois ça ne pardonne pas!

Si ton noyau est compilé avec l'option, il y a aussi la combinaison "ALT + Impr Ecran + B" qui permet de rebooter le PC de façon hard, mais sans appuyer sur le bouton.

Et si tu es un bricoleur dégueulasse (comme moi ) , tu peux te recompiler un noyau avec une combinaison de touches dans ce genre, qui va tuer ton processus (voire X, si besoin est).

=> /drivers/tty/sysrq.c

Il y a surement mieux...


En tous cas, l'idée d'un accès distant SSH me paraît beaucoup plus raisonnable si c'est possible pour toi (ou même, un script shell tournant en arrière plan peut peut etre s'occupper de ça automatiquement)

[frp31]

Envoyé par kiluak

Ah, quand X plante des fois ça ne pardonne pas!

Si ton noyau est compilé avec l'option, il y a aussi la combinaison "ALT + Impr Ecran + B" qui permet de rebooter le PC de façon hard, mais sans appuyer sur le bouton.

Et si tu es un bricoleur dégueulasse (comme moi ) , tu peux te recompiler un noyau avec une combinaison de touches dans ce genre, qui va tuer ton processus (voire X, si besoin est).

=> /drivers/tty/sysrq.c

Il y a surement mieux...


En tous cas, l'idée d'un accès distant SSH me paraît beaucoup plus raisonnable si c'est possible pour toi (ou même, un script shell tournant en arrière plan peut peut etre s'occupper de ça automatiquement)

si tu veux faire plus porcasse encore, tu peux chinter une relai alimenté par le 12V en sortie d'alim qui coupe l'alim...

ou mieux encore, piloter un servo-moteur par une carte serie, qui tire sur le bouton "reset" vers l'interieur.... rigolez pas j'ai déjà vu ça !!!!

[mont29]

Merci à vous, mais les magikeys ne fonctionnaient pas ici –*et je ne pouvais pas facilement me faire un accès SSH… De toute façon, je ne suis pas sûr que ça ait pu marcher, vu le type de blocage…

Pour info, c’est bien cette sa***ie de fglrx qui posait problème, en passant au radeon je peux maintenant déboguer et toute tranquilité (même si, l’accélération 3D n’étant pas encore activé pour moi, les performances sont en chute libre).

En fait, ma théorie est que l’interruption du processus effectuée par gdb peut parfois se produire durant une phase de dessin (utilisation d’OpenGL), et que cela semble induire un blocage du driver fglrx dans une phase critique quelconque, au niveau noyau… Tuer gdb aurait probablement pu suffire, mais comme je n’avais plus accès à rien (j’ai aussi tenté de faire des manip clavier “à l’aveugle”, me disant que peut-être le seul système graphique était touché, mais rien à faire)… Le plus drôle dans l’histoire est que la souris (le touchpad, en fait), continuait à marcher (le curseur bougeait à l’écran)

Un autre insondable mystère de l’informatique.