CXL 디바이스 트러블슈팅 — RAS 이벤트·Poison List·Media Error 추적
#왜 별도 진단이 필요한가
Ch 8에서 링크 자체를 봤습니다. 링크가 정상이어도 디바이스 측에서 문제가 발생할 수 있습니다. DRAM ECC error, refresh failure, media wear 같은 디바이스 내부 이상은 링크 진단으로 안 보입니다.
CXL는 RAS 이벤트 채널과 poison list 메커니즘으로 디바이스 측 진단 정보를 호스트에 노출합니다.
#RAS 이벤트 등급
CXL Spec이 정의하는 4가지 등급:
| 등급 | 의미 | 호스트 대응 |
|---|---|---|
| Information | 정보성 (mailbox completion 등) | log만 |
| Warning | Correctable error | counter 모니터링 |
| Failure | Uncorrectable, 단일 영역 | poison list 격리, page offline |
| Fatal | 디바이스 오류 | 디바이스 reset 또는 교체 |
Linux 6.2+는 Failure 이상에서 자동 page offline + MCE 이벤트 트리거.
#CXL Mailbox로 상태 확인
mailbox 명령으로 디바이스 health 조회:
# 1. Health Info (Mailbox opcode 0x4400)$ cxl health -m mem0{ "memdev":"mem0", "health_status":"normal", "media_status":"normal", "ext_status":"normal", "life_used_percent":12, "temperature":42, "dirty_shutdown_count":3, "volatile_uncorrectable_errors":0, "persistent_uncorrectable_errors":0}
# 2. Event Records (opcode 0x4500)$ cxl monitor -m mem0[2026-06-18 09:10:23] Info: Mailbox cmd 0x4400 completed in 1.2ms[2026-06-18 09:11:45] Warning: Correctable ECC error at 0x80045000[2026-06-18 09:12:01] Failure: Media error at 0x80067800 — added to poison list#Poison List 추적
Poison List는 디바이스가 bad media를 기록하는 리스트입니다.
# Poison list 조회 (opcode 0x4800)$ cxl list -m mem0 -P{ "poison":[ { "address":"0x80012340", "length":64, "source":"injected" # 테스트 주입 }, { "address":"0x80015800", "length":64, "source":"internal" # 디바이스 자체 감지 }, { "address":"0x80067800", "length":4096, "source":"vendor" # 펌웨어 감지 } ]}
# Poison 클리어 (보통 권장 안 함)$ cxl clear-poison -m mem0 -a 0x80012340injected는 테스트용 주입, internal은 DRAM controller 자체 감지, vendor는 펌웨어 진단. source가 internal이 늘어남은 media wear 신호.
#Linux 통합 — sysfs
/sys/bus/cxl/devices/memX/에 poison·event 통합:
# Poison list$ ls /sys/bus/cxl/devices/mem0/poison/list inject clear
$ cat /sys/bus/cxl/devices/mem0/poison/list0x80012340 64 injected0x80015800 64 internal0x80067800 4096 vendor
# Events$ ls /sys/bus/cxl/devices/mem0/events/info warning failure fatal
$ cat /sys/bus/cxl/devices/mem0/events/failure | tail -10[2026-06-18 09:12:01] Media error at 0x80067800 (size=4096)#bpftrace로 이벤트 추적
CXL 이벤트 발생 빈도 모니터링:
# 모든 CXL 이벤트$ bpftrace -e ' tracepoint:cxl:cxl_aer_uncorrectable_error { @ue[str(args->kind)] = count(); } tracepoint:cxl:cxl_aer_correctable_error { @ce[str(args->kind)] = count(); } interval:s:60 { print(@ue); print(@ce); clear(@ue); clear(@ce); }'
# 출력 예@ue[mailbox_timeout]: 2@ce[ecc_error]: 145#Page Offline 자동화
Failure 이벤트 시 kernel이 자동 page offline:
# Failure event 발생 후$ cat /sys/devices/system/memory/auto_online_blocksoffline
# 영향 받은 page 확인$ cat /sys/devices/system/node/node2/memoryX/stateoffline
# offline pages 통계$ cat /proc/meminfo | grep HardwareCorruptedHardwareCorrupted: 4 kB
# Workload에 영향$ dmesg | tail[12345.6789] Memory failure: 0x80067800: recovery action for huge page: Sending SIGBUSoffline된 page에 접근하는 워크로드는 SIGBUS. graceful recovery가 필요.
#Performance vs RAS 트레이드오프
| 모드 | Latency 영향 | 정확도 |
|---|---|---|
| Polling | 없음 (별도 thread) | 5초 간격 정도 |
| Interrupt | 약간 (per event ~1μs) | 즉시 |
| Hybrid | 작음 | 즉시 + summary polling |
대부분 Interrupt 권장. cxl set-event-irq -m memX -e all 명령으로 활성.
#운영 사례 — Poison Page 격리
실 상황의 poison page 처리 흐름:
- 디바이스가 internal media error 감지
- Poison list에 추가, event log에 기록
- Interrupt로 host kernel에 알림
- Kernel이 affected page를 offline
- 해당 page에 매핑되어 있던 process에 SIGBUS
- Process가 정상 종료 또는 fault handler에서 복구
- 운영팀이
cxl monitor알림으로 인지 - Poison rate를 추적해 디바이스 교체 결정
이 흐름이 데이터센터 운영 표준 절차.
#자주 만나는 함정
| 증상 | 원인 |
|---|---|
cxl health 결과 “warning” | life_used_percent 또는 dirty_shutdown 증가 — 모니터링 |
| Poison rate 갑자기 증가 | media wear 진행 — 디바이스 교체 검토 |
cxl monitor 응답 없음 | event interrupt 비활성. cxl set-event-irq 필요 |
| 영향 받은 page에 process 정지 | SIGBUS 처리 안 함 — graceful recovery 구현 필요 |
| Temperature 비현실적 (255 또는 0) | 디바이스 firmware bug — sensor 미초기화 |
| 갑작스러운 throughput 저하 | thermal throttling — cxl health temperature 확인 |
| Multi-host pool LD 접근 실패 | LD 할당 충돌 — Fabric Manager log 확인 |
| Page offline 빈번 | bad media 진행 — poison rate 임계 설정 |
| Failure event 후 region 정상 | partial failure — 영향 받은 page만 offline, 나머지 OK |
| Fatal event 후 메모리 사라짐 | 디바이스 offline 완료. region remove. |
#진단 워크플로
cxl health -m memX— 디바이스 자체 상태 확인cxl list -m memX -P— poison list 변화 추적cxl monitor -m memX— 실시간 event log 모니터링dmesg | grep -E "cxl|memory_failure|mce"— kernel 이벤트bpftrace로 이벤트 빈도 patterns 분석- 장기 추적: poison rate, life_used_percent, dirty_shutdown_count
#정리
- CXL 디바이스 트러블슈팅은 링크 디버깅과 별개 — 디바이스 측 RAS 이벤트와 poison list를 봐야 합니다.
- RAS 이벤트는 Information·Warning·Failure·Fatal 4단계. Failure 이상에서 page offline이 자동 trigger.
- Poison list는 bad media를 추적하는 리스트. internal source가 늘어남은 media wear 신호.
- cxl health·monitor·list -P가 표준 도구.
/sys/bus/cxl/devices/memX/poison/events/로 통합. - 운영에서는 poison rate·life_used·dirty_shutdown 세 지표를 장기 추적해 디바이스 교체 결정.
#다음 장 예고
Embedded Debugging 시리즈에 CXL 관련 추가 챕터는 여기까지. 다음 깊이는 Kernel Debugging Ch 8~9의 드라이버 코드 디버깅과 Memory Diagnostics Ch 6~7의 메모리 진단·tiered memory로 자연 분산됩니다.
#관련 항목
Embedded Debugging · 9 of 9
- 1 GDB Remote Serial Protocol 분석 — 디버거-타겟 통신 메커니즘
- 2 JTAG·SWD·CoreSight 분석 — ARM 디버그 인터페이스 비교
- 3 OpenOCD 심화 분석 — Configuration·Adapter·Target 통합
- 4 J-Link 도구 체인 분석 — JLinkExe·RTT·GDB Server 활용
- 5 ELF와 MAP 파일 분석 — 베어메탈 메모리 레이아웃 추적
- 6 임베디드 Trace 비교 — RTT·ITM·SWO·ETM·Semihosting 선택
- 7 RTOS-aware 디버깅과 트러블슈팅 — Task·Queue·Stack 분석
- 8 CXL Link Training 디버깅 — LTSSM 상태와 Protocol Analyzer 활용
- 9 CXL 디바이스 트러블슈팅 — RAS 이벤트·Poison List·Media Error 추적
관련 글
CXL Link Training 디버깅 — LTSSM 상태와 Protocol Analyzer 활용
CXL 링크가 안 올라올 때 LTSSM 상태 분석, Protocol Analyzer 캡처, lspci·cxl-cli·dmesg 진단 흐름.
같은 시리즈에서 이어 읽기
RTOS-aware 디버깅과 트러블슈팅 — Task·Queue·Stack 분석
FreeRTOS/Zephyr task 콜스택, Hardfault 분석, MPU, 신호 무결성, 보안 lock 해제.
같은 시리즈에서 이어 읽기
임베디드 Trace 비교 — RTT·ITM·SWO·ETM·Semihosting 선택
printf 없이 펌웨어 로그·trace 빼내기. 다섯 가지 방법 비교 + 코드 예제.
같은 시리즈에서 이어 읽기