Determinando a causa do pânico no kernel do Linux

Estou executando um derivado do Ubuntu 12.04 (amd64) e tenho tido problemas muito estranhos recentemente. Do nada, aparentemente, o X congelará completamente por um tempo (1-3 minutos?) E, em seguida, o sistema será reiniciado. Esse sistema está com overclock, mas muito estável, como verificado no Windows, o que me leva a acreditar que estou tendo um pânico no kernel ou um problema com um dos meus módulos. Mesmo no Linux, eu posso executar o LINPACK e não vejo uma falha, apesar de colocar uma carga ridícula na CPU. As falhas parecem ocorrer em momentos aleatórios, mesmo quando a máquina está ociosa.

Como posso depurar o que está travando o sistema?

Com o pressentimento de que poderia ser o driver proprietário da NVIDIA, eu voltei para a versão estável do driver, versão 304, e ainda sofro a falha.

Alguém pode me orientar sobre um bom procedimento de depuração para depois de uma falha? Eu ficaria mais do que feliz em inicializar em um pen drive e postar todos os meus arquivos de configuração pós-falha, só não tenho certeza do que eles seriam. Como posso descobrir o que está travando meu sistema?

Aqui estão alguns troncos, os culpados de sempre.

.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

Nem consigo encontrar um registro do acidente.

Acionar a falha não é tão simples, parece que acontece quando a GPU está tentando desenhar várias coisas ao mesmo tempo. Se eu colocar um vídeo do YouTube em tela cheia e deixá-lo repetir por um tempo ou percorrer uma tonelada de GIFs e uma notificação do Skype aparecer, às vezes ele trava. Totalmente coçando minha cabeça neste.

A CPU está com overclock para 4,8 GHz, mas é completamente estável e sobreviveu a enormes execuções do LINPACK e a 9 horas do Prime95 ontem sem uma única falha.

Atualizar

Eu tenho instalado kdump, crashe linux-crashdump, assim como os símbolos de depuração do kernel para meu kernel versão 3.2.0-35. Quando executo apport-unpacko arquivo do kernel com falha e, crashem seguida, no VmCoredespejo de memória, eis o que vejo:

      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 executo a logpartir do crashutilitário, vejo isso na parte inferior do log:

[ 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 gera o 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

Alguma ideia?

Eu tenho duas sugestões para começar.

O primeiro que você não vai gostar. Não importa o quão estável você pense que seu sistema com overclock é, seria o meu primeiro suspeito. E qualquer desenvolvedor que você relatar o problema dirá a mesma coisa. Sua carga de trabalho de teste estável não está necessariamente usando as mesmas instruções, estressando o subsistema de memória, tanto faz. Pare de fazer overclock. Se você quiser que as pessoas acreditem que o problema não está em overclock, faça-o acontecer quando não estiver em overclock para que você possa obter um relatório de erro limpo. Isso fará uma enorme diferença em quanto esforço outras pessoas investirão na solução desse problema. Ter um software livre de erros é um ponto de orgulho, mas os relatórios de pessoas com configurações de hardware particularmente questionáveis ​​são um tempo de espera frustrante que provavelmente não envolve nenhum bug real.

O segundo é obter os dados do oops, que, como você notou, não vão a nenhum dos lugares que você mencionou. Se a falha ocorrer apenas durante a execução do X11, acho que o console local está praticamente esgotado (de qualquer maneira), então você precisa fazer isso em um console serial, na rede ou salvando no disco local (o que é mais difícil do que pode parecer porque você não deseja que um kernel não confiável corrompa seu sistema de arquivos). Aqui estão algumas maneiras de fazer isso:

• use o netdump para salvar em um servidor pela rede. Eu não faço isso há anos, então não tenho certeza se esse software ainda está por aí e funciona com kernels modernos, mas é fácil o suficiente para que valha a pena tentar.
• inicialize usando um console serial ; você precisará de uma porta serial gratuita nas duas máquinas (seja uma antiga ou um adaptador serial USB) e um cabo de modem nulo; você configuraria a outra máquina para salvar a saída.
• O kdump parece ser o que as crianças legais usam hoje em dia e parece bastante flexível, embora não seja a minha preferência porque parece complexo de configurar. Em resumo, envolve a inicialização de um kernel diferente que pode fazer qualquer coisa e inspecionar o conteúdo da memória do antigo kernel, mas você precisa essencialmente construir todo o processo e não vejo muitas opções disponíveis. Atualização: Na verdade, existem algumas coisas interessantes de distribuição; no Ubuntu, linux-crashdump

Depois de obter as informações de depuração, existe uma ferramenta chamada ksymoops que você pode usar para transformar os endereços em nomes de símbolos e começar a ter uma idéia de como seu kernel falhou. E se o dump simbolizado não significa nada para você, pelo menos isso é algo útil para relatar aqui ou talvez na lista de distribuição / rastreador de erros da sua distribuição Linux.

A partir crashdo seu crashdump, você pode tentar digitação loge btpara obter uma informação pouco mais (coisas registrados durante o pânico e uma backtrace pilha). Você Fatal Machine checkparece estar vindo daqui , no entanto. Ao analisar o código, seu processador relatou uma exceção de verificação de máquina - um problema de hardware. Mais uma vez, minha primeira aposta seria devido ao overclock. Parece que pode haver uma mensagem mais específica na logsaída que pode lhe dizer mais.

Também a partir desse código, parece que se você inicializar com o mce=3parâmetro kernel, ele irá parar de travar ... mas eu realmente não recomendaria isso, exceto como uma etapa de diagnóstico. Se o kernel do Linux achar que vale a pena corrigir esse erro, provavelmente está certo.

a) Verifique se as mensagens do kernel estão sendo registradas em um arquivo pelo rsyslog daemon

vi /etc/rsyslog.conf

E adicione o seguinte

kern.*                 /var/log/kernel.log

Reinicie o rsyslogserviço.

/etc/initd.d/rsyslog restart

b) Anote os módulos carregados

`lsmod >/your/home/dir`

c) Como o pânico não é reprodutível, espere que isso aconteça

d) Após o pânico, inicialize o sistema usando um CD ao vivo ou de emergência

e) Monte os sistemas de arquivos (normalmente / será suficiente se / var e / home não são sistemas de arquivos separados) do sistema afetado ( pvs, vgs, lvscomandos precisam ser executados se você estiver usando LVM no sistema afetado para abrir o LV) mount -t ext4 /dev/sdXN /mnt

f) Vá para o /mnt/var/log/diretório e verifique o kernel.logarquivo. Isso deve fornecer informações suficientes para descobrir se o pânico está acontecendo em um módulo específico ou em outra coisa.

Seu processador está com overclock? Eu tive esse mesmo problema hoje quando estava jogando com o multiplicador no menu de overclocking na minha BIOS; vários multiplicadores em torno de 20x causariam isso. Reduzi para 18,5x (3,7GHz) e o problema desapareceu; Eu acho que foi um problema de placa-mãe / energia.

Definitivamente um problema no processador, observe as linhas que dizem: TSC 539b174dead ADDR 3fe98d264ebd MISC 1 [1561.519950] [Erro de hardware]: PROCESSOR 0: 206a7 TIME 1357862746 SOCKET 0 APIC 1 microcódigo 28. Processador 0 é o que o kernel usou para processar a falha (é importante em sistemas com várias CPUs) e o soquete 0 é o processador incorreto (embora eu assuma que você tenha apenas 1). Ou é ruim ou, como você notou, o overclock causa falhas. Sei que você disse que passou pelo prime95, mas como não tenho mais informações sobre a idade do sistema, estou procurando alguns canudos, como fica sua pasta térmica e você verificou se o seu LGA (sob o CPU) parece bem? Estou pensando que talvez pinos dobrados ou algum colar sob o LGA. Novamente, apenas causa raiz aqui.

Se isso não resolver o problema, há um pequeno truque que você pode fazer para usar o SMBIOS para descobrir exatamente onde o pânico ocorre, outra linha (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) é basicamente dados do SMBIOS que podem mostrar onde ocorreu a falha. Quando sua máquina estiver ligada, na linha de comando, execute "TSC 539b174de9d ADDR 3fe98d264ebd MISC 1" | sudo mcelog --ascii --dmi para obter a saída, isso indica que é um erro de hardware e até o DIMM em que estava processando, isso pode apontar para um DIMM ou caminho de barramento defeituoso, se a falha do DIMM saltar a cada falha, no entanto, isso aponta para a CPU.

Tínhamos um roteador mikrotik instalado em uma plataforma antiga. O ventilador parou de girar e causou o aquecimento do processador. O roteador inicia o Kernel Panic de vez em quando. Depois de trocar o ventilador da CPU, tudo correu bem.

Como você está fazendo um overclock de sua máquina, isso pode ser uma causa possível.