ce matin je voulais imprimer rapidement plusieurs photos, j'ai sorti gimp 2
en voulant imprimer une page avec les diverses photos réduites dessus.
Lorsque j'ai créé une nouvelle image au format 21x29.7x600dpi (les 4 photos
que je voulais monter étaient déjà chargée) gimp m'a averti qu'elle allait
faire plus de 260 Mo et j'ai passé outre. Après tout la machine a 512 Mo de
RAM...
Ensuite c'est parti en vrille :
- j'ai pu voir que gimp et kswapd se battaient pour savoir qui aurait la
plus grosse charge
- X a cessé de rafraîchir les fenêtres de gimp
- et ça a fini par un superbe crash de X (driver proprio NVidia pour une
4200 Ti) => grosse bouillie de pixels colorés à l'écran
- Plus de clavier : impossible de switcher sur une autre console pour
dépatouiller, je remarque que même les diodes verrouillage majuscule et
pavé numérique ne réagissent plus.
D'un autre côté, le reste de la machine n'est pas planté : je vois des accès
réseau à intervales réguliers (sans doute fetchmail et bittorrent) et ssh
réagit toujours.
Est-ce qu'il y a encore moyen de sauver le patient ?
Plus de traces de X (lancement habituel par startx, runlevel 3 sans *DM) qui
a dû être lancé depuis le zsh en tty1 ou tty2.
Ce n'est pas le premier plantage de X (4.3.0) sur ma machine (Debian 2.4.26
SMP) mais les autres fois je m'en suis sorti en switchant sur une console
secondaire et en killant les restes du plantage. Là je coince et vu que tout
n'est pas mort, j'aimerais bien essayer de dépanner avant de bêtement
relancer.
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien empirer les choses que les améliorer.
Sebastien Kirche
Le 20 nov 2004, Nicolas George a dit :
Sebastien Kirche wrote in message :
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien empirer les choses que les améliorer.
Exact.
Je n'ai pas encore toujours le «réflexe» log, mais j'ai fini par consulter /var/log/kern.log et les dernières lignes étaient celles-ci : ,----[ tail /var/log/kern.log ] | Nov 15 21:54:20 obelix kernel: printer.c: usblp0: removed | Nov 15 22:52:28 obelix kernel: hub.c: new USB device 00:1d.0-2, assigned address 12 | Nov 15 22:52:28 obelix kernel: printer.c: usblp0: USB Bidirectional printer dev 12 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1204 | Nov 20 08:53:57 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process WindowMaker | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process wmnet | Nov 20 08:54:35 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:35 obelix kernel: VM: killing process XFree86 `----
Ça m'a confirmé que c'était X qui était en cause, mais que c'était le noyau qui avait tué X après un dérapage d'allocation mémoire (ma fameuse image de 260 Mo dans Gimp sans doute).
Du coup un premier lancement manuel de X s'est soldé par une erreur, mais ça a décoincé le clavier.
J'ai rebasculé sur une autre console et c'est reparti :D
Comme ça je ne gâche pas mon uptime de 37 jours ;) Merci.
Sébastien Kirche
Le 20 nov 2004, Nicolas George a dit :
Sebastien Kirche wrote in message <87r7moiyhl.fsf@falbala.seki.fr>:
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien
empirer les choses que les améliorer.
Exact.
Je n'ai pas encore toujours le «réflexe» log, mais j'ai fini par consulter
/var/log/kern.log et les dernières lignes étaient celles-ci :
,----[ tail /var/log/kern.log ]
| Nov 15 21:54:20 obelix kernel: printer.c: usblp0: removed
| Nov 15 22:52:28 obelix kernel: hub.c: new USB device 00:1d.0-2, assigned address 12
| Nov 15 22:52:28 obelix kernel: printer.c: usblp0: USB Bidirectional printer dev 12 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1204
| Nov 20 08:53:57 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:32 obelix kernel: VM: killing process WindowMaker
| Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:32 obelix kernel: VM: killing process wmnet
| Nov 20 08:54:35 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:35 obelix kernel: VM: killing process XFree86
`----
Ça m'a confirmé que c'était X qui était en cause, mais que c'était le noyau
qui avait tué X après un dérapage d'allocation mémoire (ma fameuse image de
260 Mo dans Gimp sans doute).
Du coup un premier lancement manuel de X s'est soldé par une erreur, mais ça
a décoincé le clavier.
J'ai rebasculé sur une autre console et c'est reparti :D
Comme ça je ne gâche pas mon uptime de 37 jours ;)
Merci.
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien empirer les choses que les améliorer.
Exact.
Je n'ai pas encore toujours le «réflexe» log, mais j'ai fini par consulter /var/log/kern.log et les dernières lignes étaient celles-ci : ,----[ tail /var/log/kern.log ] | Nov 15 21:54:20 obelix kernel: printer.c: usblp0: removed | Nov 15 22:52:28 obelix kernel: hub.c: new USB device 00:1d.0-2, assigned address 12 | Nov 15 22:52:28 obelix kernel: printer.c: usblp0: USB Bidirectional printer dev 12 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1204 | Nov 20 08:53:57 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process WindowMaker | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process wmnet | Nov 20 08:54:35 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:35 obelix kernel: VM: killing process XFree86 `----
Ça m'a confirmé que c'était X qui était en cause, mais que c'était le noyau qui avait tué X après un dérapage d'allocation mémoire (ma fameuse image de 260 Mo dans Gimp sans doute).
Du coup un premier lancement manuel de X s'est soldé par une erreur, mais ça a décoincé le clavier.
J'ai rebasculé sur une autre console et c'est reparti :D
Comme ça je ne gâche pas mon uptime de 37 jours ;) Merci.
Sébastien Kirche
Sebastien Kirche
Le 20 nov 2004, Nicolas George a dit :
Sebastien Kirche wrote in message :
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien empirer les choses que les améliorer.
Exact.
Je n'ai pas encore toujours le «réflexe» log, mais j'ai fini par consulter /var/log/kern.log et les dernières lignes étaient celles-ci : ,----[ tail /var/log/kern.log ] | Nov 15 21:54:20 obelix kernel: printer.c: usblp0: removed | Nov 15 22:52:28 obelix kernel: hub.c: new USB device 00:1d.0-2, assigned address 12 | Nov 15 22:52:28 obelix kernel: printer.c: usblp0: USB Bidirectional printer dev 12 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1204 | Nov 20 08:53:57 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process WindowMaker | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process wmnet | Nov 20 08:54:35 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:35 obelix kernel: VM: killing process XFree86 `----
Ça m'a confirmé que c'était X qui était en cause, mais que c'était le noyau qui avait tué X après un dérapage d'allocation mémoire (ma fameuse image de 260 Mo dans Gimp sans doute).
Du coup un premier lancement manuel de X s'est soldé par une erreur, mais ça a décoincé le clavier.
J'ai rebasculé sur une autre console et c'est reparti :D
Comme ça je ne gâche pas mon uptime de 37 jours ;) Merci.
Sébastien Kirche
Le 20 nov 2004, Nicolas George a dit :
Sebastien Kirche wrote in message <87r7moiyhl.fsf@falbala.seki.fr>:
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien
empirer les choses que les améliorer.
Exact.
Je n'ai pas encore toujours le «réflexe» log, mais j'ai fini par consulter
/var/log/kern.log et les dernières lignes étaient celles-ci :
,----[ tail /var/log/kern.log ]
| Nov 15 21:54:20 obelix kernel: printer.c: usblp0: removed
| Nov 15 22:52:28 obelix kernel: hub.c: new USB device 00:1d.0-2, assigned address 12
| Nov 15 22:52:28 obelix kernel: printer.c: usblp0: USB Bidirectional printer dev 12 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1204
| Nov 20 08:53:57 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:32 obelix kernel: VM: killing process WindowMaker
| Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:32 obelix kernel: VM: killing process wmnet
| Nov 20 08:54:35 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:35 obelix kernel: VM: killing process XFree86
`----
Ça m'a confirmé que c'était X qui était en cause, mais que c'était le noyau
qui avait tué X après un dérapage d'allocation mémoire (ma fameuse image de
260 Mo dans Gimp sans doute).
Du coup un premier lancement manuel de X s'est soldé par une erreur, mais ça
a décoincé le clavier.
J'ai rebasculé sur une autre console et c'est reparti :D
Comme ça je ne gâche pas mon uptime de 37 jours ;)
Merci.
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien empirer les choses que les améliorer.
Exact.
Je n'ai pas encore toujours le «réflexe» log, mais j'ai fini par consulter /var/log/kern.log et les dernières lignes étaient celles-ci : ,----[ tail /var/log/kern.log ] | Nov 15 21:54:20 obelix kernel: printer.c: usblp0: removed | Nov 15 22:52:28 obelix kernel: hub.c: new USB device 00:1d.0-2, assigned address 12 | Nov 15 22:52:28 obelix kernel: printer.c: usblp0: USB Bidirectional printer dev 12 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1204 | Nov 20 08:53:57 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process WindowMaker | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process wmnet | Nov 20 08:54:35 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:35 obelix kernel: VM: killing process XFree86 `----
Ça m'a confirmé que c'était X qui était en cause, mais que c'était le noyau qui avait tué X après un dérapage d'allocation mémoire (ma fameuse image de 260 Mo dans Gimp sans doute).
Du coup un premier lancement manuel de X s'est soldé par une erreur, mais ça a décoincé le clavier.
J'ai rebasculé sur une autre console et c'est reparti :D
Comme ça je ne gâche pas mon uptime de 37 jours ;) Merci.
Sébastien Kirche
Sebastien Kirche
Le 20 nov 2004, Nicolas George a dit :
Sebastien Kirche wrote in message :
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien empirer les choses que les améliorer.
Exact.
Je n'ai pas encore toujours le «réflexe» log, mais j'ai fini par consulter /var/log/kern.log et les dernières lignes étaient celles-ci : ,----[ tail /var/log/kern.log ] | Nov 15 21:54:20 obelix kernel: printer.c: usblp0: removed | Nov 15 22:52:28 obelix kernel: hub.c: new USB device 00:1d.0-2, assigned address 12 | Nov 15 22:52:28 obelix kernel: printer.c: usblp0: USB Bidirectional printer dev 12 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1204 | Nov 20 08:53:57 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process WindowMaker | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process wmnet | Nov 20 08:54:35 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:35 obelix kernel: VM: killing process XFree86 `----
Ça m'a confirmé que c'était X qui était en cause, mais que c'était le noyau qui avait tué X après un dérapage d'allocation mémoire (ma fameuse image de 260 Mo dans Gimp sans doute).
Du coup un premier lancement manuel de X s'est soldé par une erreur, mais ça a décoincé le clavier.
J'ai rebasculé sur une autre console et c'est reparti :D
Comme ça je ne gâche pas mon uptime de 37 jours ;) Merci.
Sébastien Kirche
Le 20 nov 2004, Nicolas George a dit :
Sebastien Kirche wrote in message <87r7moiyhl.fsf@falbala.seki.fr>:
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien
empirer les choses que les améliorer.
Exact.
Je n'ai pas encore toujours le «réflexe» log, mais j'ai fini par consulter
/var/log/kern.log et les dernières lignes étaient celles-ci :
,----[ tail /var/log/kern.log ]
| Nov 15 21:54:20 obelix kernel: printer.c: usblp0: removed
| Nov 15 22:52:28 obelix kernel: hub.c: new USB device 00:1d.0-2, assigned address 12
| Nov 15 22:52:28 obelix kernel: printer.c: usblp0: USB Bidirectional printer dev 12 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1204
| Nov 20 08:53:57 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:32 obelix kernel: VM: killing process WindowMaker
| Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:32 obelix kernel: VM: killing process wmnet
| Nov 20 08:54:35 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
| Nov 20 08:54:35 obelix kernel: VM: killing process XFree86
`----
Ça m'a confirmé que c'était X qui était en cause, mais que c'était le noyau
qui avait tué X après un dérapage d'allocation mémoire (ma fameuse image de
260 Mo dans Gimp sans doute).
Du coup un premier lancement manuel de X s'est soldé par une erreur, mais ça
a décoincé le clavier.
J'ai rebasculé sur une autre console et c'est reparti :D
Comme ça je ne gâche pas mon uptime de 37 jours ;)
Merci.
Est-ce qu'il y a encore moyen de sauver le patient ?
Tu peux essayer de lancer X depuis la connexion ssh. Ça peut aussi bien empirer les choses que les améliorer.
Exact.
Je n'ai pas encore toujours le «réflexe» log, mais j'ai fini par consulter /var/log/kern.log et les dernières lignes étaient celles-ci : ,----[ tail /var/log/kern.log ] | Nov 15 21:54:20 obelix kernel: printer.c: usblp0: removed | Nov 15 22:52:28 obelix kernel: hub.c: new USB device 00:1d.0-2, assigned address 12 | Nov 15 22:52:28 obelix kernel: printer.c: usblp0: USB Bidirectional printer dev 12 if 0 alt 1 proto 2 vid 0x03F0 pid 0x1204 | Nov 20 08:53:57 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process WindowMaker | Nov 20 08:54:32 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:32 obelix kernel: VM: killing process wmnet | Nov 20 08:54:35 obelix kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) | Nov 20 08:54:35 obelix kernel: VM: killing process XFree86 `----
Ça m'a confirmé que c'était X qui était en cause, mais que c'était le noyau qui avait tué X après un dérapage d'allocation mémoire (ma fameuse image de 260 Mo dans Gimp sans doute).
Du coup un premier lancement manuel de X s'est soldé par une erreur, mais ça a décoincé le clavier.
J'ai rebasculé sur une autre console et c'est reparti :D
Comme ça je ne gâche pas mon uptime de 37 jours ;) Merci.
Sébastien Kirche
Bruno Mathieu
Sebastien Kirche a écrit:
- Plus de clavier : impossible de switcher sur une autre console pour dépatouiller, je remarque que même les diodes verrouillage majuscule et pavé numérique ne réagissent plus.
Bonjour,
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on ne pouvait plus rien faire sur une console. Rebooter n'était pas trop envisageable car plusieurs personnes faisaient tourner des process assez longs sur la machine. Kbd_mode à distance pour remettre le clavier en état a fonctionné.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
-- Bruno
Sebastien Kirche a écrit:
- Plus de clavier : impossible de switcher sur une autre console
pour dépatouiller, je remarque que même les diodes verrouillage
majuscule et pavé numérique ne réagissent plus.
Bonjour,
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de serveurs
X sur sun : le clavier ne se remettait pas en mode ascii alors on ne
pouvait plus rien faire sur une console. Rebooter n'était pas trop
envisageable car plusieurs personnes faisaient tourner des process assez
longs sur la machine. Kbd_mode à distance pour remettre le clavier en état
a fonctionné.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les
touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me
rend parfois la console (si noyau compilé avec support de Magic Keys).
- Plus de clavier : impossible de switcher sur une autre console pour dépatouiller, je remarque que même les diodes verrouillage majuscule et pavé numérique ne réagissent plus.
Bonjour,
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on ne pouvait plus rien faire sur une console. Rebooter n'était pas trop envisageable car plusieurs personnes faisaient tourner des process assez longs sur la machine. Kbd_mode à distance pour remettre le clavier en état a fonctionné.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
-- Bruno
Sebastien Kirche
Le 20 nov 2004, Bruno Mathieu s'est exprimé ainsi :
Bonjour,
Salut :)
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on ne pouvait plus rien faire sur une console. Rebooter n'était pas trop envisageable car plusieurs personnes faisaient tourner des process assez longs sur la machine. Kbd_mode à distance pour remettre le clavier en état a fonctionné.
Je ne connaissais pas du tout kbd_mode. Je me note ça dans un coin. J'ai fini par décoincer en relançant X 2 fois.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
Je viens de vérifier dans la conf du noyau je crois que les touches magiques n'y sont pas...
Sébastien Kirche
Le 20 nov 2004, Bruno Mathieu s'est exprimé ainsi :
Bonjour,
Salut :)
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de
serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on
ne pouvait plus rien faire sur une console. Rebooter n'était pas trop
envisageable car plusieurs personnes faisaient tourner des process assez
longs sur la machine. Kbd_mode à distance pour remettre le clavier en état
a fonctionné.
Je ne connaissais pas du tout kbd_mode. Je me note ça dans un coin.
J'ai fini par décoincer en relançant X 2 fois.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les
touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me
rend parfois la console (si noyau compilé avec support de Magic Keys).
Je viens de vérifier dans la conf du noyau je crois que les touches magiques
n'y sont pas...
Le 20 nov 2004, Bruno Mathieu s'est exprimé ainsi :
Bonjour,
Salut :)
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on ne pouvait plus rien faire sur une console. Rebooter n'était pas trop envisageable car plusieurs personnes faisaient tourner des process assez longs sur la machine. Kbd_mode à distance pour remettre le clavier en état a fonctionné.
Je ne connaissais pas du tout kbd_mode. Je me note ça dans un coin. J'ai fini par décoincer en relançant X 2 fois.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
Je viens de vérifier dans la conf du noyau je crois que les touches magiques n'y sont pas...
Sébastien Kirche
Bruno Mathieu
Sebastien Kirche a écrit:
Je ne connaissais pas du tout kbd_mode. Je me note ça dans un coin. J'ai fini par décoincer en relançant X 2 fois.
J'en avais moi-même presque oublié l'existence depuis que je suis sous linux :-) C'était une proposition comme ça pour ton uptime, parce que je reboote sauvagement après usage des touches magiques maintenant que je suis seul sur ma machine.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
Je viens de vérifier dans la conf du noyau je crois que les touches magiques n'y sont pas...
Le symbole en question est : CONFIG_MAGIC_SYSRQ et il faut un 1 dans un fichier de /proc http://eric.gerbier.free.fr/admin-tips.html#magic ou kernel.sysrq = 1 dans /etc/sysctl.conf
Si tu as un 2.6.x (x=9 c'est ok, avant je ne sais pas), CONFIG_IKCONFIG permet d'avoir un /proc/config.gz qui indique la config du noyau qui tourne, et c'est rudement pratique AMHA : cf http://lists.debian.org/debian-kernel/2004/10/msg00023.html pour d'autres avis !
-- Bruno
Sebastien Kirche a écrit:
Je ne connaissais pas du tout kbd_mode. Je me note ça dans un coin.
J'ai fini par décoincer en relançant X 2 fois.
J'en avais moi-même presque oublié l'existence depuis que je suis sous
linux :-) C'était une proposition comme ça pour ton uptime, parce que je
reboote sauvagement après usage des touches magiques maintenant que je suis
seul sur ma machine.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les
touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me
rend parfois la console (si noyau compilé avec support de Magic Keys).
Je viens de vérifier dans la conf du noyau je crois que les touches
magiques n'y sont pas...
Le symbole en question est :
CONFIG_MAGIC_SYSRQ et il faut un 1 dans un fichier de /proc
http://eric.gerbier.free.fr/admin-tips.html#magic ou
kernel.sysrq = 1 dans /etc/sysctl.conf
Si tu as un 2.6.x (x=9 c'est ok, avant je ne sais pas), CONFIG_IKCONFIG
permet d'avoir un /proc/config.gz qui indique la config du noyau qui
tourne, et c'est rudement pratique AMHA : cf
http://lists.debian.org/debian-kernel/2004/10/msg00023.html pour d'autres
avis !
Je ne connaissais pas du tout kbd_mode. Je me note ça dans un coin. J'ai fini par décoincer en relançant X 2 fois.
J'en avais moi-même presque oublié l'existence depuis que je suis sous linux :-) C'était une proposition comme ça pour ton uptime, parce que je reboote sauvagement après usage des touches magiques maintenant que je suis seul sur ma machine.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
Je viens de vérifier dans la conf du noyau je crois que les touches magiques n'y sont pas...
Le symbole en question est : CONFIG_MAGIC_SYSRQ et il faut un 1 dans un fichier de /proc http://eric.gerbier.free.fr/admin-tips.html#magic ou kernel.sysrq = 1 dans /etc/sysctl.conf
Si tu as un 2.6.x (x=9 c'est ok, avant je ne sais pas), CONFIG_IKCONFIG permet d'avoir un /proc/config.gz qui indique la config du noyau qui tourne, et c'est rudement pratique AMHA : cf http://lists.debian.org/debian-kernel/2004/10/msg00023.html pour d'autres avis !
-- Bruno
Sebastien Kirche
Le 20 nov 2004, Bruno Mathieu a dit :
Je viens de vérifier dans la conf du noyau je crois que les touches magiques n'y sont pas...
Le symbole en question est : CONFIG_MAGIC_SYSRQ et il faut un 1 dans un fichier de /proc http://eric.gerbier.free.fr/admin-tips.html#magic ou kernel.sysrq = 1 dans /etc/sysctl.conf
Ok ça me confirme : rien dans /boot/config-2.4.26-1-686-smp et pas de sysrq dans /proc/sys/kernel
Dommage.
Sébastien Kirche
Le 20 nov 2004, Bruno Mathieu a dit :
Je viens de vérifier dans la conf du noyau je crois que les touches
magiques n'y sont pas...
Le symbole en question est :
CONFIG_MAGIC_SYSRQ et il faut un 1 dans un fichier de /proc
http://eric.gerbier.free.fr/admin-tips.html#magic ou
kernel.sysrq = 1 dans /etc/sysctl.conf
Ok ça me confirme : rien dans /boot/config-2.4.26-1-686-smp et pas de sysrq
dans /proc/sys/kernel
Je viens de vérifier dans la conf du noyau je crois que les touches magiques n'y sont pas...
Le symbole en question est : CONFIG_MAGIC_SYSRQ et il faut un 1 dans un fichier de /proc http://eric.gerbier.free.fr/admin-tips.html#magic ou kernel.sysrq = 1 dans /etc/sysctl.conf
Ok ça me confirme : rien dans /boot/config-2.4.26-1-686-smp et pas de sysrq dans /proc/sys/kernel
Dommage.
Sébastien Kirche
Sebastien Kirche
Le 25 Nov 2004, ludovic Thebault a dit :
Le bug est réapparu. Le clavier ne répond pas => donc gèle complet du système, reboot obligatoire.
Es-tu sûr que la machine est complètement plantée ?
Le fait qu'il n'y ait plus d'affichage et que le clavier ne réponde plus (switch vers une autre console ou blocage majuscules inopérant) n'est pas une preuve.
Je m'explique : le week-end dernier j'ai gimp qui m'a fait crasher X suite à (semble-t-il) un souci d'allocation mémoire. Résultat : un tas de pixels à l'écran et clavier bloqué.
Cependant j'ai pu constater qu'il était toujours possible de se connecter sur la machine par ssh, ce qui m'a permis de déplanter le bousin *sans* rebooter.
Également, Bruno Mathieu m'a indiqué une solution pour débloquer le clavier si tu peux encore te logguer dessus à distance : kbd_mode (voir ci-dessous).
Tu peux aussi tenter un reboot propre dans ce cas.
Le 20 Nov 2004, Bruno Mathieu a formulé :
Sebastien Kirche a écrit:
- Plus de clavier : impossible de switcher sur une autre console pour dépatouiller, je remarque que même les diodes verrouillage majuscule et pavé numérique ne réagissent plus.
Bonjour,
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on ne pouvait plus rien faire sur une console. Rebooter n'était pas trop envisageable car plusieurs personnes faisaient tourner des process assez longs sur la machine. Kbd_mode à distance pour remettre le clavier en état a fonctionné.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
Sébastien Kirche
Le 25 Nov 2004, ludovic Thebault a dit :
Le bug est réapparu.
Le clavier ne répond pas => donc gèle complet du système, reboot
obligatoire.
Es-tu sûr que la machine est complètement plantée ?
Le fait qu'il n'y ait plus d'affichage et que le clavier ne réponde plus
(switch vers une autre console ou blocage majuscules inopérant) n'est pas
une preuve.
Je m'explique : le week-end dernier j'ai gimp qui m'a fait crasher X suite à
(semble-t-il) un souci d'allocation mémoire. Résultat : un tas de pixels à
l'écran et clavier bloqué.
Cependant j'ai pu constater qu'il était toujours possible de se connecter
sur la machine par ssh, ce qui m'a permis de déplanter le bousin *sans*
rebooter.
Également, Bruno Mathieu m'a indiqué une solution pour débloquer le clavier
si tu peux encore te logguer dessus à distance : kbd_mode (voir ci-dessous).
Tu peux aussi tenter un reboot propre dans ce cas.
Le 20 Nov 2004, Bruno Mathieu a formulé :
Sebastien Kirche a écrit:
- Plus de clavier : impossible de switcher sur une autre console
pour dépatouiller, je remarque que même les diodes verrouillage
majuscule et pavé numérique ne réagissent plus.
Bonjour,
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de
serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on
ne pouvait plus rien faire sur une console. Rebooter n'était pas trop
envisageable car plusieurs personnes faisaient tourner des process assez
longs sur la machine. Kbd_mode à distance pour remettre le clavier en état
a fonctionné.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les
touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me
rend parfois la console (si noyau compilé avec support de Magic Keys).
Le bug est réapparu. Le clavier ne répond pas => donc gèle complet du système, reboot obligatoire.
Es-tu sûr que la machine est complètement plantée ?
Le fait qu'il n'y ait plus d'affichage et que le clavier ne réponde plus (switch vers une autre console ou blocage majuscules inopérant) n'est pas une preuve.
Je m'explique : le week-end dernier j'ai gimp qui m'a fait crasher X suite à (semble-t-il) un souci d'allocation mémoire. Résultat : un tas de pixels à l'écran et clavier bloqué.
Cependant j'ai pu constater qu'il était toujours possible de se connecter sur la machine par ssh, ce qui m'a permis de déplanter le bousin *sans* rebooter.
Également, Bruno Mathieu m'a indiqué une solution pour débloquer le clavier si tu peux encore te logguer dessus à distance : kbd_mode (voir ci-dessous).
Tu peux aussi tenter un reboot propre dans ce cas.
Le 20 Nov 2004, Bruno Mathieu a formulé :
Sebastien Kirche a écrit:
- Plus de clavier : impossible de switcher sur une autre console pour dépatouiller, je remarque que même les diodes verrouillage majuscule et pavé numérique ne réagissent plus.
Bonjour,
Tu peux essayer kbd_mode à distance. Je me souviens de plantage de serveurs X sur sun : le clavier ne se remettait pas en mode ascii alors on ne pouvait plus rien faire sur une console. Rebooter n'était pas trop envisageable car plusieurs personnes faisaient tourner des process assez longs sur la machine. Kbd_mode à distance pour remettre le clavier en état a fonctionné.
Autrement il m'est arrivé que les diodes ne répondent plus mais que les touches magiques fonctionnent encore. Dans ce cas un alt-impr_écran-k me rend parfois la console (si noyau compilé avec support de Magic Keys).
