Jak interpretować wiadomości MCE?

Zauważyłem kilka błędów, które niedawno pojawiły się /var/log/messagesna jednym z naszych serwerów (poniżej). Jednak klient mce wydaje się być mniej pewny źródła błędu niż zdekodowane wpisy w syslog. Czy jest jakiś klucz do interpretacji wyniku 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

Wszystkie błędy wydają się być powiązane z tym samym poziomem pamięci:

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

Mam uruchomionego demona mcelog, a kiedy sprawdzam informacje o błędach, wydaje się, że nie wie, skąd pochodzą błędy. Tyle tylko, że są one powiązane CPU0(w tym polu mamy tylko jeden procesor):

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

W ogóle nie jest jasne, jak mam interpretować te informacje. Z jednej strony klient mce nie wskazuje kanału ani DIMM, ale zdekodowany komunikat wskazuje, że błędy występują w DIMM 8. dmesgWydaje się, że rejestrowane są tylko 42 wiadomości:

[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

Wydaje mi się, że otrzymuję mieszane wiadomości, co sprawia, że ​​zastanawiam się, jakie założenia przyjąć na podstawie informacji zgłoszonych z różnych źródeł.

Różne informacje:

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

Możesz spróbować wymienić odpowiedni moduł DIMM (CPU 0, GNIAZDO 8) i sprawdzić, czy komunikaty MCE są nadal generowane.

Pakiet mcelog jest skonfigurowany z pewnymi domyślnymi progami dla różnych zdarzeń MCE, które pojawiają się w czasie. Sprawdź /etc/mcelog/mcelog.confszczegóły. W przypadku błędów stron pamięci próg wynosi 10 zdarzeń w ciągu 24 godzin. (Nie jestem do końca pewien, skąd pochodzi ta liczba, ale prawdopodobnie jest to rozsądny punkt odniesienia). W twoim poście wymieniono 77 zdarzeń, które można poprawić w ciągu 24 godzin na całej grupie stron, więc jest całkiem prawdopodobne, że w module DIMM wystąpił problem, który może, ale nie musi, przerodzić się w coś poważniejszego.

Nie byłbym zbyt zły na otrzymywanie niespójnych informacji z różnych źródeł. Ogólnie stwierdziłem, że wszystko na poziomie oprogramowania układowego jest dość specyficzne dla platformy (tj. Szczególnie dla tego konkretnego modelu sprzętu). Moją ogólną zasadą w przypadku problemów związanych z oprogramowaniem układowym jest to, że narzędzia dostawcy są zwykle najdokładniejsze, ale najmniej użyteczne. Bardziej ogólne narzędzia open source są łatwiejsze w obsłudze, ale mogą nie zapewniać wystarczającej ilości informacji, aby dokładnie pokazać, co się dzieje.