Ursache der Linux-Kernel-Panik ermitteln

Ich verwende ein Ubuntu 12.04-Derivat (amd64) und habe in letzter Zeit wirklich seltsame Probleme. Scheinbar friert X aus heiterem Himmel für eine Weile vollständig ein (1-3 Minuten?), Und dann wird das System neu gestartet. Dieses System ist übertaktet, aber sehr stabil, wie in Windows verifiziert, was mich zu der Annahme veranlasst, dass ich eine Kernel-Panik oder ein Problem mit einem meiner Module habe. Selbst unter Linux kann ich LINPACK ausführen und sehe keinen Absturz, obwohl die CPU lächerlich belastet wird. Abstürze scheinen zu zufälligen Zeiten vorzukommen, auch wenn die Maschine im Leerlauf steht.

Wie kann ich debuggen, was das System zum Absturz bringt?

Aus der Vermutung heraus, dass es sich um den proprietären NVIDIA-Treiber handeln könnte, habe ich auf die stabile Version des Treibers 304 zurückgegriffen und erlebe immer noch den Absturz.

Kann mich jemand nach einem Absturz durch ein gutes Debugging-Verfahren führen? Gerne boote ich von einem USB-Stick und poste alle meine Konfigurationsdateien nach dem Absturz. Ich bin mir nur nicht sicher, wie sie aussehen würden. Wie kann ich herausfinden, was mein System zum Absturz bringt?

Hier sind ein paar Protokolle, die üblichen Täter.

.xsession-Fehler : 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

Ich kann anscheinend nicht einmal eine Aufzeichnung des Absturzes finden.

Das Auslösen des Absturzes ist nicht so einfach, es scheint zu passieren, wenn die GPU versucht, mehrere Dinge gleichzeitig zu zeichnen. Wenn ich ein YouTube-Video im Vollbildmodus anlege und es eine Weile wiederholen lasse oder durch eine Menge GIFs scrolle und eine Skype-Benachrichtigung erscheint, stürzt es manchmal ab. Ich kratzte mich total am Kopf.

Die CPU ist auf 4,8 GHz übertaktet, aber sie ist absolut stabil und hat gestern riesige LINPACK-Läufe und 9 Stunden Prime95 ohne einen einzigen Absturz überstanden.

Aktualisieren

Ich habe installiert kdump, crashund linux-crashdumpsowie die Kernel - Debug - Symbole für meine Kernel - Version 3.2.0-35. Wenn ich apport-unpackdie abgestürzte Kerneldatei und dann crashden VmCoreAbsturzspeicherauszug ausführe, sehe ich Folgendes:

      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)

Wenn ich logvom crashDienstprogramm aus starte, wird am Ende des Protokolls Folgendes angezeigt:

[ 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 gibt den Backtrace aus:

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

Irgendwelche Ideen?

Ich habe zwei Vorschläge zu beginnen.

Das erste wirst du nicht mögen. Egal wie stabil Sie denken, Ihr übertaktetes System ist, es wäre mein erster Verdächtiger. Und jeder Entwickler, dem Sie das Problem melden, wird dasselbe sagen. Ihre stabile Test-Workload muss nicht unbedingt dieselben Anweisungen verwenden, was das Speichersubsystem in gleichem Maße belastet. Hör auf zu übertakten. Wenn Sie möchten, dass die Leute glauben, dass das Problem nicht übertaktet ist, sollten Sie dies tun, wenn Sie nicht übertaktet sind, damit Sie einen sauberen Fehlerbericht erhalten. Dies wird einen großen Unterschied darin machen, wie viel Aufwand andere Menschen in die Lösung dieses Problems investieren werden. Fehlerfreie Software zu haben, ist ein Grund zum Stolz, aber Berichte von Leuten mit besonders fragwürdigen Hardware-Setups sind frustrierend für die Zeit, die wahrscheinlich überhaupt keinen echten Fehler mit sich bringt.

Die zweite Möglichkeit besteht darin, die Hoppla-Daten abzurufen, die, wie Sie bemerkt haben, an keinen der von Ihnen genannten Orte gelangen. Wenn der Absturz nur unter X11 auftritt, ist die lokale Konsole meiner Meinung nach ziemlich ausgefallen (das ist ohnehin ein Problem). Sie müssen dies also über eine serielle Konsole, über das Netzwerk oder durch Speichern auf der lokalen Festplatte tun (was schwieriger ist als) es kann sich anhören, weil Sie nicht möchten, dass ein nicht vertrauenswürdiger Kernel Ihr Dateisystem beschädigt. Hier sind einige Möglichkeiten, dies zu tun:

• Verwenden Sie netdump , um auf einem Server über das Netzwerk zu speichern. Ich habe das seit Jahren nicht mehr gemacht, daher bin ich mir nicht sicher, ob es diese Software noch gibt, die mit modernen Kernels arbeitet, aber es ist einfach genug, dass es einen Versuch wert ist.
• über eine serielle Konsole booten ; Sie benötigen auf beiden Computern einen freien seriellen Anschluss (einen alten oder einen seriellen USB-Adapter) und ein Nullmodemkabel. Sie würden den anderen Computer so konfigurieren, dass die Ausgabe gespeichert wird.
• kdump scheint das zu sein, was die coolen Kids heutzutage verwenden, und es scheint ziemlich flexibel zu sein, obwohl es nicht meine Präferenz wäre, weil es komplex in der Einrichtung aussieht. Kurz gesagt, es geht darum, einen anderen Kernel zu booten, der alles kann und den Speicherinhalt des früheren Kernels überprüft, aber Sie müssen im Wesentlichen den gesamten Prozess erstellen, und ich sehe nicht viele vordefinierte Optionen da draußen. Update: Eigentlich gibt es ein paar nette Distributionssachen; auf Ubuntu, Linux-Crashdump

Sobald Sie die Debug-Informationen erhalten haben, gibt es ein Tool namens ksymoops , mit dem Sie die Adressen in Symbolnamen umwandeln und eine Vorstellung davon bekommen können, wie Ihr Kernel abgestürzt ist. Und wenn der symbolisierte Speicherauszug für Sie nichts bedeutet, ist dies zumindest hilfreich, wenn Sie ihn hier oder möglicherweise in der Mailing-Liste / dem Bug-Tracker Ihrer Linux-Distribution melden.

Von crashIhrem Absturzabbild aus können Sie versuchen , etwas einzugeben logund btmehr Informationen zu erhalten (während der Panik protokollierte Dinge und ein Stack-Backtrace). Ihr Fatal Machine checkscheint jedoch von hier zu kommen. Nach dem Überfliegen des Codes hat Ihr Prozessor eine Machine Check Exception gemeldet - ein Hardwareproblem. Wieder würde meine erste Wette auf Übertakten zurückzuführen sein. Es scheint, als ob die logAusgabe eine spezifischere Meldung enthält, die Ihnen mehr sagen könnte.

Auch von diesem Code aus sieht es so aus, als würde mce=3es nicht mehr abstürzen, wenn Sie mit dem Kernel-Parameter booten ... aber ich würde dies nicht wirklich empfehlen, außer als Diagnoseschritt. Wenn der Linux-Kernel denkt, dass dieser Fehler einen Absturz wert ist, ist er wahrscheinlich richtig.

a) Überprüfen Sie, ob Kernelmeldungen vom rsyslog-Daemon in einer Datei protokolliert werden

vi /etc/rsyslog.conf

Und fügen Sie Folgendes hinzu

kern.*                 /var/log/kernel.log

Starten Sie den rsyslogDienst neu.

/etc/initd.d/rsyslog restart

b) Notieren Sie sich die geladenen Module

`lsmod >/your/home/dir`

c) Warten Sie, bis die Panik nicht reproduzierbar ist

d) Sobald die Panik aufgetreten ist, starten Sie das System mit einer Live- oder Notfall-CD

e) Montieren Sie die Dateisysteme (normalerweise / genügt , wenn / var und / home nicht getrennte Dateisysteme) des betroffenen Systems ( pvs, vgs, lvsmüssen Befehle ausgeführt werden , wenn Sie LVM auf dem betroffenen System werden mit dem LV bringen) mount -t ext4 /dev/sdXN /mnt

f) Gehen Sie in das /mnt/var/log/Verzeichnis und überprüfen Sie die kernel.logDatei. Dies sollte Ihnen genügend Informationen geben, um herauszufinden, ob die Panik für ein bestimmtes Modul oder etwas anderes auftritt.

Ist Ihr Prozessor übertaktet? Ich hatte heute das gleiche Problem, als ich mit dem Multiplikator im Übertaktungsmenü in meinem BIOS spielte. Dies würde durch verschiedene Multiplikatoren um das 20-fache geschehen. Ich reduzierte es auf 18,5x (3,7 GHz) und das Problem ging weg; Ich denke, es war ein Motherboard / Power-Problem.

Beachten Sie auf jeden Fall die Zeilen, in denen steht: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [Hardwarefehler]: PROCESSOR 0: 206a7 TIME 1357862746 SOCKET 0 APIC 1 Microcode 28. Prozessor 0 ist das, was der Kernel zum Verarbeiten des Absturzes verwendet hat (ist in Multi-CPU-Systemen von Bedeutung) und Sockel 0 ist der fehlerhafte Prozessor (obwohl ich davon ausgehe, dass Sie nur 1 haben). Entweder ist es schlecht oder, wie Sie bemerkt haben, übertaktet zu werden, kann zu Fehlern führen. Ich weiß, dass Sie gesagt haben, Sie haben es durch prime95 geschafft, aber da ich keine weiteren Informationen darüber habe, wie alt das System ist, greife ich nach ein paar Strohhalmen, wie sieht Ihre Wärmeleitpaste aus, und haben Sie überprüft, ob Ihre LGA (unter der CPU) sieht in Ordnung aus? Ich denke vielleicht verbogene Stifte oder etwas Paste unter der LGA. Wieder nur Grundursache hier.

Wenn das Problem dadurch nicht behoben werden kann, können Sie mit Ihrem SMBIOS einen kleinen Trick ausführen, um herauszufinden, wo genau die Panik auftritt. Eine andere Zeile (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) enthält im Grunde SMBIOS-Daten, die angeben, wo der Absturz stattgefunden hat. Wenn Ihr Computer hochgefahren ist, geben Sie in der Befehlszeile "TSC 539b174de9d ADDR 3fe98d264ebd MISC 1" | ein sudo mcelog --ascii --dmi, um die Ausgabe zu erhalten. Dies zeigt an, dass es sich um einen Hardwarefehler handelt und auch, auf welchem ​​DIMM es sich befand. Dies kann auf ein fehlerhaftes DIMM oder einen fehlerhaften Buspfad hinweisen, wenn der DIMM-Fehler bei jedem DIMM-Fehler auftritt Absturz zeigt dies jedoch auf die CPU.

Wir hatten einen Mikrotik-Router auf einem alten Rig installiert. Der Lüfter hörte auf zu drehen und der Prozessor wurde heiß. Der Router startet dann von Zeit zu Zeit mit Kernel Panic. Nach dem Wechsel des CPU-Lüfters lief alles gut.

Da Sie Ihre Maschine übertakten, kann dies eine mögliche Ursache sein.