Forum Linux.général freeze clavier

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
9
août
2016

Bonsoir.
Je viens d'expérimenter un bug des plus étranges: mon clavier s'est bloqué pour de vrai. Venant de renverser un quantité non négligeable de liquide dessus, j'ai cru qu'il était mort, mais pour être sûr j'ai vérifié sur une autre machine, et il fonctionne (puisque je m'en sers actuellement…).

Du coup, je me suis loggué en ssh de cette autre machine afin d'accéder à dmesg, et vers le moment du bug, j'ai deux messages qui apparaissent 5 fois chacun, à 120s d'intervalle:

[Tue Aug 9 19:24:24 2016] INFO: task khubd:76 blocked for more than 120 seconds.
[Tue Aug 9 19:24:24 2016] Tainted: P O 3.16.0-4-amd64 #1
[Tue Aug 9 19:24:24 2016] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Tue Aug 9 19:24:24 2016] khubd D ffff8800bf5d8628 0 76 2 0x00000000
[Tue Aug 9 19:24:24 2016] ffff8800bf5d81d0 0000000000000046 0000000000012f00 ffff8800bf6e3fd8
[Tue Aug 9 19:24:24 2016] 0000000000012f00 ffff8800bf5d81d0 ffff88008d6260f0 ffff8800bf6e3d58
[Tue Aug 9 19:24:24 2016] ffff88008d6260f4 ffff8800bf5d81d0 00000000ffffffff ffff88008d6260f8
[Tue Aug 9 19:24:24 2016] Call Trace:
[Tue Aug 9 19:24:24 2016] [] ? schedule_preempt_disabled+0x25/0x70
[Tue Aug 9 19:24:24 2016] [] ? _mutex_lock_slowpath+0xd3/0x1c0
[Tue Aug 9 19:24:24 2016] [] ? mutex_lock+0x1b/0x2a
[Tue Aug 9 19:24:24 2016] [] ? usb_disconnect+0x50/0x280 [usbcore]
[Tue Aug 9 19:24:24 2016] [] ? hub_thread+0xaac/0x1720 [usbcore]
[Tue Aug 9 19:24:24 2016] [] ? check_preempt_wakeup+0xe4/0x1d0
[Tue Aug 9 19:24:24 2016] [] ? prepare_to_wait_event+0xf0/0xf0
[Tue Aug 9 19:24:24 2016] [] ? hub_port_debounce+0x130/0x130 [usbcore]
[Tue Aug 9 19:24:24 2016] [] ? kthread+0xbd/0xe0
[Tue Aug 9 19:24:24 2016] [] ? kthread_create_on_node+0x180/0x180
[Tue Aug 9 19:24:24 2016] [] ? ret_from_fork+0x58/0x90
[Tue Aug 9 19:24:24 2016] [] ? kthread_create_on_node+0x180/0x180
[Tue Aug 9 19:24:24 2016] INFO: task kworker/1:3:4856 blocked for more than 120 seconds.
[Tue Aug 9 19:24:24 2016] Tainted: P O 3.16.0-4-amd64 #1
[Tue Aug 9 19:24:24 2016] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Tue Aug 9 19:24:24 2016] kworker/1:3 D ffff88008e8d1808 0 4856 2 0x00000000
[Tue Aug 9 19:24:24 2016] Workqueue: events hid_reset [usbhid]
[Tue Aug 9 19:24:24 2016] ffff88008e8d13b0 0000000000000046 0000000000012f00 ffff8800760abfd8
[Tue Aug 9 19:24:24 2016] 0000000000012f00 ffff88008e8d13b0 ffff8800760abac8 ffff8800760aba40
[Tue Aug 9 19:24:24 2016] ffff8800760abac0 ffff88008e8d13b0 ffff88008e8d13b0 00000000ffffffed
[Tue Aug 9 19:24:24 2016] Call Trace:
[Tue Aug 9 19:24:24 2016] [] ? schedule_timeout+0x229/0x2a0
[Tue Aug 9 19:24:24 2016] [] ? signal_wake_up_state+0x1a/0x30
[Tue Aug 9 19:24:24 2016] [] ? _send_signal+0x173/0x470
[Tue Aug 9 19:24:24 2016] [] ? wait_for_completion+0xa8/0x120
[Tue Aug 9 19:24:24 2016] [] ? wake_up_state+0x10/0x10
[Tue Aug 9 19:24:24 2016] [] ? flush_work+0xde/0x150
[Tue Aug 9 19:24:24 2016] [] ? destroy_worker+0x80/0x80
[Tue Aug 9 19:24:24 2016] [] ? _cancel_work_timer+0x88/0x1a0
[Tue Aug 9 19:24:24 2016] [] ? lock_timer_base.isra.35+0x26/0x50
[Tue Aug 9 19:24:24 2016] [] ? try_to_del_timer_sync+0x49/0x60
[Tue Aug 9 19:24:24 2016] [] ? usbhid_close+0x59/0xb0 [usbhid]
[Tue Aug 9 19:24:24 2016] [] ? inputclose_device+0x41/0x60
[Tue Aug 9 19:24:24 2016] [] ? evdev_disconnect+0x26/0x50 [evdev]
[Tue Aug 9 19:24:24 2016] [] ? _input_unregister_device+0xbd/0x170
[Tue Aug 9 19:24:24 2016] [] ? input_unregister_device+0x45/0x80
[Tue Aug 9 19:24:24 2016] [] ? hidinput_disconnect+0x65/0x90 [hid]
[Tue Aug 9 19:24:24 2016] [] ? hid_disconnect+0x68/0x70 [hid]
[Tue Aug 9 19:24:24 2016] [] ? hid_device_remove+0xb5/0xd0 [hid]
[Tue Aug 9 19:24:24 2016] [] ? _device_release_driver+0x7a/0xf0
[Tue Aug 9 19:24:24 2016] [] ? device_release_driver+0x1e/0x30
[Tue Aug 9 19:24:24 2016] [] ? bus_remove_device+0x103/0x180
[Tue Aug 9 19:24:24 2016] [] ? device_del+0x116/0x1b0
[Tue Aug 9 19:24:24 2016] [] ? hid_destroy_device+0x22/0x60 [hid]
[Tue Aug 9 19:24:24 2016] [] ? usbhiddisconnect+0x45/0x70 [usbhid]
[Tue Aug 9 19:24:24 2016] [] ? usb_unbind_interface+0x6c/0x2b0 [usbcore]
[Tue Aug 9 19:24:24 2016] [] ? _device_release_driver+0x7a/0xf0
[Tue Aug 9 19:24:24 2016] [] ? devicerelease_driver+0x1e/0x30
[Tue Aug 9 19:24:24 2016] [] ? usbforced_unbind_intf+0x29/0x50 [usbcore]
[Tue Aug 9 19:24:24 2016] [] ? unbind_marked_interfaces.isra.10+0x52/0x60 [usbcore]
[Tue Aug 9 19:24:24 2016] [] ? usb_unbind_and_rebind_marked_interfaces+0x15/0x30 [usbcore]
[Tue Aug 9 19:24:24 2016] [] ? usb_reset_device+0x18b/0x2a0 [usbcore]
[Tue Aug 9 19:24:24 2016] [] ? hid_reset+0x146/0x1b0 [usbhid]
[Tue Aug 9 19:24:24 2016] [] ? process_one_work+0x172/0x420
[Tue Aug 9 19:24:24 2016] [] ? worker_thread+0x113/0x4f0
[Tue Aug 9 19:24:24 2016] [] ? _schedule+0x2b1/0x700
[Tue Aug 9 19:24:24 2016] [] ? rescuer_thread+0x2d0/0x2d0
[Tue Aug 9 19:24:24 2016] [] ? kthread+0xbd/0xe0
[Tue Aug 9 19:24:24 2016] [] ? kthreadcreate_on_node+0x180/0x180
[Tue Aug 9 19:24:24 2016] [] ? ret_from_fork+0x58/0x90
[Tue Aug 9 19:24:24 2016] [] ? kthread_create_on_node+0x180/0x180

J'ai regardé l'état du processus khubd via ps, et il était en sommeil non interruptible haute priorité (D<) (j'aurai du sauvegarder le résultat du ps, je me rappelle plus de kworker) alors que maintenant, il est en sommeil interruptible (S).
J'avais beau dé/re-brancher le clavier, rien ne changeait (forcément, non interruptible, le sommeil). En désespoir de cause, j'ai fait un reboot, mais même ça ne fonctionnait plus. Bon, j'aurai pu chercher à «réparer» plus en profondeur, mais je n'avais rien d'important en cours, donc j'ai été au plus rapide, reboot à l'ancienne.

Par contre, je me dis que ça pourrait arriver à nouveau, donc mes questions sont:

  • comment faire dans ce genre de cas, en admettant que l'on peut se connecter en root de l'extérieur? En gros, comment supprimer le symptôme.
  • comment trouver la cause réelle du problème, ou au moins comment récupérer les informations nécessaire à ça? Parce que je ne pense pas vraiment que sauvegarder une stack trace va aider grand monde… Bien sûr, toujours en admettant qu'il est possible d'avoir un accès extérieur.

Je me demande si un clavier PS2 aurait fonctionné, du coup… dommage que j'en aie plus :/

  • # Rebooter...

    Posté par  . Évalué à 2.

    Bonsoir,

    Le message du noyau constate que la tâche qui retire le clavier de la configuration active ne veut pas se terminer car elle attend quelque chose, probablement que ton clavier réponde. Il est plus difficile de tuer une tâche de l'espace noyau qu'un processus utilisateur car cette dernière partage potentiellement sa mémoire avec d'autres tâches. La tuer pourrait donc déstabiliser encore un peu plus le système. Tu peux essayer de décharger (rmmod) les modules concernés, ici toute ta pile USB, mais sans grande garantie de succès, l'issue la plus probable étant de devoir redémarrer comme tu la fait. Le fait qu'un simple redémarrage du noyau n'ait pas été suffisant indique que le contrôleur USB devait être un peu déboussolé et donc que même si tu avais réussi à ne recharger que la pile USB, le résultat aurait été le même qu'un redémarrage du noyau.

    Pour aider les développeurs (quand c'est autre chose qu'une panne d'origine matérielle comme ici), le minimum est 1) la trace que tu as reproduite (donc oui elle aide souvent sinon elle ne serait pas affichée), 2) la version du logiciel, 3) la méthode de reproduction (ici: quel type de café?). Tu peux y ajouter une image de la mémoire du processus (core dump), le fichier fautif, la capture tcpdump, ou tout ce qui te semble utile à la reproduction aisée.

    Pour le clavier PS/2, outre en avoir un, il faut surtout avoir la prise pour le brancher… Je n'ai jamais renversé de liquide dessus à cette époque (bien qu'encore enfant), donc difficile de répondre même s'il est vrai que le code et l'électronique étaient plus simple.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.