¿Cómo interpreto los mensajes MCE?

Noté un montón de errores que aparecieron recientemente en /var/log/messagesuno de nuestros servidores (a continuación). Sin embargo, el cliente mce parece estar menos seguro del origen del error que las entradas decodificadas en syslog. ¿Hay algún tipo de clave para usar para interpretar la salida MCE?

Nov 12 04:19:19 areion kernel: [14698753.176035] Machine check events logged
Nov 12 04:19:19 areion mcelog: HARDWARE ERROR. This is *NOT* a software problem!
Nov 12 04:19:19 areion mcelog: Please contact your hardware vendor
Nov 12 04:19:19 areion mcelog: MCE 0
Nov 12 04:19:19 areion mcelog: CPU 0 BANK 8
Nov 12 04:19:19 areion mcelog: MISC 640738dd0009159c ADDR 96236c6c0
Nov 12 04:19:19 areion mcelog: TIME 1352711959 Mon Nov 12 04:19:19 2012
Nov 12 04:19:19 areion mcelog: MCG status:
Nov 12 04:19:19 areion mcelog: MCi status:
Nov 12 04:19:19 areion mcelog: MCi_MISC register valid
Nov 12 04:19:19 areion mcelog: MCi_ADDR register valid
Nov 12 04:19:19 areion mcelog: MCA: MEMORY CONTROLLER RD_CHANNELunspecified_ERR
Nov 12 04:19:19 areion mcelog: Transaction: Memory read error
Nov 12 04:19:19 areion mcelog: STATUS 8c0000400001009f MCGSTATUS 0
Nov 12 04:19:19 areion mcelog: MCGCAP 1c09 APICID 20 SOCKETID 1
Nov 12 04:19:19 areion mcelog: CPUID Vendor Intel Family 6 Model 44

Todos los errores parecen estar conectados con el mismo banco de memoria:

areion:~# awk -F'mcelog:' '/mcelog:.*BANK/{ print $2; }' < /var/log/messages |uniq
 CPU 0 BANK 8 

Tengo el demonio mcelog ejecutándose, y cuando busco información de error, no parece saber de dónde provienen los errores. Solo que están asociados CPU0(solo tenemos una CPU en este cuadro):

Memory errors
SOCKET 1 CHANNEL any DIMM any
corrected memory errors:
        77 total
        77 in 24h
uncorrected memory errors:
        0 total
        0 in 24h
Per page corrected memory statistics:
359ffc000: total 2 2 in 24h online

3b93cc000: total 2 2 in 24h online

3ce45c000: total 2 2 in 24h online

96236c000: total 20 20 in 24h online triggered

96545c000: total 9 9 in 24h online

96a82c000: total 9 9 in 24h online

96a8ec000: total 1 1 in 24h online

96fb6c000: total 15 15 in 24h online triggered

9c2edc000: total 15 15 in 24h online triggered

9c5eac000: total 1 1 in 24h online

9c6a1c000: total 1 1 in 24h online

No está nada claro cómo interpretar esta información. Por un lado, el cliente mce no indica canal o DIMM, pero el mensaje decodificado indica que se producen errores en DIMM 8. dmesgParece indicar que solo se registraron 42 mensajes:

[14698753.176035] Machine check events logged
[14698753.629174] Machine check events logged
[14698815.338595] __ratelimit: 38 callbacks suppressed
[14698815.338628] Machine check events logged
[14698816.020797] Machine check events logged

Parece que recibo mensajes mixtos, lo que me hace preguntarme qué suposiciones hacer en base a la información reportada por las diversas fuentes.

Información variada:

areion:~# grep 'model name' /proc/cpuinfo |uniq
model name      : Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz

areion:~# apt-cache policy mcelog |grep Installed
  Installed: 1.0~pre3-3

areion:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 6.0.6 (squeeze)
Release:        6.0.6
Codename:       squeeze

Puede intentar reemplazar el DIMM en cuestión (CPU 0, SOCKET 8) y ver si se siguen generando los mensajes MCE.

El paquete mcelog viene configurado con algunos umbrales predeterminados para varios eventos MCE que ocurren con el tiempo. Echa un vistazo /etc/mcelog/mcelog.confpara más detalles. Para errores de página de memoria, el umbral es de 10 eventos durante 24 horas. (No estoy realmente seguro de dónde proviene este número, pero probablemente sea un punto de referencia razonable). Su publicación menciona 77 eventos corregibles durante 24 horas en un montón de páginas, por lo que es muy probable que el DIMM haya desarrollado un problema que puede o no convertirse en algo más grave.

No me molestaría demasiado recibir información inconsistente de diferentes fuentes. En general, he descubierto que cualquier cosa a nivel de firmware es bastante específica de la plataforma (es decir, particular para ese modelo de hardware en particular). Mi regla general para los problemas relacionados con el firmware es que las herramientas del proveedor suelen ser las más precisas, pero las menos utilizables. Es más fácil trabajar con las herramientas de código abierto más genéricas, pero es posible que no proporcionen suficiente información para mostrar exactamente lo que está sucediendo.