Как я могу интерпретировать сообщения MCE?

Я заметил кучу ошибок, которые только недавно появились /var/log/messagesна одном из наших серверов (ниже). Однако клиент mce, похоже, менее уверен в источнике ошибок, чем декодированные записи в системном журнале. Есть какой-то ключ, чтобы использовать для интерпретации вывода 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

Кажется, все ошибки связаны с одним и тем же банком памяти:

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

У меня запущен демон mcelog, и когда я проверяю информацию об ошибках, он, похоже, не знает, откуда происходят ошибки. Только то, с чем они связаны CPU0(у нас только один процессор в этом поле):

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

Не совсем понятно, как мне интерпретировать эту информацию. С одной стороны, клиент mce не указывает канал или DIMM, но декодированное сообщение указывает, что ошибки происходят в DIMM 8. dmesgПохоже, что было зарегистрировано только 42 сообщения:

[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

Кажется, я получаю смешанные сообщения, что заставляет меня задуматься о том, какие предположения делать на основе информации, сообщаемой из различных источников.

Дополнительная информация:

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

Вы можете попробовать заменить соответствующий модуль DIMM (CPU 0, SOCKET 8) и посмотреть, продолжают ли генерироваться сообщения MCE.

Пакет mcelog поставляется с некоторыми пороговыми значениями по умолчанию для различных событий MCE, происходящих с течением времени. Проверьте /etc/mcelog/mcelog.confдля деталей. Для ошибок страницы памяти порог составляет 10 событий за 24 часа. (Я не совсем уверен, откуда это число, но это, вероятно, разумный ориентир). В вашем посте упоминается 77 исправляемых событий за 24 часа на целой пачке страниц, поэтому вполне вероятно, что в DIMM возникла проблема, которая может превратиться или не превратиться в нечто более серьезное.

Я не был бы слишком расстроен получением противоречивой информации из разных источников. В общем, я обнаружил, что все на уровне прошивки довольно специфично для платформы (то есть, специфично для этой конкретной аппаратной модели). Мое эмпирическое правило для проблем, связанных с микропрограммным обеспечением, заключается в том, что инструменты поставщика обычно являются наиболее точными, но наименее пригодными для использования. С более общими инструментами с открытым исходным кодом легче работать, но они могут не предоставлять достаточно информации, чтобы точно показать, что происходит.