Debian Pb d'affichage des consoles virtuelles - Page 1

Je suis en train de peaufiner l'install d'une Debian Lenny sur mon Thinkpad S30 tout neuf (miam!) et tout roule nikel. Mon affichage est nikel mais des que jessaye de passer sur un console virtuelle (CTRL+F<1-9>) mon ecran deviens noir et je ne peux plus revenir a la console graphique (CTRL-F7), oblige de rebooter car meme CTRL-ALT-Backspace ne fait pas rebooter X.

Je voudrai donc savoir si vous avez deja eu ce probleme la, car moi je lai eu une fois mais avec un ordi qui avit un xorg pourrav, une fois celui ci ajuste plus de probleme, mais la le xorg semble bon (repris sur un xorg jap).

je le poste ici a titre d'info (j'ai coupe les parties non relatives a l'affichage):

Section "Module"
	Load	"i2c"
	Load	"bitmap"
	Load	"ddc"
	Load	"dri"
	Load	"extmod"
	Load	"freetype"
	Load	"glx"
	Load	"int10"
	Load	"vbe"
EndSection

Section "Device"
	Identifier	"Generic Video Card"
	Driver		"siliconmotion"
	Option		"HWCursor"	"off"
	Option		"SWCursor"	"on"
	Option		"UseBIOS"	"off"
EndSection

Section "Monitor"
	Identifier	"Generic Monitor"
	HorizSync	28-51
	VertRefresh	43-60
	Option		"DPMS"
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Device 		"Generic Video Card"
	Monitor		"Generic Monitor"
	DefaultDepth	16
	SubSection "Display"
		Depth 	16
		Modes	"1024x768" "800x600"
	EndSubSection
	SubSection "Display"
		Depth 	24
		Modes	"1024x768" "800x600"
	EndSubSection
EndSection

Section "DRI"
	Mode 0666
EndSection

Merci du coup de main.

PS: le S30 est sortit qu'au jap donc le clavier est jap donc pardon pour le manque d'accents (xmodmap va devenir mon ami).

Ctrl+Alt+Backspace ne fait "rebooter" X que si tu es sous X !

Si tu veux le tuer et que tu es dans une console, pourquoi ne pas tout simplement le tuer ? (via kill/killall)

ben parce qu'il peut plus rien faire une fois qu'il a switché avec Ctrl Alt Fn

Ctrl+Alt+Fn c'est pour repasser dans une console texte, donc c'est que ça plante avant d'atteindre la dite console, donc tu ne peux alors rien faire, sauf ne pas passer sur cette console


Dans 99% des cas ce genre de plantage est due a un driver graphique pourrit. Les drivers ATI avaient ce problème pendant longtemps (c'était ça ou corruption de la mémoire graphique, et en mode texte c'est plutôt sympa ^^)

Au pire si la machine est connecté en résal tu peut toujours tenter d'y SSHer dessus pour voir si elle est toujours en vie, mais généralement ça se traduisait par un lock complet..

Si ta distrib à activé les Magic SysRq Keys (mais sur un portable ça risque d'être chaud a utiliser ^^) tu peut toujours en googlant chercher les combinaisons de touches pour tenter de rendre la vie a ta machine dans ce genre de cas (fonctionnement non garantie dans la majorité des cas, au mieux tu peux arriver a la rebooter ^^)

Sur la plupart des distributions linux que j'ai essayées, effectivement, en faisant AltGr+ImprÉcran sur une console on réussit à ramener un prompt pratiquement quel que soit l'état (enfin c'est-à-dire si la console est morte/inutilisable mais que le noyau/init sont toujours en marche, évidemment, pas si l'ordi a complètement planté. Mais s'il réagit normalement au Ctrl-Alt-Suppr il devrait aussi réagir à cette combinaison-là)

JoNas (./1) :
CTRL-F7

J'espère que tu veux dire Alt-F7 parce que sinon c'est normal que ça fasse rien ^^

Sally (./5) :
Mais s'il réagit normalement au Ctrl-Alt-Suppr il devrait aussi réagir à cette combinaison-là)

Pas forcement

Sur une machine type PC *normalement* Ctrl+Alt+Suppr genere une IT qui peut tres bien reagir, meme si tout le reste est completemment planté.. (je ne sais pas par contre pour Alt+SysReq)

Hum oui mais je veux dire s'il réagit *normalement* au ctrl-alt-suppr (ie séquence de reboot normale, runlevel 6 etc.) c'est que init et le noyau ne sont pas plantés (sinon effectivement c'est possible que ça déclenche un reboot par le bios même si tout est planté, mais c'est pas ce que j'appelle le comportement normal ^^). Il me semble que SysReq déclenche aussi une interruption sinon

Je ne sais pas si SysRq est activé sous Debian (sous Fedora, c'est désactivé par défaut pour des raisons de sécurité).

./4 : Oui j'avais entendu mais dans mon cas c'est pas une ATI (peut être que les silicon graphics sont merdiques aussi?)

./5 : Oui je veux dire CTRL-ALT-F7 pardon.

./8 : Les touches SysRq sont activées

Je pense que c'est un pb graphique car a l'aveuglette je peux logger sur les consoles (le disque gratte une fois que j'ai entré user+password). Pour info j'ai ajouté des lignes dans mon xorg pour supporter les affichages 1/4/8bpp et non seulement 16 et 24bpp mais rien n'y change :/

Je doute que tu ai une carte "silicon graphics"

siliconmotion n'a rien a voir avec Silicon Graphics

Godzil (./10) :
Je doute que tu ai une carte "silicon graphics"

siliconmotion n'a rien a voir avec Silicon Graphics

En effet c'est une siliconmotion (http://aglet.net/s30/), faute d'innatention (en plus je l'ai marqué dans mon Xorg cf. ./1)

On dirait que mon problème vienne bien de là (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502030) mise à part que je n'ai pas du tout de problème de curseur ou quoi que ce soit.

D'ailleurs en lisant ce rapport de bug (cd adresse plus aut) j'ai découvert que je pouvais revenir a l'interface graphique en faisant ALT+F7. Ya du mieux donc.

Problème résolu, ça venait de la version 1.6 du driver qui est foireuse sous Lenny.

Il fallait rajouter la ligne suivante dans mon Xorg (dans la section de la carte graphique):

Option "NoInt10" "yes"

(Vu sur http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499018#15)

Je continue mon chemin vers l'élaboration de l'ordi parfait (Hardware + Software) :P
Prochaine étape xmodmap et kazehakaze.

Merci en tout cas de vos commentaires!

PS: la solution à ce problème est applicable à tout les Thinkpad (sinon tout les ordis utilisant du siliconmotion) iseries qui ont un chipset siliconmotion.

Au passage, pour rectifier un truc : y'a pas d'interruption particulière pour le Ctrl-Alt-Suppr, SysReq, etc. sur PC, juste une interruption générale pour dire qu'une touche a été pressée ; les combinaisons de touches "spéciales" sont gérées en soft. Et le BIOS n'intervient plus sous Windows et Linux, c'est le driver clavier de l'OS qui fait l'interprétation des touches tapées.

Tu m'étonne je m'avais toujours entendu parlé d'une IT spéciale pour le ctrl+alt+suppr (autre que celle du clavier classique) (et meme si en réfléchissant c'est étrange c'est vrai)

j'avais lu ça (il me semble) entre autre sur le choix du Ctrl+Alt+Suppr sous Windows NT qui garantissait que seul l'OS pouvait le receptionner car on ne pouvais pas le détourner (comme on peut détourner l'appuie sur les touches) j'ai mal du comprendre l'article..

Y'a bien un truc comme ça sous Windows et Linux (les Secure Attention Keys) mais je pense que c'est uniquement un chemin de code différent dans le driver du clavier, et que la "sécurisation" ne concerne que l'user-space.

En tout cas s'ils ont rajouté une interruption spécifique ça doit être nouveau, y'a pas ça dans l'architecture PC "classique". J'ai même vérifié sur mon PC (qui date de quelques années) tout à l'heure pour être sûr : sous DOS, si tu désactives l'interruption clavier, le Ctrl-Alt-Suppr n'a pas d'effet.

(faudrait que je regarde dans les sources de Linux pour voir comment ils gèrent ça )

Mais quand tu fais Control-Alt-Suppr avant le chargement de l'OS, ça redémarre bien... c'est pas une interruption spécifique, c'est juste le BIOS qui fait ça "manuellement" ?

Oui, apparemment.

Ok, donc en fait, si sur autre chose qu'un PC, Ctrl+Alt+suppr ne fait rien sous linux, c'est juste parcequ'il on eu la flemme de le faire

(enfin en tout cas ça ne vaut pas le Ctrl+Command+Power des Mac PPC, qui lui est une IT, et ça reboot quelque soit l'état de la machine )