Come interpretare i messaggi MCE?

Ho notato un sacco di errori che sono apparsi di recente /var/log/messagessu uno dei nostri server (sotto). Tuttavia, il client mce sembra essere meno sicuro dell'origine dell'errore rispetto alle voci decodificate in syslog. Esiste una sorta di chiave da utilizzare per interpretare l'output 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

Tutti gli errori sembrano essere collegati allo stesso banco di memoria:

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

Ho il demone mcelog in esecuzione e quando controllo le informazioni sugli errori, non sembra sapere da dove provengano gli errori. Solo a cui sono associati CPU0(in questa scatola abbiamo solo una CPU):

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

Non è affatto chiaro come devo interpretare queste informazioni. Da un lato, il client mce non indica canale o DIMM, ma il messaggio decodificato indica che si verificano errori su DIMM 8. dmesgsembra indicare che sono stati registrati solo 42 messaggi:

[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

Mi sembra di ricevere messaggi contrastanti, il che mi fa chiedere quali ipotesi fare in base alle informazioni riportate dalle varie fonti.

Informazioni varie:

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

Potresti provare a sostituire il modulo DIMM in questione (CPU 0, SOCKET 8) e vedere se i messaggi MCE continuano a essere generati.

Il pacchetto mcelog viene configurato con alcune soglie predefinite per vari eventi MCE che si verificano nel tempo. Controlla /etc/mcelog/mcelog.confper i dettagli. Per gli errori della pagina di memoria la soglia è di 10 eventi nell'arco di 24 ore. (Non sono sicuro da dove provenga questo numero, ma è probabilmente un punto di riferimento ragionevole). Il tuo post menziona 77 eventi correggibili in 24 ore su un sacco di pagine, quindi è abbastanza probabile che il DIMM abbia sviluppato un problema che potrebbe o meno trasformarsi in qualcosa di più serio.

Non sarei troppo dispiaciuto di ricevere informazioni incoerenti da fonti diverse. In generale, ho scoperto che qualsiasi cosa a livello di firmware è piuttosto specifica per la piattaforma (ovvero particolare per quel particolare modello hardware). La mia regola empirica per i problemi relativi al firmware è che gli strumenti del fornitore sono in genere i più precisi, ma i meno utilizzabili. Gli strumenti open source più generici sono più facili da utilizzare, ma potrebbero non fornire informazioni sufficienti per mostrare esattamente cosa sta succedendo.