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