Déterminer la cause de la panique du noyau Linux

J'utilise un dérivé d'Ubuntu 12.04 (amd64) et j'ai eu des problèmes vraiment étranges récemment. Apparemment, X gèlera complètement pendant un certain temps (1-3 minutes?) Puis le système redémarrera. Ce système est overclocké, mais très stable comme vérifié dans Windows, ce qui m'amène à croire que j'ai une panique du noyau ou un problème avec l'un de mes modules. Même sous Linux, je peux exécuter LINPACK et je ne verrai pas de plantage malgré une charge ridicule sur le CPU. Les plantages semblent se produire à des moments aléatoires, même lorsque la machine est inactive.

Comment puis-je déboguer ce qui plante le système?

Sur un pressentiment que ce pourrait être le pilote NVIDIA propriétaire, je suis revenu à la version stable du pilote, la version 304 et je continue de rencontrer le crash.

Quelqu'un peut-il me guider à travers une bonne procédure de débogage après un crash? Je serais plus qu'heureux de démarrer dans une clé USB et de publier tous mes fichiers de configuration post-crash, je ne suis tout simplement pas sûr de ce qu'ils seraient. Comment savoir ce qui bloque mon système?

Voici un tas de journaux, les coupables habituels.

Erreurs .xsession : http://pastebin.com/EEDtVkVm

/var/log/Xorg.0.log : http://pastebin.com/ftsG5VAn

/var/log/kern.log : http://pastebin.com/Hsy7jcHZ

/ var / log / syslog : http://pastebin.com/9Fkp3FMz

Je n'arrive même pas à trouver un enregistrement du crash du tout.

Déclencher le crash n'est pas si simple, il semble se produire lorsque le GPU essaie de dessiner plusieurs choses à la fois. Si je mets une vidéo YouTube en plein écran et que je la répète pendant un certain temps ou que je fais défiler une tonne de GIF et qu'une notification Skype s'affiche, parfois elle se bloque. Je me gratte complètement la tête sur celui-ci.

Le processeur est overclocké à 4,8 GHz, mais il est complètement stable et a survécu à d'énormes courses LINPACK et à 9 heures de Prime95 hier sans un seul crash.

Mise à jour

Je l' ai installé kdump, crashet linux-crashdump, ainsi que les symboles de débogage du noyau pour ma version du noyau 3.2.0-35. Lorsque je lance apport-unpacksur le fichier du noyau écrasé, puis crashsur le VmCorevidage sur incident, voici ce que je vois:

      KERNEL: /usr/lib/debug/boot/vmlinux-3.2.0-35-generic
    DUMPFILE: Downloads/crash/VmCore
        CPUS: 8
        DATE: Thu Jan 10 16:05:55 2013
      UPTIME: 00:26:04
LOAD AVERAGE: 2.20, 0.84, 0.49
       TASKS: 614
    NODENAME: mightymoose
     RELEASE: 3.2.0-35-generic
     VERSION: #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012
     MACHINE: x86_64  (3499 Mhz)
      MEMORY: 8 GB
       PANIC: "[ 1561.519960] Kernel panic - not syncing: Fatal Machine check"
         PID: 0
     COMMAND: "swapper/5"
        TASK: ffff880211251700  (1 of 8)  [THREAD_INFO: ffff880211260000]
         CPU: 5
       STATE: TASK_RUNNING (PANIC)

Lorsque je cours à logpartir de l' crashutilitaire, je vois ceci au bas du journal:

[ 1561.519943] [Hardware Error]: CPU 4: Machine Check Exception: 5 Bank 3: be00000000800400
[ 1561.519946] [Hardware Error]: RIP !INEXACT! 33:<00007fe99ae93e54> 
[ 1561.519948] [Hardware Error]: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 
[ 1561.519950] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 1 microcode 28
[ 1561.519951] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519953] [Hardware Error]: CPU 0: Machine Check Exception: 4 Bank 3: be00000000800400
[ 1561.519955] [Hardware Error]: TSC 539b174de9d ADDR 3fe98d264ebd MISC 1 
[ 1561.519957] [Hardware Error]: PROCESSOR 0:206a7 TIME 1357862746 SOCKET 0 APIC 0 microcode 28
[ 1561.519958] [Hardware Error]: Run the above through 'mcelog --ascii'
[ 1561.519959] [Hardware Error]: Machine check: Processor context corrupt
[ 1561.519960] Kernel panic - not syncing: Fatal Machine check
[ 1561.519962] Pid: 0, comm: swapper/5 Tainted: P   M     C O 3.2.0-35-generic #55-Ubuntu
[ 1561.519963] Call Trace:
[ 1561.519964]  <#MC>  [<ffffffff81644340>] panic+0x91/0x1a4
[ 1561.519971]  [<ffffffff8102abeb>] mce_panic.part.14+0x18b/0x1c0
[ 1561.519973]  [<ffffffff8102ac80>] mce_panic+0x60/0xb0
[ 1561.519975]  [<ffffffff8102aec4>] mce_reign+0x1f4/0x200
[ 1561.519977]  [<ffffffff8102b175>] mce_end+0xf5/0x100
[ 1561.519979]  [<ffffffff8102b92c>] do_machine_check+0x3fc/0x600
[ 1561.519982]  [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519984]  [<ffffffff8165d78c>] machine_check+0x1c/0x30
[ 1561.519986]  [<ffffffff8136d48f>] ? intel_idle+0xbf/0x150
[ 1561.519987]  <<EOE>>  [<ffffffff81509697>] ? menu_select+0xe7/0x2c0
[ 1561.519991]  [<ffffffff815082d1>] cpuidle_idle_call+0xc1/0x280
[ 1561.519994]  [<ffffffff8101322a>] cpu_idle+0xca/0x120
[ 1561.519996]  [<ffffffff8163aa9a>] start_secondary+0xd9/0xdb

bt sort la trace:

PID: 0      TASK: ffff880211251700  CPU: 5   COMMAND: "swapper/5"
 #0 [ffff88021ed4aba0] machine_kexec at ffffffff8103947a
 #1 [ffff88021ed4ac10] crash_kexec at ffffffff810b52c8
 #2 [ffff88021ed4ace0] panic at ffffffff81644347
 #3 [ffff88021ed4ad60] mce_panic.part.14 at ffffffff8102abeb
 #4 [ffff88021ed4adb0] mce_panic at ffffffff8102ac80
 #5 [ffff88021ed4ade0] mce_reign at ffffffff8102aec4
 #6 [ffff88021ed4ae40] mce_end at ffffffff8102b175
 #7 [ffff88021ed4ae70] do_machine_check at ffffffff8102b92c
 #8 [ffff88021ed4af50] machine_check at ffffffff8165d78c
    [exception RIP: intel_idle+191]
    RIP: ffffffff8136d48f  RSP: ffff880211261e38  RFLAGS: 00000046
    RAX: 0000000000000020  RBX: 0000000000000008  RCX: 0000000000000001
    RDX: 0000000000000000  RSI: ffff880211261fd8  RDI: ffffffff81c12f00
    RBP: ffff880211261e98   R8: 00000000fffffffc   R9: 0000000000000f9f
    R10: 0000000000001e95  R11: 0000000000000000  R12: 0000000000000003
    R13: ffff88021ed5ac70  R14: 0000000000000020  R15: 12d818fb42cfe42b
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
--- <MCE exception stack> ---
 #9 [ffff880211261e38] intel_idle at ffffffff8136d48f
#10 [ffff880211261ea0] cpuidle_idle_call at ffffffff815082d1
#11 [ffff880211261f00] cpu_idle at ffffffff8101322a

Des idées?

J'ai deux suggestions pour commencer.

Le premier tu ne vas pas aimer. Peu importe la stabilité de votre système overclocké, ce serait mon premier suspect. Et tout développeur pour lequel vous signalez le problème dira la même chose. Votre charge de travail de test stable n'utilise pas nécessairement les mêmes instructions, ce qui met autant l'accent sur le sous-système de mémoire. Arrêtez l'overclocking. Si vous voulez que les gens croient que le problème n'est pas l'overclocking, alors faites-le se produire sans overclocking afin que vous puissiez obtenir un rapport de bogue propre. Cela fera une énorme différence dans les efforts que d'autres personnes investiront pour résoudre ce problème. Avoir un logiciel sans bogue est une fierté, mais les rapports de personnes avec des configurations matérielles particulièrement douteuses sont des pertes de temps frustrantes qui n'impliquent probablement pas un vrai bogue du tout.

La seconde consiste à obtenir les données oops, qui, comme vous l'avez remarqué, ne vont à aucun des endroits que vous avez mentionnés. Si le crash ne se produit que lors de l'exécution de X11, je pense que la console locale est à peu près hors (c'est quand même pénible), vous devez donc le faire sur une console série, sur le réseau ou en enregistrant sur le disque local (ce qui est plus délicat que cela peut sembler parce que vous ne voulez pas qu'un noyau non fiable puisse corrompre votre système de fichiers). Voici quelques façons de procéder:

• utilisez netdump pour enregistrer sur un serveur sur le réseau. Je ne l'ai pas fait depuis des années, donc je ne suis pas sûr que ce logiciel existe toujours et fonctionne avec les noyaux modernes, mais c'est assez facile pour que ça vaille le coup.
• démarrer à l'aide d'une console série ; vous aurez besoin d'un port série libre sur les deux machines (que ce soit une ancienne école ou un adaptateur série USB) et un câble null modem; vous configurez l'autre machine pour enregistrer la sortie.
• kdump semble être ce que les enfants cool utilisent de nos jours, et semble assez flexible, bien que ce ne soit pas ma préférence car il semble complexe à configurer. En bref, cela implique de démarrer un noyau différent qui peut faire n'importe quoi et inspecter le contenu de la mémoire de l'ancien noyau, mais vous devez essentiellement construire tout le processus et je ne vois pas beaucoup d'options en conserve. Mise à jour: Il y a en fait de belles choses de distribution; sur Ubuntu, linux-crashdump

Une fois que vous obtenez les informations de débogage, il existe un outil appelé ksymoops que vous pouvez utiliser pour transformer les adresses en noms de symboles et commencer à avoir une idée de la façon dont votre noyau s'est écrasé. Et si le vidage symbolisé ne signifie rien pour vous, au moins c'est quelque chose d'utile à signaler ici ou peut-être sur la liste de diffusion / suivi des bogues de votre distribution Linux.

À partir crashde votre crashdump, vous pouvez essayer de taper loget btd'obtenir un peu plus d'informations (les choses enregistrées pendant la panique et une trace de pile). Vous semblez Fatal Machine checkcependant venir d' ici . Après avoir effacé le code, votre processeur a signalé une exception de vérification de la machine - un problème matériel. Encore une fois, mon premier pari serait dû à l'overclocking. Il semble qu'il puisse y avoir un message plus spécifique dans la logsortie qui pourrait vous en dire plus.

De plus, à partir de ce code, il semble que si vous démarrez avec le mce=3paramètre du noyau, il cessera de planter ... mais je ne le recommanderais pas vraiment, sauf comme étape de diagnostic. Si le noyau Linux pense que cette erreur vaut la peine de s'écraser, c'est probablement vrai.

a) Vérifiez si les messages du noyau sont enregistrés dans un fichier par le démon rsyslog

vi /etc/rsyslog.conf

Et ajoutez ce qui suit

kern.*                 /var/log/kernel.log

Redémarrez le rsyslogservice.

/etc/initd.d/rsyslog restart

b) Prenez note des modules chargés

`lsmod >/your/home/dir`

c) Comme la panique n'est pas reproductible, attendez qu'elle se produise

d) Une fois que la panique s'est produite, démarrez le système à l'aide d'un CD live ou d'urgence

e) Monter les systèmes de fichiers (généralement / sera suffisant si / var et / home ne sont pas des systèmes de fichiers séparés) du système affecté ( pvs, vgs, les lvscommandes doivent être exécutées si vous utilisez LVM sur le système affecté pour faire apparaître le LV) mount -t ext4 /dev/sdXN /mnt

f) Allez dans le /mnt/var/log/répertoire et vérifiez le kernel.logfichier. Cela devrait vous donner suffisamment d'informations pour savoir si la panique se produit pour un module particulier ou autre chose.

Votre processeur est-il overclocké? J'ai eu ce même problème aujourd'hui quand je jouais avec le multiplicateur dans le menu de sur-horloge de mon BIOS; divers multiplicateurs autour de 20x provoqueraient cela. Je l'ai réduit à 18,5x (3,7 GHz) et le problème a disparu; Je pense que c'était un problème de carte mère / d'alimentation.

Certainement un problème de processeur, notez les lignes qui disent: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [Erreur matérielle]: PROCESSOR 0: 206a7 TIME 1357862746 SOCKET 0 APIC 1 microcode 28. Le processeur 0 est ce que le noyau a utilisé pour traiter le crash (importe dans les systèmes multi-processeurs) et le socket 0 est le processeur incriminé (bien que je suppose que vous n'en avez qu'un). Soit c'est mauvais, soit comme vous l'avez remarqué, étant overclocké, cause de défauts. Je sais que vous avez dit que vous l'avez traversé avec Prime95, mais comme je n'ai pas plus d'informations sur l'âge du système, je prends quelques pailles, à quoi ressemble votre pâte thermique et avez-vous vérifié que votre LGA (sous la CPU) semble bien? Je pense peut-être à des broches tordues ou à de la pâte sous la LGA. Encore une fois, juste la cause des racines ici.

Si cela ne résout pas le problème, vous pouvez utiliser votre SMBIOS pour trouver où la panique frappe exactement, une autre ligne (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) est essentiellement des données SMBIOS qui peuvent indiquer où le crash s'est produit. Lorsque votre machine est en marche, lors de l'exécution en ligne de commande, faites écho à "TSC 539b174de9d ADDR 3fe98d264ebd MISC 1" | sudo mcelog --ascii --dmi pour obtenir la sortie, cela vous indiquera qu'il s'agit d'une erreur matérielle et même sur quel module DIMM il était en train de traiter, cela peut indiquer un module DIMM ou un chemin de bus défectueux, si la défaillance du module DIMM saute à chaque planter cependant, cela pointe vers le CPU.

Nous avions un routeur mikrotik installé sur une ancienne plate-forme. Le ventilateur a cessé de tourner et a fait chauffer le processeur. Le routeur commence alors de temps en temps à Kernel Panic. Après avoir changé le ventilateur du CPU, tout s'est bien passé.

Puisque vous overclockez votre machine, cela peut être une cause possible.