CXL 디바이스 트러블슈팅 — RAS 이벤트·Poison List·Media Error 추적

#왜 별도 진단이 필요한가

Ch 8에서 링크 자체를 봤습니다. 링크가 정상이어도 디바이스 측에서 문제가 발생할 수 있습니다. DRAM ECC error, refresh failure, media wear 같은 디바이스 내부 이상은 링크 진단으로 안 보입니다.

CXL은 Event Log와 poison list 메커니즘으로 디바이스 측 진단 정보를 호스트에 노출합니다.

#Event Log 네 종류

CXL 디바이스는 이벤트를 네 개의 Event Log에 나눠 쌓습니다. Linux 드라이버는 로그마다 interrupt 설정을 따로 두고(info_settings·warn_settings·failure_settings·fatal_settings), trace 출력에는 아래 이름을 씁니다(drivers/cxl/core/trace.h의 cxl_event_log_type_str).

드라이버는 이벤트 interrupt를 받으면 cxl_event_thread()(drivers/cxl/pci.c)에서 Event Status 레지스터를 읽고, 해당 로그를 cxl_mem_get_event_records()로 가져옵니다. 이때 쓰는 mailbox 명령이 Get Event Records(0x0100)와 Clear Event Records(0x0101)입니다.

#CXL Mailbox로 상태 확인

디바이스 health는 Get Health Info(mailbox opcode 0x4200)로 읽고, cxl list의 -H(--health)가 이를 보여 줍니다. ndctl 문서(Documentation/cxl/cxl-list.txt)의 예시:

1
# cxl list -m mem0 -H
2
[
3
  {
4
    "memdev":"mem0",
5
    "pmem_size":268435456,
6
    "ram_size":268435456,
7
    "health":{
8
      "maintenance_needed":true,
9
      "performance_degraded":true,
10
      "hw_replacement_needed":true,
11
      "media_normal":false,
12
      "media_not_ready":false,
13
      "media_persistence_lost":false,
14
      "media_data_lost":true,
15
      "media_powerloss_persistence_loss":false,
16
      "media_shutdown_persistence_loss":false,
17
      "media_persistence_loss_imminent":false,
18
      "media_powerloss_data_loss":false,
19
      "media_shutdown_data_loss":false,
20
      "media_data_loss_imminent":false,
21
      "ext_life_used":"normal",
22
      "ext_temperature":"critical",
23
      "ext_corrected_volatile":"warning",
24
      "ext_corrected_persistent":"normal",
25
      "life_used_percent":15,
26
      "temperature":25,
27
      "dirty_shutdowns":10,
28
      "volatile_errors":20,
29
      "pmem_errors":30
30
    }
31
  }
32
]

이벤트는 cxl monitor로 봅니다. 커널이 내보내는 CXL trace event를 JSON으로 바꿔 표준 출력이나 로그 파일(--daemon --log=<file>)에 씁니다.

1
$ cxl monitor
2
$ cxl monitor --daemon --log=/var/log/cxl-monitor.log

#Poison List 추적

Poison List는 디바이스가 poison으로 표시한 주소 범위의 리스트입니다. Get Poison List의 mailbox opcode는 0x4300입니다. cxl list의 -L(--media-errors)이 이를 읽어 media_errors로 붙입니다. source는 External, Internal, Injected, Vendor Specific, Unknown 중 하나입니다(CXL 3.1 Table 8-140). ndctl 문서의 예시:

1
# cxl list -m mem9 --media-errors -u
2
{
3
  "memdev":"mem9",
4
  "pmem_size":"1024.00 MiB (1073.74 MB)",
5
  "pmem_qos_class":42,
6
  "ram_size":"1024.00 MiB (1073.74 MB)",
7
  "ram_qos_class":42,
8
  "serial":"0x5",
9
  "numa_node":1,
10
  "host":"cxl_mem.5",
11
  "media_errors":[
12
    {
13
      "offset":"0x40000000",
14
      "length":64,
15
      "source":"Injected"
16
    }
17
  ]
18
}

memdev로 조회하면 offset은 디바이스 DPA, region으로 조회하면 region 시작 기준입니다. --media-errors는 ndctl을 -Dlibtracefs=enabled로 빌드했을 때만 쓸 수 있습니다.

테스트용 poison 주입·제거는 cxl inject-media-poison과 cxl clear-media-poison입니다. 주소는 DPA로 줍니다.

1
# cxl clear-media-poison mem0 -a 0x1000
2
poison cleared at mem0:0x1000

#Linux 통합 — sysfs·debugfs

poison 관련 커널 인터페이스(Documentation/ABI/testing/sysfs-bus-cxl, debugfs-cxl):

#bpftrace로 이벤트 추적

CXL AER 이벤트 발생 빈도를 memdev별로 셉니다. cxl_aer_uncorrectable_error·cxl_aer_correctable_error tracepoint의 필드는 memdev, host, serial, status 등입니다(drivers/cxl/core/trace.h).

1
$ bpftrace -e '
2
  tracepoint:cxl:cxl_aer_uncorrectable_error {
3
    @ue[str(args->memdev)] = count();
4
  }
5
  tracepoint:cxl:cxl_aer_correctable_error {
6
    @ce[str(args->memdev)] = count();
7
  }
8
  interval:s:60 {
9
    print(@ue);
10
    print(@ce);
11
    clear(@ue);
12
    clear(@ce);
13
  }
14
'

#이벤트 처리 주체 — OS냐 펌웨어냐

이벤트 로그를 OS가 처리할지는 플랫폼이 정합니다. cxl_event_config()(drivers/cxl/pci.c)는 host bridge의 native_cxl_error가 꺼져 있으면(BIOS가 CXL error reporting 제어권을 쥔 경우) 이벤트 처리를 하지 않습니다. 주석의 설명대로 한 주체만 event record를 처리할 수 있기 때문입니다. 제어권이 OS에 있으면 드라이버가 Set Event Interrupt Policy(0x0103)로 네 로그 모두 MSI/MSI-X를 요청하고 interrupt를 등록합니다. 별도 사용자 명령으로 켜는 단계는 없습니다.

#자주 만나는 함정

#진단 워크플로

1. cxl list -m memX -H — 디바이스 health 확인
2. cxl list -m memX -L — poison list(media error) 추적
3. cxl monitor — CXL trace event 모니터링
4. dmesg | grep -i cxl — 드라이버 메시지
5. bpftrace로 AER 이벤트 빈도 분석
6. 장기 추적: life_used_percent, dirty_shutdowns, media error 수

#정리

• CXL 디바이스 트러블슈팅은 링크 디버깅과 별개 — 디바이스 측 Event Log와 poison list를 봐야 합니다.
• Event Log는 Informational·Warning·Failure·Fatal 네 종류이고, 드라이버는 interrupt를 받아 Get Event Records(0x0100)로 가져옵니다.
• health는 cxl list -H(Get Health Info, 0x4200), poison은 cxl list -L(Get Poison List, 0x4300)로 봅니다.
• 이벤트 처리 주체는 플랫폼의 native_cxl_error 설정이 정합니다.
• 운영에서는 *media error 수·life_used_percent·dirty_shutdowns*를 장기 추적해 디바이스 교체를 판단합니다.

#다음 장 예고

Embedded Debugging 시리즈에 CXL 관련 추가 챕터는 여기까지. 다음 깊이는 Kernel Debugging Ch 8~9의 드라이버 코드 디버깅과 Memory Diagnostics Ch 6~7의 메모리 진단·tiered memory로 자연 분산됩니다.

#관련 항목

• Ch 8: CXL Link Training 디버깅
• Kernel Debugging Ch 8: CXL 커널 드라이버 디버깅
• Memory Diagnostics Ch 6: CXL 메모리 진단
• Postmortem Debugging Ch 5: CXL 디바이스 Core Dump 분석