Determinar la causa del pánico del kernel de Linux

Estoy ejecutando un derivado de Ubuntu 12.04 (amd64) y recientemente he tenido problemas realmente extraños. Aparentemente, al parecer, X se congelará por completo durante un tiempo (¿1-3 minutos?) Y luego el sistema se reiniciará. Este sistema está overclockeado, pero es muy estable como se verificó en Windows, lo que me lleva a creer que tengo un kernel panic o un problema con uno de mis módulos. Incluso en Linux, puedo ejecutar LINPACK y no veré un bloqueo a pesar de poner una carga ridícula en la CPU. Los bloqueos parecen ocurrir en momentos aleatorios, incluso cuando la máquina está inactiva.

¿Cómo puedo depurar lo que está bloqueando el sistema?

Con el presentimiento de que podría ser el controlador propietario de NVIDIA, volví a la versión estable del controlador, la versión 304, y aún sigo experimentando el bloqueo.

¿Alguien puede guiarme a través de un buen procedimiento de depuración para después de un bloqueo? Me encantaría arrancar en una memoria USB y publicar todos mis archivos de configuración posteriores al bloqueo, pero no estoy seguro de cuáles serían. ¿Cómo puedo averiguar qué está bloqueando mi sistema?

Aquí hay un montón de registros, los culpables habituales.

.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

Ni siquiera puedo encontrar un registro del accidente en absoluto.

Disparar el bloqueo no es tan simple, parece suceder cuando la GPU está tratando de dibujar varias cosas a la vez. Si pongo un video de YouTube en pantalla completa y lo dejo repetir por un tiempo o me desplazo por una tonelada de GIF y aparece una notificación de Skype, a veces se bloquea. Rascando totalmente mi cabeza en este caso.

La CPU está overclockeada a 4.8GHz, pero es completamente estable y ha sobrevivido a las grandes ejecuciones de LINPACK y 9 horas de Prime95 ayer sin un solo bloqueo.

Actualizar

He instalado kdump, crashy linux-crashdump, así como los símbolos de depuración del kernel para mi kernel versión 3.2.0-35. Cuando ejecuto apport-unpackel archivo del kernel bloqueado y luego crashen el VmCorevolcado de memoria, esto es lo que veo:

      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)

Cuando ejecuto logdesde la crashutilidad, veo esto en la parte inferior del 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 da salida a la traza inversa:

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

¿Algunas ideas?

Tengo dos sugerencias para comenzar.

Lo primero que no te va a gustar. No importa cuán estable creas que es tu sistema overclockeado, sería mi primer sospechoso. Y cualquier desarrollador al que le informe el problema le dirá lo mismo. Su carga de trabajo de prueba estable no utiliza necesariamente las mismas instrucciones, lo que hace hincapié en el subsistema de memoria, lo que sea. Deja de hacer overclocking. Si desea que la gente crea que el problema no es el overclocking, hágalo cuando no esté haciendo overclocking para que pueda obtener un informe de error limpio. Esto hará una gran diferencia en la cantidad de esfuerzo que otras personas invertirán para resolver este problema. Tener un software libre de errores es un motivo de orgullo, pero los informes de personas con configuraciones de hardware particularmente cuestionables son frustrantes sumideros de tiempo que probablemente no implican ningún error real.

El segundo es obtener los datos de Uy, que como has notado no van a ninguno de los lugares que has mencionado. Si el bloqueo solo ocurre mientras se ejecuta X11, creo que la consola local está bastante apagada (de todos modos es un problema), por lo que debe hacerlo a través de una consola serie, a través de la red o guardando en el disco local (que es más complicado que puede sonar porque no desea que un núcleo no confiable corrompa su sistema de archivos). Aquí hay algunas maneras de hacer esto:

• use netdump para guardar en un servidor a través de la red. No he hecho esto en años, por lo que no estoy seguro de que este software siga funcionando y funcione con núcleos modernos, pero es lo suficientemente fácil como para que valga la pena intentarlo.
• arrancar usando una consola en serie ; necesitará un puerto serie gratuito en ambas máquinas (ya sea uno de la vieja escuela o un adaptador serie USB) y un cable de módem nulo; configuraría la otra máquina para guardar la salida.
• kdump parece ser lo que usan los niños geniales hoy en día, y parece bastante flexible, aunque no sería mi preferencia porque parece complejo de configurar. En resumen, implica iniciar un kernel diferente que puede hacer cualquier cosa e inspeccionar el contenido de la memoria del kernel anterior, pero esencialmente tiene que construir todo el proceso y no veo muchas opciones enlatadas. Actualización: hay algunas buenas cosas de distribución, en realidad; en Ubuntu, linux-crashdump

Una vez que obtenga la información de depuración, hay una herramienta llamada ksymoops que puede usar para convertir las direcciones en nombres de símbolos y comenzar a tener una idea de cómo se bloqueó su núcleo. Y si el volcado simbolizado no significa nada para usted, al menos esto es algo útil para informar aquí o tal vez en la lista de correo / rastreador de errores de su distribución de Linux.

Desde crashsu crashdump, puede intentar escribir logy btobtener un poco más de información (cosas registradas durante el pánico y un seguimiento de la pila). Sin embargo, Fatal Machine checkparece que viene de aquí . Al descremar el código, su procesador ha informado una excepción de comprobación de máquina , un problema de hardware. Nuevamente, mi primera apuesta se debería al overclocking. Parece que podría haber un mensaje más específico en la logsalida que podría brindarle más información.

También a partir de ese código, parece que si arrancas con el mce=3parámetro del kernel, dejará de fallar ... pero realmente no recomendaría esto, excepto como un paso de diagnóstico. Si el kernel de Linux cree que vale la pena colapsar este error, probablemente sea correcto.

a) Verifique si los mensajes del núcleo están siendo registrados en un archivo por rsyslog daemon

vi /etc/rsyslog.conf

Y agregue lo siguiente

kern.*                 /var/log/kernel.log

Reiniciar el rsyslogservicio.

/etc/initd.d/rsyslog restart

b) Tome nota de los módulos cargados

`lsmod >/your/home/dir`

c) Como el pánico no es reproducible, espere a que ocurra

d) Una vez que se ha producido el pánico, inicie el sistema con un CD en vivo o de emergencia.

e) Montar los sistemas de archivos (normalmente / será suficiente si / var y / home no son sistemas de archivos independientes) del sistema afectado ( pvs, vgs, lvscomandos deben ejecutarse si está utilizando LVM en el sistema afectado para que aparezca el LV) mount -t ext4 /dev/sdXN /mnt

f) Vaya al /mnt/var/log/directorio y verifique el kernel.logarchivo. Esto debería darle suficiente información para determinar si el pánico está sucediendo para un módulo en particular o algo más.

¿Su procesador está overclockeado? Tuve este mismo problema hoy cuando jugaba con el multiplicador en el menú de over-clock de mi BIOS; varios multiplicadores alrededor de 20x causarían que esto suceda. Lo reduje a 18.5x (3.7GHz) y el problema desapareció; Creo que fue un problema de placa base / energía.

Definitivamente un problema de procesador, observe las líneas que dicen: TSC 539b174adad ADDR 3fe98d264ebd MISC 1 [1561.519950] [Error de hardware]: PROCESADOR 0: 206a7 TIEMPO 1357862746 SOCKET 0 APIC 1 microcódigo 28. El procesador 0 es lo que el núcleo usó para procesar el bloqueo (es importante en los sistemas de varias CPU) y el zócalo 0 es el procesador infractor (aunque supongo que solo tiene 1). O es malo o, como notó, estar overclockeado causa fallas. Sé que dijiste que lo pasaste por prime95, pero como no tengo más información sobre la antigüedad del sistema, estoy agarrando algunas pajitas, cómo se ve tu pasta térmica, y ¿has verificado para asegurarte de que tu LGA (bajo el CPU) se ve bien? Estoy pensando que tal vez pines doblados o algo de pasta debajo de la LGA. De nuevo, solo causa raíz aquí.

Si eso no soluciona el problema, hay un pequeño truco que puede hacer para usar su SMBIOS para encontrar exactamente dónde llega el pánico, otra línea (TSC 539b174de9d ADDR 3fe98d264ebd MISC 1) son básicamente datos de SMBIOS que pueden mostrar dónde ocurrió el accidente. Cuando su máquina esté activa, en la línea de comando ejecutada, repita "TSC 539b174de9d ADDR 3fe98d264ebd MISC 1" | sudo mcelog --ascii --dmi para obtener la salida, esto le dirá que es un error de hardware e incluso en qué DIMM estaba procesando, esto puede apuntar a un DIMM o ruta de bus defectuoso, si la falla del DIMM salta con cada sin embargo, esto apunta a la CPU.

Teníamos un enrutador mikrotik instalado en una vieja plataforma. El ventilador dejó de girar y el procesador se calentó. El enrutador comienza a Kernel Panic de vez en cuando. Después de cambiar el ventilador de la CPU, todo salió bien.

Dado que está overclocking su máquina puede ser una posible causa.