컴맹이라 분석은 택도 없고 허접한 내용입니다만, 그냥 기록 겸 겸사겸사 올립니다. 예전 같으면 아무도 찾지 않는 블로그에 올리고 땡 쳤을텐데... 이 쪽이 더 낫다는 것에는 뭐 일련의 고민이 필요없을 겁니다.

 

아래 내용 일부분은 외부 업체 엔지니어분에게도 공유가 되었거나 될 내용이 있는 것이라 걱정은 됩니다만.. 어차피 제 개인정보의 상당수는 공공정보처럼 취급되는데다 아는체 하시면 대인님께서 친히 처단해주시리라 믿습니다. 암튼..

 

ECC 메모리는 주로 서버나 워크스테이션 타겟의 CPU (e.g. Intel Xeon, AMD Epic, ThreadRipper)에서 사용됩니다. 대부분의 데스크톱 타겟의 CPU를 사용하시는 분들께는 해당사항이 없습니다. 한편, 이와 관련해서 현업에 계신분들이 보기에는 다소 가소로운 내용일 듯 하네요. 저에게는 주 업무도 아니고 그냥 취미같은(?) 일이라... 참 어정쩡한 타겟의 컨텐츠입니다. 다소 시무룩 해졌지만 힘을 내서 기록하겠습니다.

 

문제의 환경은 다음과 같습니다:

 - 메인보드: ASUS WS-C621E-SAGE

 - CPU - Intel Xeon Silver 4114 @ 2.20Ghz

 - 메모리: DDR4, 삼성 시금치 Registered-DIMM, 32GB * 8 ( 상세 스펙: https://www.samsung.com/semiconductor/dram/module/M393A4K40CB1-CRC/ )

 - OS: Ubuntu 18.04LTS, Kernel 4.15(Vanilla), 또는 5.0 (HWE)

 

ECC 오류가 떴을 때 증상이나 대처 방법은 RAM 교체 - 메인보드 점검 - CPU 점검 ... 순으로 가야하겠지요? 이 게시물에서는 어떤 놈이 문제가 있는 놈인지를 가려내는 일만 합니다. 최종적인 진단과 수리는 전문가에게 맡깁시다.

 

암튼, 이런 ECC를 지원하는 메모리를 사용하면, 하드웨어에 문제가 발생했을 때 아래와 같은 커널 로그가 뜹니다.

 

 

사실 이거라도 떠 주는게 어디냐 싶어서 ECC 메모리를 선호합니다. 그냥 재부팅되거나 셧다운되고 커널 로그에는 하나도 안남고 그러면 어디서부터 건드려야할지 막막하더라구요.

 

위 정보로 알 수 있는 것을 대충 볼까요?

 

(1) 하드웨어에 의해 오류가 수정되었고, 추가적인 행동이 필요하지 않다..고 나와 있습니다. ECC를 통해서 정정이 되었다는 소리지요. 하지만, 해당 하드웨어는 재현이 까다로운 간헐적 재부팅 또는 셧다운을 겪고 있는 서버라 뭔가 조치를 취해야 했습니다.

(2) 문제의 타입은 메모리 오류라고 합니다. 정확하게는 읽기 오류지요.

(3) 문제가 생긴 부분은 0x003fc3327680로 주소가 매핑되어 있습니다.

(4) 그리고 Memory Controller 3(EDAC MC3)에 붙어 있는 DIMM이라고 보면 됩니다. 거기서도 2번째 채널이라는 거네요. (CPU_SrcID#1_MC#1_Chan#2_DIMM#0 -> CPU Src ID = 1, MC = 1, Chan = 2, DIMM = 0)

 

그럼에도 불구하고 위의 정보로는 정확히 어떤 녀석인지 잘 모릅니다. 세상에... MC3이 관장하는 DIMM에 2번째 채널이라니... 이게 뭐야 살려주세요 소리가 자동으로 나옵니다.

 

문제는 사진의 가장 아랫줄과 같이, DIMM 위치(DIMM location: not present.)가 뜨지 않는다는데 있습니다. 저렇게 위치가 직접적으로 나오지 않는 것은, 더 최신 커널(5.0.x)을 써도 마찬가지입니다.

물리 어드레스를 보고 계산해서 어림하는 방법도 해볼법 하겠으나.. 저는 그렇게 산수를 잘 하지 못합니다.

 

그럼 어떻게 해야 할까요?

 

메모리 장치와 주소를 매핑하는 정보는 DMI(데스크톱 관리 인터페이스; Desktop management interface, 또는 SMBIOS/시스템 관리 BIOS라고 부르는) 테이블에 기록되어 있을 것입니다.

 

이 DMI 표의 내용 중에, DMI Type 20 (Memory Device Mapped Address)을 조회하면, 각 DIMM 별로 지정된 메모리 영역을 볼 수 있습니다. 그런 다음, 0x3fc3327680이 걸쳐져 있는 순번을 찾아, DIMM_A 슬롯 부터 순서대로 개수를 세면 대략의 위치를 알 수 있습니다. 보통 메모리 하드웨어 모듈을 보여주는 DMI Type 17(Memory Device)과 번갈아가면서 나오기 때문에, 어떤 모듈인지 한방에 볼 수 있습니다.

 

참고로 리눅스에서는 dmidecode라는 유틸리티를 사용하여 이 내용을 볼 수 있습니다.

 

이제 어떤 녀석인지 밝혀낼 시간입니다.

 

 

... 하지만 어림도 없습니다. 

 

사용된 메인보드의 최신 바이오스는, SMBIOS 버전 3.2.1을 사용하고 있지만, 최신 dmidecode는 SMBIOS 3.2.0 표준까지만 지원합니다. 이게 이유인지는 모르겠으나, DMI Type 20이 조회되지 않네요. 게다가 Ubuntu 18.04에서 제공하는 기본 패키지의 dmidecode는 3.1 버전입니다. 택도 없죠. 그래서 혹시나 해서 dmidecode 3.2 버전을 빌드해서 테스트했죠. 하지만, 위에서 보이는대로, 현재 3.2버전은 SMBIOS 3.2.0 스펙까지만 지원합니다.

 

이제 다른 방법을 써야겠네요.

 

ECC 메모리를 사용할 수 있는 하드웨어라면, 대개는 RASdaemon( https://pagure.io/rasdaemon )을 구동시킬 수 있습니다. 즉각적인 오류를 확인하는데는 edac-utils를 사용할 수도 있겠지요. 하지만 재부팅 등으로 고통받고 있다면, 기록을 끝까지 남겨서 보기 위해 rasdaemon을 사용해야 합니다. 옛날(그래봤자 2018년 이전)에는 mcelog라는 프로그램을 썼겠지만, 커널 4.13 부터는 구형 MCE 모듈(/dev/mcelog)이 deprecated 되었기 때문에, 최신의 리눅스 배포판에서는 rasdaemon 사용을 권장합니다. (한편, 이 당시에는 edac-utils도 무슨 이유에선지 오류가 똑바로 안보이더라구요. 쩝.)

 

ubuntu에서는 $ sudo apt install rasdaemon

으로,

RHEL/CentOS에서는 # yum install rasdaemon을 쓰면 설치가 됩니다. 설치된 rasdaemon은 서비스로 띄워놓으면 OK.

 

이제 오류가 다시 발생하기를 기다립니다. 오류가 금방 기록되면 다행이지만, 그렇지 않는 경우가 많으니 계속 구동하면서 잡아내면 됩니다. 만약, 더 빨리 해야 한다면 대강 주소를 알고 있으니 mmap()하면 되겠지만, 특정 주소에 대한 직접 억세스는 기본적으로 막고 있으니 이걸 풀려면 커널 파라미터도 바꿔야하고... 재부팅도 해야 하고... 귀찮습니다. 그냥 내버려둡니다. 어차피 제가 쓰는거 아니거든요. (저런...)

 

암튼 오류를 확인하기 위해서는, 다음의 명령어를 사용합니다:

 

# ras-mc-ctl --summary

 

 

이건 글을 올리면서 오늘찍은거라, 오류가 2개로 나타납니다. 사실 같은 놈인데, 슬롯 매핑 오류가 있어서 이를 바꿔서 기록이 더 남은 겁니다. 기존에는 Chan#2 -> Chan#0으로 옮긴거죠.

 

세부 오류를 보려면 다음 명령어를 사용합니다:

# ras-mc-ctl --errors

 

 

워낙 길어서 위의 3줄만 찍습니다. 암튼, 이렇게 재부팅 여부에 상관없이 문제를 기록, 확인할 수 있습니다.

 

하지만 정작 이 게시물의 포인트인 "어떤 DIMM 슬롯에 꼽혀있는 RAM이 문제인가?"는 풀 수 없죠. 여전히 우리가 알 수 있는 것은 커널 로그에서도 확인할 수 있는 "CPU_SrcID#1_MC#1_Chan#2_DIMM#0" 뿐이니깐요.

 

이건 다음의 명령어를 사용하여 확인하면 됩니다:

# ras-mc-ctl --layout

 

 

 

편의를 위해서 제가 빨간색으로 표기했습니다.

 

이 명령어로, 각각의 메모리 컨트롤러/채널별로 할당되어 있는 녀석을 찾으면 됩니다. CPU SrcID, MC는 필요 없고.. 맨 앞의 MC3과 Channel 숫자만 보면 됩니다. 에? 여전히 DIMM이 어떤놈인지는 모른다구요? 그럼 그것도 봐야지요.

 

 

위의 그림과 같이, --mainboard 옵션을 사용하면 DMI에서 메인보드 정보를 가져와서 보여줍니다. DIMM 정보도 알려주겠지요. 운이 좋아서 dimm label 정보가 다 박혀있다면 --print-labels 옵션에서 보여주겠지만, 개략적인 것은 --guess-labels 옵션을 사용해서 볼 수 있습니다. 사실 DMI decode 타입 17번으로 나오는 순서대로 봐도 됩니다만.

 

순서대로라고 한다면, 다음과 같이 매핑되겠지요.

 

MC 0 - DIMM A, B, C

MC 1 - DIMM D, E, F ---> 여기는 CPU 0번

MC 2 - DIMM G, H, J

MC 3 - DIMM K, L, M ---> 여기가 CPU 1번.

 

근데 여기서 "어...?" 다 싶은게, 왜 DIMM_M1에 메모리가 꽂혔을까 싶습니다. 메인보드 매뉴얼을 가져와서 찾아봅니다. 설명을 위해, ASUS 홈페이지에서 가져온 매뉴얼 ( https://www.asus.com/kr/Commercial-Servers-Workstations/WS-C621E-SAGE/HelpDesk_Manual/ ) 의 일부분을 인용합니다.

 

역시나, Single CPU configuration에서는 DIMM A,B,C,D,E,F 만을 사용합니다. 그럼 Dual CPU configuration을 볼까요?

 

대충 위에서 --layout으로 본 구성과 같습니다. A,B, D,E, G,H, 잘 꼽혀있고... 근데... K, L?

설명을 보니.. 음. K1에 있어야 할 놈이 M1에 있습니다. ... 뭐 조립자의 사소한 실수일겁니다.

 

정말 그러한지 마지막으로 확인합니다. 메인보드 레이아웃을 보니 문제의 녀석이 M1에 있을 듯 합니다.

 

 

 

만약, 메인보드 레이아웃을 얻지 못할 경우, 각 메모리의 시리얼 번호를 dmidecode로 얻을 수 있습니다. 거기서 DIMM_M1을 찾고, 거기에 적혀있는 시리얼 번호와 파트 번호를 얻어오면 됩니다.

이제 서버를 뜯어서 메모리 위치 오류부터 바로잡아 줍니다. 서버 사진은 생략합니다. 정말로 DIMM_M1 슬롯에 문제의 램이 박혀있었고, 이를 K1으로 옮겨줬습니다.

 

아무튼 다시 부팅 후, 테스트..

 

 

위치를 M1 -> K1으로 바꿔주고, 이에 따라 mc3의 channel2 대신 channel 0으로 잡힙니다. 오류도 다시 뜹니다.

 

오류는 여전히 있는 것으로 보아, 거의 메모리 오류로 봐도 무방할 듯 합니다. 메인보드나 CPU 불량의 의심은 좀 덜해도 되지 않을까 싶어요.

이제 서버의 내용물을 백업하고, 수리를 보내야 합니다. 아직 업체한테 연락은.. 백업하고 요청해야 합니다. 연말인데 엔지니어분도 귀찮으실텐데.. 뭐 암튼 진단이 맞길 바랍니다.

 

올해 들어온 녀석인데 속을 썩여서... 내년부터는 그냥 델이나 HPE같은 메이커(...) 서버를 사고 치울까 합니다. 4U 서버를 들었다 올려도 흐닷닷닷 기합을 넣어가며 하는게 예전같지 않네요. 괜히 돈 아낀다고 ... 몸 버려가고 있습니다. 회사에 이렇게 헌신하면 헌신짝되는데 말입니다.

 

 

음... 한편, 만약 기다리는 시간이 부족하다면, 문제를 어떻게 재현해야 할까요?

 

메모리 테스트를 해야 하는데.. 고전적인 memtest86+을 사용해도 되지만, 이건 재부팅이 필요하고, 현재 커널로 진입해서 테스트 하는 것이 아니니 rasdaemon에 기록되지도 않을 것입니다. 그럼 이를 해결할 수 있는 프로그램을 먼저 찾아야지요.

 

이를 위해 오늘 사용할 물건은 memtester ( http://pyropus.ca/software/memtester/ )입니다. 재부팅도 필요없고, ubuntu에서도 관리되는 패키지입니다. 안타깝게도 RHEL/CentOS 7에서는 보이지 않네요. IUS/epel 저장소 모두 다요. 이런 경우에는 다운로드 받아서 빌드해야겠습니다.

 

여유가 있는 메모리가 대략 250GB 정도 되니, root 권한에서, 다음과 같이 실행해서 230GB 정도를 쓰게 하면 저 부분이 다시 걸리겠지요.

 

 

ECC에 의해서 교정되는 읽기 오류기 때문에, 여기서 오류가 뜨지는 않을겁니다. 엄밀하게 이건 쓰기 오류를 찾는데 보통 사용하니깐요.

 

하지만, dmesg를 보면 오류가 뜨는 것을 확인할 수 있습니다.

 

 

{7}이라고 7번째 오류임을 보입니다. 그 자리를 읽을 때 마다 오류가 발생하니, 대충 맞다고 봐야 합니다.

 

잘 사용되지 않는 하드웨어가 필요하고, 메모리 오류가 흔한 것도 아니라 이 애매한 컨텐츠를 일단 여기서 마무리합니다. 리눅스는 이제 주류시장에 편입된지 10년이 훨씬 지났기 때문에 그래도 보실 분이 좀 있긴 하겠다.. 싶은게 좀 위안이 되네요.

 

암튼, 재미없는 글 봐주셔서 감사합니다.