Comment interpréter les messages MCE?

J'ai remarqué un tas d'erreurs qui sont apparues récemment /var/log/messagessur l'un de nos serveurs (ci-dessous). Cependant, le client mce semble être moins certain de la source d'erreur que les entrées décodées dans syslog. Y a-t-il une sorte de clé à utiliser pour interpréter la sortie 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

Toutes les erreurs semblent être liées à la même banque de mémoire:

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

J'ai le démon mcelog en cours d'exécution et lorsque je vérifie les informations d'erreur, il ne semble pas savoir d'où viennent les erreurs. Seulement qu'ils sont associés CPU0(nous n'avons qu'un seul CPU dans cette case):

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

On ne sait pas du tout comment je dois interpréter ces informations. D'une part, le client mce n'indique pas le canal ou le module DIMM, mais le message décodé indique que les erreurs se produisent sur le module DIMM 8. dmesgsemble indiquer que seulement 42 messages ont été enregistrés:

[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

Il semble que je reçois des messages mitigés, ce qui me fait me demander quelles hypothèses faire sur la base des informations rapportées par les différentes sources.

Informations diverses:

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

Vous voudrez peut-être essayer de remplacer la barrette DIMM en question (CPU 0, SOCKET 8) et voir si les messages MCE continuent d'être générés.

Le package mcelog est configuré avec certains seuils par défaut pour divers événements MCE qui se produisent au fil du temps. Consultez /etc/mcelog/mcelog.confpour plus de détails. Pour les erreurs de page mémoire, le seuil est de 10 événements sur 24 heures. (Je ne sais pas vraiment d'où vient ce chiffre mais c'est probablement un point de référence raisonnable). Votre message mentionne 77 événements corrigeables sur 24 heures sur un tas de pages, il est donc très probable que le module DIMM ait développé un problème qui peut ou non se transformer en quelque chose de plus grave.

Je ne serais pas trop contrarié de recevoir des informations incohérentes de différentes sources. En général, j'ai trouvé que tout ce qui est au niveau du firmware est assez spécifique à la plate-forme (c'est-à-dire particulier à ce modèle matériel particulier). Ma règle générale pour les problèmes liés au firmware est que les outils du fournisseur sont généralement les plus précis, mais les moins utilisables. Les outils open source plus génériques sont plus faciles à utiliser, mais peuvent ne pas fournir suffisamment d'informations pour montrer exactement ce qui se passe.