Determinare la causa del panico del kernel Linux

Sto eseguendo un derivato di Ubuntu 12.04 (amd64) e di recente ho avuto problemi davvero strani. All'improvviso, apparentemente, X si bloccherà completamente per un po '(1-3 minuti?) E quindi il sistema si riavvierà. Questo sistema è overcloccato, ma molto stabile come verificato in Windows, il che mi porta a credere che sto avendo un panico del kernel o un problema con uno dei miei moduli. Anche in Linux, posso eseguire LINPACK e non vedrò un arresto anomalo nonostante il carico ridicolo sulla CPU. Gli arresti anomali sembrano verificarsi in momenti casuali, anche quando la macchina è inattiva.

Come posso eseguire il debug di ciò che sta bloccando il sistema?

Con la sensazione che potrebbe essere il driver proprietario NVIDIA, sono tornato fino alla versione stabile del driver, versione 304 e ho ancora il crash.

Qualcuno può guidarmi attraverso una buona procedura di debug per dopo un incidente? Sarei più che felice di avviare una chiavetta USB e pubblicare tutti i miei file di configurazione post-crash, non sono sicuro di come sarebbero. Come posso sapere cosa sta andando in crash il mio sistema?

Ecco un mucchio di tronchi, i soliti colpevoli.

.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

Non riesco nemmeno a trovare un record dell'incidente.

Innescare il crash non è così semplice, sembra accadere quando la GPU sta cercando di disegnare più cose contemporaneamente. Se inserisco un video di YouTube a schermo intero e lo lascio ripetere per un po 'o scorro una tonnellata di GIF e viene visualizzata una notifica Skype, a volte si blocca. Mi gratto totalmente la testa su questo.

La CPU è overcloccata a 4.8GHz, ma è completamente stabile ed è sopravvissuta ieri a enormi corse LINPACK e 9 ore di Prime95 senza un singolo crash.

Aggiornare

Ho installato kdump, crashe linux-crashdump, oltre ai simboli di debug del kernel per la mia versione 3.2.0-35 del kernel. Quando corro apport-unpacksul file del kernel bloccato e quindi crashsul VmCoredump del crash, ecco cosa vedo:

      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)

Quando eseguo logdal crashprogramma di utilità, vedo questo in fondo il registro:

[ 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 genera il backtrace:

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

Qualche idea?

Ho due suggerimenti per iniziare.

Il primo che non ti piacerà. Non importa quanto pensi sia stabile il tuo sistema overcloccato, sarebbe il mio primo sospettato. E qualsiasi sviluppatore a cui riferisci il problema dirà la stessa cosa. Il carico di lavoro di prova stabile non utilizza necessariamente le stesse istruzioni, sottolineando il sottosistema di memoria, qualunque cosa. Ferma l'overclocking. Se vuoi che le persone credano che il problema non sia l'overclocking, allora fallo accadere quando non eseguono l'overclocking in modo da poter ottenere un rapporto pulito sui bug. Ciò farà un'enorme differenza nello sforzo che altre persone investiranno per risolvere questo problema. Avere un software privo di bug è un punto di orgoglio, ma i rapporti di persone con configurazioni hardware particolarmente discutibili sono frustranti sprechi di tempo che probabilmente non comportano affatto un vero bug.

Il secondo è quello di ottenere i dati di oops, che come hai notato non va in nessuno dei luoghi che hai menzionato. Se il crash si verifica solo durante l'esecuzione di X11, penso che la console locale sia praticamente fuori uso (è comunque una seccatura), quindi è necessario farlo su una console seriale, sulla rete o salvando su disco locale (che è più complicato di può sembrare perché non vuoi che un kernel inaffidabile corrompa il tuo filesystem). Ecco alcuni modi per farlo:

• utilizzare netdump per salvare su un server in rete. Non lo faccio da anni, quindi non sono sicuro che questo software sia ancora in circolazione e funzioni con kernel moderni, ma è abbastanza facile che valga la pena provare.
• avviare usando una console seriale ; avrai bisogno di una porta seriale libera su entrambe le macchine (sia una vecchia scuola o un adattatore seriale USB) e un cavo null modem; configureresti l'altra macchina per salvare l'output.
• kdump sembra essere quello che usano i ragazzi fantastici al giorno d'oggi, e sembra abbastanza flessibile, anche se non sarebbe la mia preferenza perché sembra complicato da configurare. In breve, comporta l'avvio di un kernel diverso che può fare qualsiasi cosa e ispezionare i contenuti di memoria del precedente kernel, ma devi essenzialmente costruire l'intero processo e non vedo molte opzioni predefinite là fuori. Aggiornamento: ci sono alcune cose interessanti sulla distribuzione, in realtà; su Ubuntu, linux-crashdump

Una volta ottenute le informazioni di debug, c'è uno strumento chiamato ksymoops che puoi usare per trasformare gli indirizzi in nomi di simboli e iniziare a farti un'idea di come il tuo kernel si è bloccato. E se il dump simbolizzato non significa nulla per te, almeno questo è qualcosa di utile da segnalare qui o forse sulla mailing list / bug tracker della tua distribuzione Linux.

Dal crashtuo crashdump, puoi provare a digitare loge btottenere un po 'più di informazioni (cose registrate durante il panico e una backtrace dello stack). Il tuo Fatal Machine checksembra provenire da qui , però. Dalla scrematura del codice, il processore ha segnalato un'eccezione di controllo macchina - un problema hardware. Ancora una volta, la mia prima scommessa sarebbe dovuta all'overclocking. Sembra che potrebbe esserci un messaggio più specifico lognell'output che potrebbe dirti di più.

Anche da quel codice, sembra che se si avvia con il mce=3parametro kernel, smetterà di bloccarsi ... ma non lo consiglierei davvero se non come un passo diagnostico. Se il kernel di Linux pensa che questo errore meriti di essere superato, probabilmente è giusto.

a) Controllare se i messaggi del kernel sono stati registrati in un file dal demone rsyslog

vi /etc/rsyslog.conf

E aggiungi quanto segue

kern.*                 /var/log/kernel.log

Riavvia il rsyslogservizio.

/etc/initd.d/rsyslog restart

b) Prendere nota dei moduli caricati

`lsmod >/your/home/dir`

c) Poiché il panico non è riproducibile, attendi che si verifichi

d) Una volta che si è verificato il panico, avviare il sistema utilizzando un CD live o di emergenza

e) Montare i filesystem (di solito / sarà sufficiente se / var e / home non sono i sistemi di file separati) del sistema interessato ( pvs, vgs, lvsi comandi devono essere eseguiti se si utilizza LVM sul sistema interessato per far apparire il LV) mount -t ext4 /dev/sdXN /mnt

f) Vai alla /mnt/var/log/directory e controlla il kernel.logfile. Questo dovrebbe darti abbastanza informazioni per capire se il panico sta accadendo per un particolare modulo o qualcos'altro.

Il tuo processore è overcloccato? Ho avuto questo stesso problema oggi quando stavo giocando con il moltiplicatore nel menu over-clock nel mio BIOS; vari moltiplicatori intorno a 20 volte causerebbero questo accada. L'ho ridotto a 18,5x (3,7 GHz) e il problema è scomparso; Penso che sia stato un problema con la scheda madre / alimentazione.

Sicuramente un problema con il processore, nota le righe che dicono: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [Errore hardware]: PROCESSOR 0: 206a7 TIME 1357862746 SOCKET 0 Microcodice APIC 1 28. Il processore 0 è quello che il kernel ha usato per elaborare l'incidente (conta nei sistemi multi-cpu) e socket 0 è il processore offensivo (anche se suppongo che tu ne abbia solo 1). O è male o come hai notato essere overclockato causa di guasti. So che hai detto che l'hai preso attraverso prime95 ma dal momento che non ho più informazioni su quanti anni ha il sistema sto afferrando alcune cannucce, come appare la tua pasta termica e hai controllato per assicurarti che il tuo LGA (sotto il CPU) sembra a posto? Sto pensando forse pin piegati o un po 'di pasta sotto l'LGA. Ancora una volta solo causa root qui.

Se ciò non risolve il problema, è possibile fare un piccolo trucco per utilizzare SMBIOS per individuare esattamente dove si verifica il panico, un'altra riga (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) sono fondamentalmente dati SMBIOS che possono mostrare dove si è verificato l'incidente. Quando la macchina è accesa, nella riga di comando, echo "TSC 539b174de9d ADDR 3fe98d264ebd MISC 1" | sudo mcelog --ascii --dmi per ottenere l'output, questo ti dirà che si tratta di un errore hardware e persino su quale modulo DIMM stava elaborando, questo può indicare un DIMM o un percorso bus difettoso, se l'errore DIMM salta intorno con ogni crash, tuttavia, questo indica la CPU.

Avevamo un router mikrotik installato su un vecchio impianto. La ventola ha smesso di girare causando il riscaldamento del processore. Il router inizia quindi a Kernel Panic di tanto in tanto. Dopo aver cambiato la ventola della CPU è andato tutto bene.

Dato che stai overcloccando la tua macchina può essere una possibile causa.