mcelog - mce-inject, mce-test

운영중인 RHEL 6.3 서버에서 커널(dmesg 로그)에서는 mce(corrected)가 감지가 되었는데 /var/log/mcelog에 로그가 찍히지 않는 현상이 발생을 하였다. 그래서 mcelog 데몬이 로그를 제대로 찍는지 확인을 위해 software 적으로 mce corrected 이벤트를 발생시켜서 로깅 상태를 확인하는 방법을 사용해 봤다.

- 테스트 서버

RHEL 6.3(2.6.32-279.el6.x86_64), HP DL380 G8

CentOS 6.7(2.6.32-573.el6.x86_64), Supermicro Server Mainboard, Intel Xeon E31220

CentOS 6.7(2.6.32-573.el6.x86_64), Intel Desktop Mainboard, Intel Celeron G1630

1. MCE 테스트

1) RHEL 6.x의 mce-inject 툴을 포함한 ras-utils(옵셔널 패키지)를 설치한다.
(mcelogd 패키지 설치 및 mcelogd 데몬도 구동 중이어야 함)

# cd /root

# yum localinstall ras-utils-6.1-1.el6.x86_64.rpm

2) mce-test 패키지(오픈소스)를 설치 한다.
(mce-test를 설치하지 않고 아래에 있는 샘플코드를 이용해도 된다.)

mce-test에 mce 테스트를 위한 샘플 코드들이 포함되어 있다.

# yum install -y git.x86_64

# git clone https://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git

# cd /root/mce-test/cases

# make
(gcc 가 설치되어 있어야 함)

3) mce-inject 커널 모듈을 올린다.

# modprobe mce-inject
(테스트 후 mce_inject 모듈을 내리려 하자 busy 하다면서 내려가지 않음. 재부팅하면 내려간다.)

4) mce 로그 확인

# tail -f /vat/log/mcelog
(다른 쉘에서 mcelog를 확인)

5) 이벤트 발생

# mce-inject /root/mce-test/cases/coverage/soft-inj/non-panic/data/corrected
(수행 후 약 1분 ~ 3분 후에 MCE 로그가 찍히는게 확인이 된다.)

* 아래는 corrected 샘플코드 내용이다.
(mce-test를 설치하지 않고 아래와 같은 샘플코드를 vi로 작성하고 수행해도 된다.)

# cat ./cases/coverage/soft-inj/non-panic/data/corrected
#
# log corrected machine checks
CPU 0 BANK 1
STATUS CORRECTED
ADDR 0xabcd
HOLD
CPU 1 BANK 0
#
CPU 1 BANK 2
STATUS CORRECTED
MISC 0xabcd
ADDR 0x1234
HOLD
CPU 0 BANK 0

* 만약 다시한번 mce 로그가 찍히게 되면 기존 /var/log/mcelog의 내용은 없어지고 새로운 로그가 찍힌다고 한다. 하지만 테스트 과정에서는 시간차를 두고 로그를 다시 찍어도 mcelog 가 사라지지 않고 쌓였으며, 재부팅 후에도 사라지지 않았다.

* ~~mcelog.org document와는 다르게 ACPI: APEI가 BIOS에서 활성화 되지 않은 시스템에서도 mce-inject 테스트를 통해 로그가 찍혔다.~~ Desktop Mainborad + PC CPU(Intel Celeron G1630) 시스템에서도 로그가 찍히는게 가능했다.

* VMWare ESXi 5.5 상의 vm(RHEL 6.3_2.6.32-279.el6.x86_64) 에서 테스트를 하면 아래와 같이 수행 결과가 나오고 /var/log/mcelog가 찍히지 않는다.
# mce-inject ./cases/coverage/soft-inj/non-panic/data/corrected
./cases/coverage/soft-inj/non-panic/data/corrected:5: larger machine check bank 1 than supported on this cpu (0)

6) 로그 확인

- mce-inject 수행 후 아래와 같이 로그가 찍히는게 확인이 된다.

# date ; mce-inject /root/mce-test/cases/coverage/soft-inj/non-panic/data/corrected
2016. 09. 13. (화) 10:06:12 KST
--> 이벤트 발생 명령을 10:06:12에 수행

# tail -f -n 1 /var/log/messages
# Sep 13 10:07:32 ingPro kernel: [Hardware Error]: Machine check events logged
--> 커널이 약 1분 20초 후 감지(감지 시각은 수행 시마다 달랐다.)

# dmesg | tail -n 1
[Hardware Error]: Machine check events logged

- mcelog를 확인해 보면 실제 이벤트가 발생했던 시각을 표기하는게 확인된다.
# cat /var/log/mcelog
Hardware event. This is not a software error.
MCE 0
CPU 0 BANK 1
ADDR abcd
TIME 1473728772 Tue Sep 13 10:06:12 2016
MCG status:
MCi status:
Corrected error
Error enabled
MCi_ADDR register valid
MCA: No Error
STATUS 9400000000000000 MCGSTATUS 0
MCGCAP c07 APICID 0 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58
Hardware event. This is not a software error.
MCE 1
CPU 1 BANK 2
MISC abcd ADDR 1234
TIME 1473728772 Tue Sep 13 10:06:12 2016
MCG status:
MCi status:
Corrected error
Error enabled
MCi_MISC register valid
MCi_ADDR register valid
MCA: No Error
STATUS 9c00000000000000 MCGSTATUS 0
MCGCAP c07 APICID 2 SOCKETID 0
CPUID Vendor Intel Family 6 Model 58

- mcelog는 커널이 감지한 10:07:32에 /var/log/mcelog 에 찍히게 된다.
# ls -la --full-time /var/log/mcelog
-rw-r--r-- 1 root root 664 2016-09-13 10:07:32.129003732 +0900 /var/log/mcelog

* 참고로 실제로 서버에 mcelog가 발생했을 때 OS상에 찍힌 mcelog 의 'BANK 숫자' 가 나타내는 것은 실제 물리적인 메모리의 DIMM 위치가 아니다. 즉, BANK ≠ DIMM . 실제 물리적인 DIMM의 위치를 찾기 위해서는 우선 CPU의 Socket 위치에 속한 Channel(DIMM의 그룹)을 우선 찾는다. - 여기까지는 어렵지 않다. 하지만 채널까지 찾았다 해도 메모리(RAM)가 어느 DIMM에 속하는지는 CPU 세대별 Intel(or AMD) Architecture를 참고하여 정확한 위치를 찾아야 하는데 쉽지 않은 일이다. 만약 Channel까지 찾았다면 Channel(보통 2~3개의 DIMM으로 이루어짐)에 속한 DIMM에 꽂아진 메모리를 모두 교체하고 MCE 발생 여부를 지켜본다. 그래도 MCE 로그가 찍힌다면 Mainboard의 BUS의 문제일 수 있다.

* OS에서 Corrected MCE 로그가 감지되는 횟수가 짧은 시간을 두고 자주 발생되는 것은 문제가 될 수 있지만 하루를 두고 1~2개 정도 발생하는 것은 문제가 되지 않을 거라 판단된다. - 개인적인 사견 임.
HP DL 시리즈 서버의 경우 Corrected 에러는 CPU의 MCR의 기록이 100 카운트가 넘어가기 전까지는 IML에 로그를 찍지 않는다고 한다. Corrected 이벤트 자체가 에러가 있었지만 ECC 등의 에러 보정 기능 등을 통해 정상적인 범위안으로 이벤트가 처리 되었다는 것을 뜻하기 때문이다.
하지만 Uncorrected 이벤트(에러보정 실패)가 발생하면 바로 하드웨어 벤더의 도움을 받아 조취를 취해야 한다.

* MCE 의 원인은 여러가지가 있는데 주로 아래 순으로 원인이 될 것이다.
메모리(70%) > 마더보드(20%) > CPU(5%) > 기타 하드웨어(높은온도, 파워서플라이 문제 등) (5%)
- 개인적인 사견 임.

2. PFA 테스트

mce-test의 pfa(Predictive Failure Analysis_예측 오류 분석) 수행을 위한 전제 조건으로 BIOS의 ACPI/EINJ 옵션 활성화와 아래와 같은 커널 옵션이 활성화 되어 있어야 한다고 한다.

1) 전제 조건 :
- To use EINJ, make sure the following are options enabled in your kernel
configuration:

CONFIG_DEBUG_FS
CONFIG_ACPI_APEI
CONFIG_ACPI_APEI_EINJ

- 또한 아래와 같이 kernel debug가 마운트 되어 있어야 한다고 함.
# mount | grep debug
none on /sys/kernel/debug type debugfs (rw)

만약 mount가 안되어 있다면 아래와 같이 mount 수행

# mount -t debugfs nodev /sys/kernel/debug

2) 테스트 과정

아래는 pfa(Predictive Failure Analysis_예측 오류 분석) 테스트 과정이다.

# cd /root/mce-test/cases/function/pfa

# ./load.sh ./run_pfa.sh ./busy
no BIOS extension support for APEI on this platform
module einj isn't supported?
(위과 같은 메시지가 발생 시 BIOS 또는 커널에서 APEI를 위한 설정이 활성화 되어 있지 않아서 발생)

./runtest.sh 를 실행하면 아래와 같은 문구가 출력되며 테스트를 출력한다.

***************************************************************************
Pay attention:

This test is for memory PFA support test. PFA test will conflict with EDAC.
Before the test EDAC related drivers must be removed from the kernel (Not
built-in or rmmod). Moreover, PFA support need correct BIOS setting and
mcelog setting. If you are not familiar with it, please skip this test.

NOTE: CPU sleep may decrease the test efficiency. To avoid this situation,
one can run *load.sh" by hand before the formal test!
***************************************************************************

1) 테스트 조건을 위해 edac 커널 모듈을 내리기
2) mcelog 테스트를 위한 BIOS 세팅
3) OS 단의 mcelog 를 위한 환경 구성
4) CPU를 Busy 하게 만든다.

- EDAC 커널 모듈을 확인한다.
# lsmod | grep -i edac
edac?
# rmmod edac?

- CPU를 busy하게 만듬
# ./load.sh ./busy

- 테스트 진행
# ./runtest.sh

# cd /root/mce-test/tools/page-types
gcc -o page-types page-types.c
cp page-types /usr/bin/

* 테스트 서버들 모두 pfa 테스트는 조건이 맞지 않아 수행되지 못 했다.

아래는 HP DL380 G8(위그림), DL560 G8 에 대한 DIMM 정보 이미지이다.

3. mcelog 관련 참조

1) MCE와 관련된 용어 설명
http://www.mcelog.org/glossary.html

2) APEI Error INJection (mce-inject 테스트를 위한 조건 등을 설명)
https://www.kernel.org/doc/Documentation/acpi/apei/einj.txt

3) mce-inject 샘플 코드
http://mcelog.org/logfile.html

4) mce-inject 테스트 방법 설명
http://mcelog.org/testing.html

5) PFA(Predictive Failure Analysis_예측 오류 분석) 테스트 방법 설명
https://kernel.googlesource.com/pub/scm/utils/cpu/mce/mcelog/+/v131/tests/pfa/PFA_test_howto

6) mce-test git-hub
https://github.com/andikleen/mce-test/blob/master/doc/howto.txt

7) How to Use Hardware Fault Management in Oracle Linux
http://www.oracle.com/technetwork/articles/servers-storage-admin/fault-management-linux-2005816.html

8) Setting up mcelog to work with systemd
https://eatpeppershothot.blogspot.kr/2015/06/setting-up-mcelog-to-work-with-systemd.html

9) Predicting server hardware failure with mcelog
https://barry.wordpress.com/2009/05/12/predicting-server-hardware-failure-with-mcelog/

10) MCE error log
http://www.gossamer-threads.com/lists/linux/kernel/1015942

11) A Tour Beyond BIOS Implementing the ACPI Error Interface with the Unified Extensible Firmware Interface
https://www.researchgate.net/publication/236201765_A_Tour_Beyond_BIOS_Implementing_the_ACPI_Error_Interface_with_the_Unified_Extensible_Firmware_Interface

12) APEI: Can not request iomem region for GARs
http://linux-kernel.vger.kernel.narkive.com/ZMR4QcLP/apei-can-not-request-iomem-region-for-gars

13) EDAC
https://wiki.kldp.org/wiki.php/EDAC

mcelog - mce-inject, mce-test

mapoo's blog

mcelog - mce-inject, mce-test

1. MCE 테스트

2. PFA 테스트

3. mcelog 관련 참조

답글 남기기 응답 취소