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 qu'il pourrait s'agir du pilote NVIDIA propriétaire, je suis revenu à la version stable du pilote, la version 304 et je subis toujours 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 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.
. xsession-errors : 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
J'ai installé kdump, crash et linux-crashdump, ainsi que les symboles de débogage du noyau pour ma version du noyau 3.2.0-35. Quand je lance apport-unpack sur le fichier du noyau planté, puis crash sur le VmCore crash dump, 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 j'exécute log à partir de l'utilitaire crash, 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 dans 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 un problème), 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 via 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 qu'il vaille le coup.
- démarrer en utilisant 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 des trucs sympas en fait; 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 de crash sur votre crashdump, vous pouvez essayer de taper log et bt pour obtenir un peu plus d'informations (les choses enregistrées pendant la panique et une trace de pile). Votre Fatal Machine check semble provenir de ici , cependant. De l'écrémage du code, votre processeur a signalé un Machine Check Exception - 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 sortie log qui pourrait vous en dire plus.
De plus, à partir de ce code, il semble que si vous démarrez avec le mce=3 paramè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 mérite d'être écrasée, 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 service rsyslog.
/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) Montez les systèmes de fichiers (généralement/suffira si/var et/home ne sont pas des systèmes de fichiers distincts) du système affecté (les commandes pvs, vgs, lvs doivent être exécuté si vous utilisez LVM sur le système affecté pour afficher le LV) mount -t ext4 /dev/sdXN /mnt
f) Allez à /mnt/var/log/ répertoire et vérifiez le kernel.log fichier. 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-CPU) 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, 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 montrer où le crash s'est produit. Lorsque votre machine est en marche, exécutez la ligne de commande en é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.