Comment rechercher la cause du blocage total?

Ma machine Arch se bloque parfois, ne répondant soudainement en aucune façon à la souris ou au clavier. Le curseur est figé. Ctrl-Alt-Backsp n'arrêtera pas X11 et ctrl-alt-del ne fait rien. Les tracés d'activité du processeur, du réseau et du disque dans conky et icewm cessent de se mettre à jour. En quelques minutes, le ventilateur se met en marche. La seule façon de faire faire quoi que ce soit à l'ordinateur est de couper l'alimentation.

Lorsqu'il démarre, les moniteurs de température du processeur affichent 70 à 80 ° C. Avant le coup, je faisais généralement des activités de faible intensité comme surfer sur le Web autour de 50 ° C.

Les journaux ne montrent rien de spécial par rapport à un arrêt normal. Le vérificateur de mémoire fonctionne correctement avec zéro défaut.

Comment puis-je savoir pourquoi il a raccroché? Y a-t-il des informations supplémentaires que je peux trouver pour un indice? Y a-t-il quelque chose de moins drastique que la mise hors tension pour obtenir une sorte d'action, si seulement une coquille limitée ou juste des bips, mais pourrait donner un indice?

La machine est un ordinateur portable Gateway P6860 17 "(encombrant mais puissant) et il fonctionne sous Arch 64bit, à jour (en mars 2011). J'avais Arch depuis longtemps sans ce problème, passé à Ubuntu pendant environ une semaine puis se retira dans une nouvelle installation d'Arch. C'est là que les tentures commencèrent.

MISE À JOUR: Oui, c'est sûr qu'il surchauffe. À une température, la souris et le clavier cessent de fonctionner, devenant parfois fonctionnels après plusieurs minutes de refroidissement. À une température plus élevée, des choses pires se produisent, comme la non-réponse totale, y compris l'ignorance de SysRq. Cette condition est rapidement suivie d'une coupure de courant soudaine. J'ai résolu le problème en achetant un nouvel ordinateur 8D

La réponse de Frederik impliquant SysRq magique et les vidages du noyau fonctionnera si le noyau est toujours en cours d'exécution et n'est pas vraiment bloqué. Le noyau peut être en boucle occupée pour une raison quelconque.

Le fait qu'il ne réponde pas à Ctrl-Alt-Del me dit que ce n'est probablement pas le cas et que la machine se bloque durement. Cela signifie une défaillance matérielle ou quelque chose de étroitement lié, comme un mauvais pilote.

Votre test de vérification de la mémoire est bon, si vous le laissez s'exécuter suffisamment longtemps. Vous devriez également essayer d'autres choses pour essayer de stresser le système, comme StressLinux . Les repères de longue durée sont également bons.

Une autre chose à essayer est de démarrer le système avec un CD live Ubuntu et d'essayer d'utiliser le système normalement. Si le retour temporaire à Ubuntu ne provoque pas la récurrence du problème, il y a de fortes chances qu'il ne s'agisse pas réellement d'un matériel défectueux, mais d'une des choses liées comme un mauvais pilote ou un noyau mal configuré. Il est tout à fait possible qu'une distribution plus populaire comme Ubuntu ait une configuration de noyau plus stable qu'une architecture comme Arch, simplement en raison du plus grand nombre de machines sur lesquelles elle a été essayée pendant la phase de test de la distribution.

Concernant le gel, il y a quelques options:

• en utilisant un port série si votre box en a un pour y récupérer le vidage en ajoutant console=ttyS0aux options de démarrage, comme décrit ici . Vous avez besoin d'une deuxième machine avec un port série et un câble null modem pour intercepter le fichier de vidage.

• en utilisant netconsole pour obtenir le vidage sur le réseau, voir ici .

• En utilisant kexec / kdump de cette façon, vous obtenez un vidage local, voir ici .

En ce qui concerne le problème de mise hors tension propre, je vous suggère d'utiliser la touche magique SysRq pour 'S'ync les disques,' U 'les monter, puis re'B'oot la boîte (les lettres sont celles que vous devez taper avec alt -sysrq.

Edit: Si vous postez le oops / trace sur le lkml, vous devez utiliser une version récente (de préférence la plus récente) du noyau et aucun module propriétaire.