MCE (Machine Check Exception)

x86 Machine Check Architecture(MCA)의 뱅크/레지스터(Register) 구조, MCE 심각도 분류(SRAR/SRAO/UCNA), 커널 처리 경로(Monarch 랑데부), CMCI 스톰, AMD SMCA, IIO(Integrated I/O) PCIe 에러 아키텍처(Completion Timeout, Poisoned TLP, Surprise Link Down, DMA/VT-d 에러), Uncore MCA 에러 종합(M2M/CHA/UPI/PCU/TOR/MDF), KVM 가상화 MCE 전파(VMEXIT, 가상 MCE 뱅크, HWPoison→게스트), APEI/GHES 펌웨어(Firmware) 연동, EDAC DIMM 디코드, memory_failure()/HWPoison 복구, GPU/가속기 연쇄 에러 분석(Xid↔IIO MCE 상관분석, AI/ML 클러스터 영향), ARM/RISC-V/POWER EEH 비교, DDR5 On-Die ECC, Row Hammer, MCE 디버깅 기법(perf/ftrace/eBPF), 로그 디코딩 실전과 운영 플레이북까지 다룹니다.

MCE 아키텍처 개요

Machine Check Exception(MCE)은 x86 아키텍처에서 벡터 18(#MC)로 정의된 abort 클래스 예외입니다. CPU 내부 또는 외부에서 발생하는 하드웨어 오류 — ECC 메모리 오류, 캐시 패리티 오류, 버스 타임아웃, TLB 오류 등 — 를 소프트웨어에 알려주는 유일한 표준 메커니즘입니다.

예외 특성

MCE의 위치: x86 예외 계층

MCE는 동기(synchronous)와 비동기(asynchronous) 모두 가능합니다. 명령어 실행 중 발견된 메모리 오류(SRAR)는 동기적이고, 백그라운드 스크러빙이 발견한 오류(SRAO)는 비동기적입니다. 커널은 동기 MCE를 더 긴급하게 처리합니다.

/* arch/x86/kernel/cpu/mce/core.c — MCE 활성화 */
void mcheck_cpu_init(struct cpuinfo_x86 *c)
{
    /* CR4.MCE 비트 설정 — 이것이 없으면 MCE 시 triple fault → 리셋 */
    cr4_set_bits(X86_CR4_MCE);
    /* 각 MCA 뱅크의 CTL 레지스터를 0xFFFFFFFFFFFFFFFF로 설정 (모든 에러 활성화) */
    for (i = 0; i < num_banks; i++)
        wrmsrl(MSR_IA32_MCx_CTL(i), 0xFFFFFFFFFFFFFFFFULL);
}

MCA 뱅크와 레지스터

MCA(Machine Check Architecture)는 CPU 내부의 에러 감지 유닛을 뱅크(bank) 단위로 구성합니다. 각 뱅크는 특정 하드웨어 컴포넌트(L1 캐시, L2 캐시, 메모리 컨트롤러, QPI/UPI 등)에 매핑(Mapping)되며, 독립적인 레지스터 세트를 가집니다.

글로벌 레지스터

뱅크별 레지스터 (i = 0..N-1)

/* arch/x86/kernel/cpu/mce/core.c — 뱅크 스캔 */
static void __mcheck_cpu_mce_banks_init(void)
{
    int i;
    u64 cap;

    rdmsrl(MSR_IA32_MCG_CAP, cap);
    num_banks = cap & MCG_BANKCNT_MASK;   /* bits [7:0] */

    for (i = 0; i < num_banks; i++) {
        struct mce_bank *b = &mce_banks[i];
        b->ctl = ~(u64)0;   /* 모든 에러 유형 활성화 */
        wrmsrl(MSR_IA32_MCx_CTL(i), b->ctl);
    }
}

IA32_MCi_STATUS 비트 필드 상세

MCi_STATUS는 MCA의 핵심 레지스터로, 64비트 전체가 에러 정보를 담고 있습니다. 커널의 MCE 핸들러는 이 레지스터의 비트 조합으로 에러의 종류, 심각도, 복구 가능성을 판단합니다.

MCA 에러 코드 분류

MCi_STATUS의 하위 16비트(bits 15:0)는 MCA 에러 코드로, Intel SDM에서 정의한 표준 포맷을 따릅니다. 크게 Simple Error Code와 Compound Error Code로 나뉩니다.

Simple Error Code (단순 에러 코드)

Compound Error Code (복합 에러 코드)

복합 에러 코드는 000F 0FTT LLLL 형식의 비트 패턴으로 인코딩됩니다.

/* arch/x86/kernel/cpu/mce/severity.c — 에러 코드 디코딩 */
#define MCESEV(s, m, c...) { .sev = MCE_##s##_SEVERITY, .msg = m, ##c }

static struct severity {
    u64 mask;
    u64 result;
    unsigned char sev;
    unsigned char mcgmask;
    unsigned char mcgres;
    char *msg;
} severities[] = {
    MCESEV(NO, "Invalid",
        SER, BITCLR(MCI_STATUS_VAL)),
    MCESEV(NO, "Not enabled",
        SER, BITCLR(MCI_STATUS_EN)),
    MCESEV(PANIC, "Processor context corrupt",
        BITSET(MCI_STATUS_PCC)),
    /* ... */
};

메모리 관련 에러 코드 상세

메모리 컨트롤러에서 발생하는 에러는 가장 흔한 MCE 원인입니다. 다음은 Intel/AMD 메모리 컨트롤러 뱅크에서 자주 보이는 에러 코드 패턴입니다.

MCE 심각도 분류

커널 함수 mce_severity()는 MCi_STATUS 비트를 분석하여 에러의 심각도를 결정합니다. Intel의 Software Developer's Manual에서 정의한 4가지 등급과 커널의 내부 분류가 있습니다.

Intel MCA Recovery 분류

/* arch/x86/kernel/cpu/mce/severity.c */
static int mce_severity_intel(struct mce *m, struct pt_regs *regs,
                               char **msg, bool is_excp)
{
    /* severities[] 테이블을 순회하며 mask/result 매칭 */
    for (struct severity *s = severities;; s++) {
        if ((m->status & s->mask) != s->result)
            continue;
        if ((m->mcgstatus & s->mcgmask) != s->mcgres)
            continue;
        *msg = s->msg;
        return s->sev;
    }
}

커널 MCE 진입 경로

MCE가 발생하면 CPU는 IDT의 벡터 18 핸들러로 점프합니다. 리눅스 커널 6.x에서의 진입 경로는 어셈블리(Assembly) 엔트리 포인트에서 시작하여 C 핸들러까지 이어집니다.

/* arch/x86/kernel/cpu/mce/core.c */
DEFINE_IDTENTRY_MCE(exc_machine_check)
{
    /* MCE 핸들러는 NMI-like 컨텍스트에서 실행 */
    if (user_mode(regs))
        nmi_enter();

    do_machine_check(regs);

    if (user_mode(regs))
        nmi_exit();
}

/* IST 3 설정: arch/x86/kernel/idt.c */
static const __initconst struct idt_data def_idts[] = {
    /* ... */
    ISTG(X86_TRAP_MC, asm_exc_machine_check, IST_INDEX_MCE),  /* IST 3 */
};

do_machine_check() 처리 흐름

do_machine_check()는 MCE의 핵심 처리 함수입니다. 멀티 CPU 환경에서 여러 코어가 동시에 MCE를 받을 수 있으므로, Monarch 랑데부 프로토콜로 동기화한 뒤 한 CPU가 최종 결정을 내립니다.

/* arch/x86/kernel/cpu/mce/core.c — 핵심 흐름 */
noinstr void do_machine_check(struct pt_regs *regs)
{
    int worst = MCE_NO_SEVERITY;
    int order, no_way_out;

    /* Phase 1: Monarch 선출 및 랑데부 */
    order = mce_start(&no_way_out);

    /* Phase 2: 자신의 MCA 뱅크 스캔 */
    for (i = 0; i < num_banks; i++) {
        rdmsrl(MSR_IA32_MCx_STATUS(i), m.status);
        if (!(m.status & MCI_STATUS_VAL))
            continue;
        severity = mce_severity(&m, regs, &msg, true);
        if (severity > worst)
            worst = severity;
        mce_log(&m);  /* 링 버퍼에 기록 */
    }

    /* Phase 3: Monarch가 최종 결정 */
    if (order == 1)  /* Monarch */
        mce_reign();   /* worst severity 수집 → panic/recover */

    /* Phase 4: 랑데부 완료 */
    mce_end(order);

    /* Phase 5: 에러 클리어 */
    for (i = 0; i < num_banks; i++)
        wrmsrl(MSR_IA32_MCx_STATUS(i), 0);
}

Monarch 메커니즘

MCE는 일반적으로 모든 CPU에 동시에 브로드캐스트됩니다(LMCE 제외). 여러 CPU가 동시에 핸들러를 실행하면 의사결정이 분산되어 일관성을 잃을 수 있으므로, Monarch(군주) 프로토콜로 하나의 CPU가 최종 결정권을 갖습니다.

Monarch 선출 규칙

1. mce_start()에서 atomic_inc_return(&mce_callin)을 호출
2. 리턴 값이 1인 CPU가 Monarch (가장 먼저 도착한 CPU)
3. 나머지 CPU(Subject)는 Monarch의 결정을 대기
4. Monarch는 모든 Subject가 mce_callin에 도달하거나 타임아웃까지 대기

tolerant 레벨

/sys/devices/system/machinecheck/machinecheck0/tolerant 설정으로 MCE 대응 수준을 조절합니다.

mce_panic()의 결정 시점

/* arch/x86/kernel/cpu/mce/core.c */
static void mce_reign(void)
{
    int global_worst = MCE_NO_SEVERITY;

    /* 모든 CPU의 worst severity 수집 */
    for_each_possible_cpu(cpu) {
        int severity = per_cpu(mce_worst_severity, cpu);
        if (severity > global_worst)
            global_worst = severity;
    }

    if (global_worst >= MCE_PANIC_SEVERITY) {
        mce_panic("Fatal machine check", &m, msg);
        /* 여기서 리턴하지 않음 */
    }
    /* PANIC이 아니면 복구 경로로 진행 */
}

Monarch 타임아웃

Monarch는 Subject CPU의 도착을 monarch_timeout(기본 ~500us, CPU마다 조정)까지 대기합니다. 타임아웃이 발생하면 Monarch는 도착한 CPU 정보만으로 결정을 내립니다. 이는 MCE 자체가 일부 CPU를 무응답 상태로 만들었을 수 있기 때문입니다.

MCG_STATUS.MCIP 비트

MCG_STATUS의 MCIP(Machine Check In Progress) 비트는 MCE 핸들러가 실행 중임을 나타냅니다. 이 비트가 1인 상태에서 새로운 MCE가 발생하면 CPU는 shutdown 상태에 들어갑니다(triple fault). 따라서 커널은 MCE 핸들러 완료 시 반드시 MCG_STATUS.MCIP = 0으로 클리어해야 합니다.

/* MCE 핸들러 완료 시 MCIP 클리어 */
static void mce_wrmsrl(u32 msr, u64 v)
{
    if (msr == MSR_IA32_MCG_STATUS) {
        v &= ~MCG_STATUS_MCIP;  /* MCIP 클리어 → 다음 MCE 수신 가능 */
    }
    wrmsrl(msr, v);
}

Monarch와 가상화(Virtualization)

KVM 가상화 환경에서 MCE가 발생하면, 하이퍼바이저(Hypervisor)가 먼저 MCE를 가로챕니다(VMEXIT). 호스트 커널의 Monarch가 에러를 분석한 후, 게스트에 영향이 있으면 게스트에 가상 MCE를 주입합니다. LMCE 지원 시 게스트 vCPU에만 MCE를 전달하여 다른 vCPU의 VMEXIT를 방지합니다.

Monarch 상태 머신

Monarch 프로토콜은 명확한 상태 전이를 통해 진행됩니다. 모든 CPU가 MCE를 수신하면 mce_start()에서 동기화 배리어를 형성하고, Monarch CPU(가장 낮은 번호)가 최종 결정을 내립니다.

/* arch/x86/kernel/cpu/mce/core.c — mce_start() 내부 로직 */
static int mce_start(int *no_way_out)
{
    int order;
    int cpus = num_online_cpus();
    u64 timeout = (u64)mca_cfg.monarch_timeout * NSEC_PER_USEC;

    if (!timeout)
        return -1;  /* Monarch 비활성화 → 독립 처리 */

    /* 1단계: CALLIN — 모든 CPU가 도착을 알림 */
    atomic_add(*no_way_out, &global_nwo);
    order = atomic_inc_return(&mce_callin);  /* 도착 순서 기록 */

    /* 2단계: CALLIN 배리어 — 모든 CPU 도착 대기 */
    mce_barrier_enter(&mce_callin_barrier, timeout);

    /* order == 1인 CPU가 Monarch (첫 번째 도착) */
    if (order == 1) {
        /* Monarch: 글로벌 상태 초기화 */
        atomic_set(&global_nwo, 0);
        atomic_set(&mce_executing, 0);
    }

    /* 타임아웃 처리: 일부 CPU 미도착 시 도착한 CPU만으로 진행 */
    if (atomic_read(&mce_callin) != cpus) {
        mce_timed_out(&timeout,
            "Not all CPUs arrived at MCE rendezvous\n");
    }

    return order;
}

Monarch 결정 매트릭스

Monarch CPU는 mce_reign()에서 수집된 모든 MCE 정보를 종합하여 global_worst 심각도와 시스템 설정에 따라 최종 조치를 결정합니다.

MCE와 CPU 핫플러그(Hotplug)

CPU 핫플러그 도중 MCE가 발생하면 특수한 상황이 발생합니다. 오프라인 상태이거나 핫플러그 진행 중인 CPU는 Monarch 랑데부에서 제외되어야 합니다.

커널은 다음과 같은 메커니즘으로 이 문제를 처리합니다:

• 오프라인 CPU 제외: mce_start()에서 num_online_cpus()를 사용하여 현재 온라인 CPU 수만 카운트합니다. 오프라인 CPU는 배리어 도착 대상에 포함되지 않습니다.
• 핫플러그 진행 중: CPU가 CPU_DEAD 상태로 전환되는 과정에서 MCE가 발생하면, 해당 CPU의 MCE 핸들러는 이미 해제(mce_cpu_dead())되어 #MC 인터럽트를 받지 못합니다. 따라서 자연스럽게 랑데부에서 제외됩니다.
• CPU 온라인 시: mce_cpu_online()에서 MCE 뱅크를 재초기화하고, 타이머를 재설정하며, CMCI를 재활성화합니다. 이전에 누적된 CE는 새로 폴링됩니다.
• 타임아웃 보호: 핫플러그 경합(Contention)으로 CPU 수가 일시적으로 불일치하는 경우, monarch_timeout이 데드락을 방지합니다. 타임아웃 만료 시 도착한 CPU만으로 진행합니다.

/* arch/x86/kernel/cpu/mce/core.c — CPU 핫플러그 콜백 */
static int mce_cpu_online(unsigned int cpu)
{
    struct timer_list *t = this_cpu_ptr(&mce_timer);

    mce_device_create(cpu);       /* sysfs 노드 생성 */
    mce_threshold_create_device(cpu);
    mce_reenable_cpu();           /* MCE 뱅크 재활성화 */
    mce_start_timer(t);          /* 폴링 타이머 시작 */
    return 0;
}

static int mce_cpu_dead(unsigned int cpu)
{
    mce_threshold_remove_device(cpu);
    mce_device_remove(cpu);       /* sysfs 노드 제거 */
    return 0;
    /* 이후 이 CPU는 #MC를 수신하지 않음 → Monarch 랑데부 제외 */
}

MCE Notifier Chain과 복구

Notifier Chain 등록 우선순위(Priority)

kill_me_now vs kill_me_later

SRAR 에러에서 커널은 두 가지 킬 전략을 사용합니다.

• kill_me_now — MCE 핸들러 내에서 즉시 force_sig(SIGBUS)를 전송. 현재 태스크(Task)가 에러 데이터를 소비한 경우에 사용.
• kill_me_later — 핸들러 리턴 후 태스크가 다시 스케줄될 때 SIGBUS를 전송. 현재 태스크와 무관한 에러일 때 사용.

/* memory_failure_queue() — 비동기 처리 큐 */
void memory_failure_queue(unsigned long pfn, int flags)
{
    struct memory_failure_entry entry = {
        .pfn = pfn,
        .flags = flags,
    };
    kfifo_put(&mf_cpu->fifo, entry);
    schedule_work_on(smp_processor_id(), &mf_cpu->work);
}

MCE 링 버퍼(Ring Buffer) 구조

커널은 MCE 이벤트를 순환(circular) 링 버퍼에 기록합니다. 이 버퍼(Buffer)는 프로듀서-컨슈머 모델로 동작하며, NMI 컨텍스트에서도 안전하게 쓸 수 있도록 설계되어 있습니다.

MCE 이벤트 필터링

perf를 사용하면 MCE 이벤트를 실시간(Real-time)으로 캡처하고 디코딩할 수 있습니다. mce:mce_record 트레이스포인트는 모든 MCE 로깅 경로에서 호출됩니다.

# MCE 트레이스 이벤트 캡처
$ perf record -e mce:mce_record -a --overwrite # 시스템 전체 기록

# 기록된 MCE 이벤트 디코딩
$ perf script
  mcelog  3421 [002] 1842.553291: mce:mce_record: \
    CPU: 2, MCGc: 0x0, MCGi: 0xf10, \
    Bank: 9, MCi: 0xbd80000000100134, \
    Addr: 0x3a7f8c000, MISC: 0x8c, severity: CE

# 특정 뱅크만 필터링 (Bank 9 = Memory Controller)
$ perf record -e mce:mce_record --filter 'bank == 9' -a

# ftrace로 직접 캡처 (perf 없이)
$ echo 1 > /sys/kernel/debug/tracing/events/mce/mce_record/enable
$ cat /sys/kernel/debug/tracing/trace_pipe

rasdaemon은 이러한 트레이스 이벤트를 SQLite DB에 저장하여 장기간 CE 추적과 페이지별 오류 통계를 제공합니다. 레거시 mcelog 데몬은 /dev/mcelog에서 직접 읽는 방식이며, 최신 커널에서는 rasdaemon 사용이 권장됩니다.

# rasdaemon으로 MCE 이력 조회
$ ras-mc-ctl --errors
# Label  CE count  UE count  Last error
# DIMM0  47        0         2026-03-15 14:23:01 Bank 9 CE
# DIMM1  0         0         —
# DIMM2  3         1         2026-03-14 09:11:44 Bank 9 UCE

# 페이지별 CE 누적 카운트 (메모리 교체 판단 기준)
$ ras-mc-ctl --error-count
# mc0: csrow0: ch0: 47 CEs, ch1: 0 CEs

# SQLite DB 직접 쿼리
$ sqlite3 /var/lib/rasdaemon/ras-mc_event.db \
    "SELECT timestamp, err_type, mc_location FROM mce_record \
     WHERE mcgstatus LIKE '%MCIP%' ORDER BY id DESC LIMIT 10;"

memory_failure()와 HWPoison

memory_failure()는 물리 메모리(Physical Memory) 페이지의 하드웨어 오류를 처리하는 핵심 함수입니다. 커널은 해당 페이지를 HWPoison으로 마킹하고, 페이지 유형에 따라 적절한 복구 조치를 수행합니다.

/* mm/memory-failure.c — 핵심 함수 */
int memory_failure(unsigned long pfn, int flags)
{
    struct page *p = pfn_to_page(pfn);

    /* 1. HWPoison 마킹 */
    SetPageHWPoison(p);

    /* 2. 페이지 잠금 및 참조 획득 */
    shake_page(p);  /* LRU에서 제거 시도 */

    /* 3. 페이지 유형에 따른 처리 */
    if (PageHuge(p))
        return memory_failure_hugetlb(pfn, p, flags);

    if (!PageLRU(p))
        return identify_page_state(pfn, p, flags);  /* 커널 페이지 등 */

    /* 4. 프로세스에 SIGBUS 전송 */
    collect_procs(p, &tokill);  /* 매핑한 프로세스 목록 */
    kill_procs(&tokill, flags & MF_ACTION_REQUIRED, pfn, flags);

    /* 5. 페이지 오프라인 */
    page_action(ps, p, pfn);
    return 0;
}

page_action[] 타입별 처리 상세

memory_failure()는 오류 페이지의 유형을 판별한 뒤 page_action[] 배열에서 해당 타입의 핸들러를 호출합니다. 커널 소스(mm/memory-failure.c)의 error_states[] 배열이 이 매핑을 정의하며, 각 페이지 상태에 따라 복구 가능 여부와 처리 방식이 크게 달라집니다.

/* mm/memory-failure.c — error_states[] 배열 (커널 6.x 기준 간략화) */
static struct page_state error_states[] = {
    { 0,              0,         "free buddy",      me_free       },
    { slab,           slab,       "kernel slab",     me_kernel     },
    { head,           head,       "huge page",       me_huge_page  },
    { sc|dirty,       sc|dirty,   "swapcache dirty", me_swapcache_dirty },
    { sc,             sc,         "swapcache clean", me_swapcache_clean },
    { mlock|dirty,    dirty,      "dirty mlocked",   me_pagecache_dirty },
    { mlock,          mlock,      "clean mlocked",   me_pagecache_clean },
    { lru|dirty,      dirty,      "dirty LRU",       me_pagecache_dirty },
    { lru,            lru,        "clean LRU",       me_pagecache_clean },
    { 0,              0,         "unknown page",    me_unknown    },
};

ECC 유형과 MCE 관계

서버 메모리에서 사용되는 ECC(Error Correcting Code) 수준에 따라 MCE의 CE(Corrected Error)와 UC(Uncorrected Error) 발생 패턴이 달라집니다. ECC가 강력할수록 더 많은 비트 오류를 CE로 교정하여 UC 발생을 줄입니다.

MCi_MISC 비트 필드 상세

MCi_MISC 레지스터는 오류 주소의 해석 방법과 복구 가능 주소의 정밀도를 알려줍니다. 특히 UCR(Uncorrected Recoverable) 에러에서 memory_failure()에 전달할 물리 주소(Physical Address)의 유효 범위를 결정하는 데 핵심적인 역할을 합니다.

/* arch/x86/kernel/cpu/mce/severity.c — MISC 비트 해석 */
#define MCI_MISC_ADDR_LSB(m)    ((m) & 0x3f)        /* bits [5:0]  */
#define MCI_MISC_ADDR_MODE(m)   (((m) >> 6) & 7)  /* bits [8:6]  */
#define MCI_MISC_ADDR_PHYS      2                    /* 물리 주소 모드 */

/* UCR 에러에서 PFN 추출 시 LSB를 확인 */
if (MCI_MISC_ADDR_MODE(m->misc) != MCI_MISC_ADDR_PHYS)
    return;  /* 물리 주소가 아니면 memory_failure 호출 불가 */

int lsb = MCI_MISC_ADDR_LSB(m->misc);
if (lsb > PAGE_SHIFT)
    lsb = PAGE_SHIFT;  /* 페이지 단위로 클램프 */

MCi_ADDR 주소 해석

MCi_ADDR 레지스터에 기록된 주소는 MCi_MISC의 Address Mode에 따라 해석 방법이 다릅니다. 대부분의 메모리 에러에서는 물리 주소 모드(010)가 사용되며, 커널은 이 주소에서 PFN(Page Frame Number)을 추출하여 memory_failure()에 전달합니다.

/* arch/x86/kernel/cpu/mce/core.c — MCi_ADDR에서 PFN 추출 */
static void mce_log_and_process(struct mce *m)
{
    unsigned long pfn;
    int lsb;

    /* 물리 주소 모드가 아니면 복구 불가 */
    if (MCI_MISC_ADDR_MODE(m->misc) != MCI_MISC_ADDR_PHYS)
        return;

    /* 유효 비트 하한 */
    lsb = MCI_MISC_ADDR_LSB(m->misc);
    if (lsb > PAGE_SHIFT)
        lsb = PAGE_SHIFT;

    /* PFN 추출: 하위 비트 마스크 후 페이지 시프트 */
    pfn = (m->addr >> PAGE_SHIFT) &
          (((1UL << (46 - PAGE_SHIFT)) - 1));

    /* memory_failure 호출 (MF_ACTION_REQUIRED는 SRAR 에러에서 설정) */
    memory_failure(pfn, m->mcgstatus & MCG_STATUS_RIPV ?
                   MF_ACTION_REQUIRED : 0);
}

/* EDAC에서 물리 주소 → DIMM 위치 디코딩 (drivers/edac/skx_common.c) */
static int skx_decode_addr(u64 addr, struct decoded_addr *res)
{
    /* System Address → Socket → iMC → Channel → DIMM → Rank → Bank → Row/Col */
    res->socket  = skx_sad_decode(addr);
    res->imc     = skx_tad_decode(addr);
    res->channel = skx_channel_decode(addr);
    res->dimm    = skx_dimm_decode(addr);
    return 0;
}

CMCI (Corrected MCE Interrupt)

CMCI(Corrected Machine Check Error Interrupt)는 교정된 에러(CE)를 효율적으로 수집하는 메커니즘입니다. 전통적인 MCE 폴링은 주기적으로 MSR을 읽어야 했지만, CMCI는 CE가 임계값에 도달하면 인터럽트를 발생시켜 즉시 알려줍니다.

CMCI vs 폴링 비교

/* arch/x86/kernel/cpu/mce/intel.c */
static void cmci_storm_begin(int bank)
{
    __clear_bit(bank, this_cpu_ptr(mce_poll_banks));
    cmci_toggle_interrupt_mode(false);  /* CMCI_EN = 0 */
    /* 폴링 타이머 활성화 */
    mce_timer_kick(CMCI_STORM_INTERVAL);
}

static void cmci_storm_end(int bank)
{
    cmci_toggle_interrupt_mode(true);   /* CMCI_EN = 1 복원 */
    mce_timer_kick(CMCI_POLL_INTERVAL);
}

CMCI 임계값 설정

MCi_CTL2 레지스터의 bits [14:0]이 CMCI 임계값을 결정합니다. CE가 이 값에 도달하면 CMCI 인터럽트가 발생합니다. 커널은 기본적으로 임계값을 1로 설정하여 첫 번째 CE부터 즉시 인터럽트를 받습니다.

/* arch/x86/kernel/cpu/mce/intel.c — CMCI 임계값 설정 */
static void cmci_set_threshold(int bank, int thresh)
{
    u64 val;

    rdmsrl(MSR_IA32_MCx_CTL2(bank), val);
    val &= ~MCI_CTL2_CMCI_THRESHOLD_MASK;
    val |= (u64)thresh & MCI_CTL2_CMCI_THRESHOLD_MASK;
    val |= MCI_CTL2_CMCI_EN;    /* bit 30: CMCI 활성화 */
    wrmsrl(MSR_IA32_MCx_CTL2(bank), val);
}

Corrected Error Collector (CEC)

Intel CPU에서 커널은 CEC(Corrected Error Collector)를 사용하여 CE가 반복되는 물리 페이지를 추적합니다. 동일 페이지에서 CE가 임계값을 초과하면 soft_offline_page()를 호출하여 예방적으로 오프라인합니다.

/* arch/x86/kernel/cpu/mce/intel.c — CEC */
static int cec_add_elem(u64 pfn)
{
    /* pfn을 decay table에 삽입 */
    /* 동일 pfn의 카운트가 action_threshold 초과 시: */
    if (count >= action_threshold) {
        /* 페이지 예방 오프라인 */
        soft_offline_page(pfn_to_page(pfn), MF_SOFT_OFFLINE);
        return 1;
    }
    return 0;
}

AMD Scalable MCA (SMCA)

AMD는 Zen 아키텍처부터 Scalable MCA(SMCA)를 도입하여 기존 MCA의 한계를 극복했습니다. SMCA는 뱅크별로 하드웨어 유닛을 동적으로 식별할 수 있어, 마이크로아키텍처 변경에 유연하게 대응합니다.

SMCA vs 기존 MCA

SMCA 추가 레지스터

/* arch/x86/kernel/cpu/mce/amd.c — SMCA 뱅크 타입 결정 */
enum smca_bank_types smca_get_bank_type(unsigned int cpu, unsigned int bank)
{
    struct smca_bank *b;

    if (bank >= MAX_NR_BANKS)
        return N_SMCA_BANK_TYPES;

    b = &smca_banks[bank];
    if (!b->hwid)
        return N_SMCA_BANK_TYPES;

    return b->hwid->bank_type;  /* SMCA_LS, SMCA_IF, SMCA_L2, SMCA_DE, ... */
}

/* SMCA 하드웨어 유닛 목록 */
static const struct smca_hwid smca_hwid_mcatypes[] = {
    { SMCA_LS,      HWID_MCATYPE(0xB0, 0x0) },  /* Load Store */
    { SMCA_LS_V2,   HWID_MCATYPE(0xB0, 0x10) }, /* Load Store V2 */
    { SMCA_IF,      HWID_MCATYPE(0xB1, 0x0) },  /* Instruction Fetch */
    { SMCA_L2_CACHE, HWID_MCATYPE(0xB2, 0x0) }, /* L2 Cache */
    { SMCA_DE,      HWID_MCATYPE(0xB3, 0x0) },  /* Decode Unit */
    { SMCA_EX,      HWID_MCATYPE(0xB6, 0x0) },  /* Execution Unit */
    { SMCA_FP,      HWID_MCATYPE(0xB7, 0x0) },  /* Floating Point */
    { SMCA_UMC,     HWID_MCATYPE(0x96, 0x0) },  /* Unified Memory Controller */
    /* ... */
};

Intel CPU 뱅크 매핑 (Skylake-SP 이후)

Intel 전통 MCA에서는 뱅크 번호가 CPU 마이크로아키텍처마다 다르게 매핑됩니다. 아래는 Skylake-SP(Xeon Scalable) 이후 서버 CPU의 일반적인 뱅크 할당입니다. Ice Lake-SP, Sapphire Rapids에서는 일부 뱅크가 추가/변경될 수 있습니다.

AMD Zen SMCA 뱅크 타입 전체 목록

SMCA에서는 MCi_IPID 레지스터의 HWID(bits [43:32])와 MCATYPE(bits [63:48])으로 하드웨어 유닛을 식별합니다. 아래는 커널 소스(arch/x86/kernel/cpu/mce/amd.c)에 정의된 전체 SMCA 뱅크 타입입니다.

Deferred Error (SMCA 고유)

AMD SMCA는 Deferred Error라는 고유한 에러 유형을 지원합니다. Deferred Error는 즉각적인 데이터 손상을 일으키지는 않지만, 나중에 소비되면 문제가 될 수 있는 "잠재적 오류"입니다. 주로 배경 패트롤 스크러빙(background patrol scrubbing)에서 발견된 에러를 보고하는 데 사용됩니다.

일반적인 UC(Uncorrected) 에러와 Deferred Error의 핵심적인 차이점은 다음과 같습니다:

/* arch/x86/kernel/cpu/mce/amd.c — Deferred Error 처리 */
static void amd_deferred_error_interrupt(void)
{
    unsigned int bank;

    for (bank = 0; bank < this_cpu_read(mce_num_banks); bank++) {
        u64 status, addr;

        rdmsrl(MSR_AMD64_SMCA_MCx_DESTAT(bank), status);
        if (!(status & MCI_STATUS_VAL))
            continue;

        if (!(status & MCI_STATUS_DEFERRED))  /* bit 32: Deferred 플래그 */
            continue;

        rdmsrl(MSR_AMD64_SMCA_MCx_DEADDR(bank), addr);

        /* 지연 에러 주소로 선제적 memory_failure 호출 */
        if (addr) {
            unsigned long pfn = addr >> PAGE_SHIFT;
            memory_failure(pfn, 0);  /* MF_ACTION_REQUIRED 미설정 */
        }

        /* DESTAT 클리어 */
        wrmsrl(MSR_AMD64_SMCA_MCx_DESTAT(bank), 0);
    }
}

/* Deferred Error는 APIC LVT에 별도 벡터(DEFERRED_ERROR_VECTOR)로 전달됨 */
/* AMD 특유: 패트롤 스크러빙이 CE로 교정 불가한 오류를 발견하면       */
/* 즉시 UC를 발생시키지 않고 DESTAT에 기록 → 소프트웨어가 선제 대응 가능 */

IIO (Integrated I/O) MCA 아키텍처

Intel 서버 CPU(Xeon Scalable 이후)에서 IIO(Integrated I/O)는 CPU 다이에 통합된 I/O 서브시스템으로, PCIe 루트 포트, DMI(Direct Media Interface), CBDMA/IOAT(Crystal Beach DMA), VT-d(Intel Virtualization Technology for Directed I/O) 엔진 등을 포함합니다. IIO는 CPU 내부에서 I/O 장치와 메시 인터커넥트 사이를 연결하는 핵심 컴포넌트이며, 전용 MCA 뱅크(일반적으로 Bank 5~8)를 통해 I/O 관련 하드웨어 에러를 보고합니다.

IIO 내부 구조

각 IIO 스택(Stack)은 독립적인 PCIe 루트 컴플렉스를 제공합니다. Intel Xeon Scalable 플랫폼에서 소켓당 최대 6개의 IIO 스택이 존재하며, 각 스택은 PCIe 루트 포트, DMA 엔진, IOMMU를 포함합니다.

IIO MCA 뱅크 구조

IIO에서 보고되는 에러는 일반적으로 Bank 5~8에 매핑됩니다(CPU 모델에 따라 다름). 각 뱅크는 특정 IIO 스택에 대응합니다. IIO 뱅크의 MCi_STATUS 에러 코드는 표준 MCA 복합 에러 코드 외에 Intel 모델 고유 에러 코드(MSCOD)도 포함합니다.

IIO MCi_STATUS 에러 코드 해석

IIO 뱅크의 MCi_STATUS 레지스터에서 에러 코드(bits 15:0)는 표준 MCA 형식을 따르지만, MSCOD(Model-Specific Error Code, bits 31:16)에 IIO 고유의 상세 정보가 인코딩됩니다. PCIe 에러의 경우 MSCOD 필드에서 PCIe AER 에러 유형을 구분할 수 있습니다.

IIO MCi_MISC 레지스터 해석

IIO 뱅크에서 MCi_MISC(MISCV=1일 때)에는 에러와 관련된 PCIe 장치의 Bus/Device/Function(BDF) 정보가 인코딩됩니다. 이를 통해 에러를 발생시킨 특정 PCIe 장치를 정확히 식별할 수 있습니다.

/* IIO MCA MISC에서 BDF 추출 예시 (커널 내부) */
static void decode_iio_mce(struct mce *m)
{
    u8  func = m->misc & 0xFF;
    u8  dev  = (m->misc >> 8) & 0x1F;
    u16 bus  = (m->misc >> 13) & 0xFF;

    pr_emerg("IIO MCE: PCIe BDF %02x:%02x.%x MSCOD=0x%04x\n",
             bus, dev, func,
             (u16)(m->status >> 16) & 0xFFFF);
}

PCIe AER vs IIO MCA: 에러 보고 이중 경로

동일한 PCIe 에러가 두 가지 경로로 보고될 수 있습니다: PCIe AER(Advanced Error Reporting)와 IIO MCA 뱅크입니다. 이 두 경로는 독립적이며, 에러 발생 시 둘 다 트리거될 수 있습니다.

IIO 에러 시나리오별 분석

시나리오 1: PCIe Completion Timeout (CTO)

가장 흔한 IIO 에러입니다. CPU가 PCIe 장치에 요청을 보냈으나, 설정된 시간(기본 50ms~3.2초) 내에 응답을 받지 못한 경우입니다.

시나리오 2: Poisoned TLP 수신

PCIe 장치가 "독성(Poisoned)" 데이터를 포함한 TLP를 전송한 경우입니다. 이는 상류 장치의 메모리(예: GPU VRAM)에서 ECC 에러가 발생했음을 의미합니다.

시나리오 3: Surprise Link Down

시나리오 4: DMA/IOAT 엔진 에러 (CBDMA/DSA)

시나리오 5: VT-d (IOMMU) 변환 실패

IIO 데이터 경로와 에러 감지 지점

IIO 스택 내부에서 PCIe 트랜잭션(Transaction)은 여러 단계를 거치며, 각 단계마다 독립적인 에러 감지 로직이 있습니다. 에러가 어느 단계에서 감지되었는지에 따라 MSCOD와 복구 가능성이 달라집니다.

IIO Poison 전파 모델과 Viral Mode

PCIe 장치에서 Poisoned TLP를 수신한 IIO는 두 가지 전략 중 하나를 선택합니다: Containment(격리) 또는 Propagation(전파). 이 동작은 BIOS의 Viral Mode 설정과 IIO 내부 로직에 의해 결정됩니다.

IIO와 PCIe 스위치/팬아웃 토폴로지(Topology)

GPU 클러스터, NVMe JBOF, 스토리지 어레이에서는 PCIe 스위치(예: Broadcom PEX, Microchip Switchtec)를 통해 여러 장치를 하나의 IIO 스택에 연결합니다. 스위치를 경유한 에러는 디버깅이 더 복잡합니다.

# PCIe 스위치 뒤 장치 에러 추적 워크플로

# 1. IIO MCE에서 BDF 식별 → 스위치 Downstream Port일 수 있음
$ lspci -s <BDF>
# 출력 예: 85:00.0 PCI bridge: Broadcom PEX 8747 (rev ca)

# 2. 스위치 하위 장치 나열
$ lspci -tv -s <BDF>

# 3. 스위치 자체 AER 상태 확인
$ cat /sys/bus/pci/devices/0000:<BDF>/aer_dev_nonfatal

# 4. 스위치 하위 포트별 AER 확인
for dev in $(lspci -D | grep "PCI bridge" | awk '{print $1}'); do
  echo "--- $dev ---"
  cat /sys/bus/pci/devices/$dev/aer_dev_nonfatal 2>/dev/null
done

# 5. Switchtec 관리 도구 (Microchip 스위치)
$ switchtec status /dev/switchtec0
$ switchtec log-dump /dev/switchtec0

추가 IIO 에러 시나리오

시나리오 6: PCIe Replay Timer Timeout (DLLP CE)

시나리오 7: MMIO 트랜잭션 에러 (CPU→장치 방향)

시나리오 8: PCIe AtomicOp / Extended Tag 에러

시나리오 9: DMI (Stack 0) 에러

시나리오 10: 가상화 환경 VFIO Passthrough IIO 에러

Intel 세대별 IIO 변천사

IIO 에러 디버깅 워크플로

# 1. IIO MCA 뱅크 에러 확인
$ dmesg | grep -i "iio\|bank [5-8]\|mce.*bank"

# 2. PCIe AER 에러 동시 확인
$ dmesg | grep -i "aer\|pcieport"

# 3. 에러 발생 장치 BDF 식별 (MCA MISC에서 디코딩)
$ mcelog --client | grep -i "iio\|misc"

# 4. 해당 BDF의 장치 정보 확인
$ lspci -vvvs <BDF>

# 5. PCIe 링크 상태 확인
$ lspci -vvvs <BDF> | grep -i "lnksta\|lnkcap\|devsta\|devctl"

# 6. AER 에러 카운터 확인
$ cat /sys/bus/pci/devices/0000:<BDF>/aer_dev_correctable
$ cat /sys/bus/pci/devices/0000:<BDF>/aer_dev_fatal
$ cat /sys/bus/pci/devices/0000:<BDF>/aer_dev_nonfatal

# 7. 장치별 세부 진단
# GPU:
$ nvidia-smi -q -d ERRORS,TEMPERATURE,POWER
# NVMe:
$ nvme smart-log /dev/nvmeN
$ nvme error-log /dev/nvmeN
# NIC:
$ ethtool -S <interface> | grep -i "error\|drop\|crc"

# 8. PCIe topology와 NUMA 매핑 확인
$ lspci -tv
$ lstopo --of txt

Uncore MCA 에러 종합 분석

IIO 외에도 CPU의 Uncore 영역에는 여러 MCA 에러 소스가 존재합니다. Uncore는 CPU 코어 외부에 있지만 CPU 다이 내부에 통합된 공유 자원 — LLC(Last Level Cache), 메모리 컨트롤러, 메시 인터커넥트, 전력 관리 유닛 등 — 을 포함합니다. 데이터센터에서 발생하는 MCE의 상당 부분이 이 Uncore 영역에서 옵니다.

M2M (Mesh to Memory) 에러

M2M은 CPU 내부 메시 인터커넥트와 iMC(메모리 컨트롤러) 사이의 중개 역할을 합니다. 메모리 요청의 주소 디코딩, 인터리빙, 미러링, 스페어링 결정을 담당합니다. Bank 9~12(SKX 기준)에 매핑됩니다.

CHA (Caching Home Agent) / LLC 에러

CHA는 LLC(Last Level Cache) 슬라이스와 코히런스 디렉토리를 관리합니다. Bank 21~24+(코어 수에 따라 가변)에 매핑됩니다.

TOR (Table of Requests) 타임아웃

TOR 타임아웃은 CHA의 트랜잭션 큐에서 요청이 완료되지 못하고 타임아웃된 경우입니다. 이는 매우 심각한 상황으로, 거의 항상 시스템 패닉을 유발합니다.

UPI (Ultra Path Interconnect) 링크 에러

UPI는 멀티소켓 시스템에서 CPU 간 통신을 담당합니다. Bank 5~6(SKX 기준)에 매핑됩니다. 원격 메모리 접근(NUMA), 코히런스 프로토콜, 인터럽트 라우팅에 사용됩니다.

PCU (Power Control Unit) 에러

PCU는 CPU 전력 관리, 주파수 제어(P-state, C-state), 온도 모니터링을 담당합니다. Bank 4에 매핑됩니다. PCU 에러는 전력/열 관련 문제를 나타냅니다.

MDF (Mesh Data Fabric) — SPR 이후

Sapphire Rapids부터 도입된 MDF(Mesh Data Fabric)는 기존 CHA/메시의 데이터 패브릭을 별도 MCA 뱅크로 분리한 것입니다. 메시 내부의 데이터 전송 경로에서 발생하는 에러를 보고합니다.

Intel Cascade Lake 아키텍처 기준 MCA 뱅크 상세

Cascade Lake-SP(CLX)는 Xeon Scalable 2세대로, Skylake-SP(SKX)의 MCA 아키텍처를 기반으로 하되 RAS 기능이 크게 강화된 세대입니다. 현재도 데이터센터에서 널리 운용되고 있어, MCE 분석의 기준 아키텍처로 적합합니다. 이후 세대(ICX, SPR, EMR, GNR)와의 차이를 이해하는 데도 Cascade Lake를 기준으로 삼으면 효과적입니다.

Cascade Lake 고유 RAS 기능과 MCA 영향

Cascade Lake ADDDC 동작 상세

ADDDC(Adaptive Double DRAM Device Correction)는 CLX에서 도입된 핵심 RAS 기능으로, DIMM 내 단일 DRAM 칩(x4)의 완전 장애까지 교정할 수 있습니다. 기존 SDDC(Single Device Data Correction)의 확장입니다.

# ADDDC 상태 확인 (EDAC sysfs)
$ cat /sys/devices/system/edac/mc/mc0/dimm0/dimm_edac_mode
# 출력 예: "x4 SDDC" 또는 "x4 ADDDC"

# ADDDC Failover 이벤트 확인
$ dmesg | grep -i "adddc\|failover"
$ ras-mc-ctl --errors | grep -i "adddc"

# Cascade Lake에서 ADDDC 활성화 여부 (BIOS 설정)
# BIOS → Advanced → Memory Configuration → ADDDC Sparing: Enabled

Uncore 에러 간 연쇄(Cascade) 패턴

Uncore 에러는 종종 연쇄적으로 발생합니다. 하나의 근본 원인(root cause)이 여러 MCA 뱅크에서 동시다발적으로 에러를 보고하게 만듭니다. 연쇄 패턴을 이해하면 근본 원인을 더 빠르게 식별할 수 있습니다. 아래는 Cascade Lake 아키텍처를 기준으로 한 에러 전파 경로입니다.

연쇄 에러 근본 원인 분석 체크리스트

여러 MCA 뱅크에서 동시에 에러가 보고되면, 다음 절차로 근본 원인을 식별합니다.

1. 타임스탬프 정렬: dmesg -T 또는 rasdaemon DB에서 에러를 시간 순서로 정렬. 가장 이른 타임스탬프의 에러가 root cause 후보
2. OVER 비트 확인: MCi_STATUS.OVER=1인 뱅크는 정보 손실이 있으므로, 해당 뱅크가 실제 1차 에러 소스였을 가능성 높음
3. 뱅크 간 우선순위:
   • iMC(Bank 13~20) UC가 있으면 → DIMM이 근본 원인일 가능성 최우선
   • IIO(Bank 7~8) CTO가 있으면 → PCIe 장치가 근본 원인
   • UPI(Bank 5~6) UC가 있으면 → 소켓 간 링크 문제
   • CHA TOR Timeout만 있으면 → 2차 에러, 다른 뱅크에서 근본 원인 탐색
4. BERT 확인: 패닉 후 재부팅 시 dmesg | grep BERT로 이전 부팅의 에러 정보 수집. BERT에 1차 에러가 남아 있을 수 있음
5. BMC/IPMI SEL: ipmitool sel list에서 OS 레벨 로그와 교차 확인. 펌웨어가 OS보다 먼저 에러를 감지한 경우 있음
6. 동일 소켓/채널 집중: 에러가 특정 소켓, 특정 메모리 채널, 특정 PCIe 슬롯에 집중되면 해당 하드웨어 교체 고려

# 연쇄 에러 분석 스크립트 예시
# 모든 MCA 뱅크 에러를 타임스탬프순으로 정렬

$ dmesg -T | grep -i "mce\|hardware error\|machine check" | sort

# rasdaemon DB에서 최근 1시간 에러를 뱅크별로 그룹화
$ sqlite3 /var/lib/rasdaemon/ras-mc_event.db \
  "SELECT bank, error_type, COUNT(*), MIN(timestamp), MAX(timestamp)
   FROM mce_record
   WHERE timestamp > strftime('%s','now','-1 hour')
   GROUP BY bank ORDER BY MIN(timestamp);"

# BERT (Boot Error Record) 확인 — 패닉 후 재부팅 시
$ dmesg | grep -A 20 "BERT"

# IPMI SEL 로그와 교차 확인
$ ipmitool sel list | tail -20

LMCE (Local MCE)

전통적으로 MCE는 모든 논리 프로세서에 브로드캐스트됩니다. LMCE(Local Machine Check Exception)는 특정 CPU에만 영향을 미치는 에러를 해당 CPU에만 전달하여 불필요한 Monarch 랑데부를 피합니다.

LMCE 활성화 조건

1. MCG_CAP.MCG_LMCE_P = 1 — CPU가 LMCE를 지원
2. MCG_EXT_CTL.LMCE_EN = 1 — 소프트웨어가 LMCE를 활성화
3. IA32_FEATURE_CONTROL.LMCE_ON = 1 — 펌웨어가 LMCE를 허용

LMCE의 이점

/* arch/x86/kernel/cpu/mce/core.c */
static void mce_intel_feature_init(struct cpuinfo_x86 *c)
{
    u64 cap, feat;

    rdmsrl(MSR_IA32_MCG_CAP, cap);
    if (cap & MCG_LMCE_P) {
        rdmsrl(MSR_IA32_FEAT_CTL, feat);
        if (feat & FEAT_CTL_LMCE_ENABLED) {
            rdmsrl(MSR_IA32_MCG_EXT_CTL, cap);
            cap |= MCG_EXT_CTL_LMCE_EN;
            wrmsrl(MSR_IA32_MCG_EXT_CTL, cap);
        }
    }
}

/* LMCE 발생 여부 확인 */
static bool mce_is_lmce(struct mce *m)
{
    return m->mcgstatus & MCG_STATUS_LMCES;
}

LMCE 지원 CPU 목록

LMCE 판별 로직 상세

do_machine_check()에서 LMCE 여부에 따라 Monarch 랑데부를 건너뛰는 핵심 분기 로직입니다. MCG_STATUS의 LMCES(bit 3) 비트가 설정되어 있으면 해당 MCE는 로컬 전용이므로 다른 CPU와 동기화할 필요가 없습니다.

/* arch/x86/kernel/cpu/mce/core.c — do_machine_check() 내부 LMCE 분기 */
noinstr void do_machine_check(struct pt_regs *regs)
{
    struct mce m;
    int worst = 0, order, no_way_out = 0;
    bool lmce = false;

    /* 1단계: MCG_STATUS 읽기 */
    m.mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);

    /* 2단계: LMCE 여부 판별 — MCG_STATUS.LMCES (bit 3) */
    lmce = m.mcgstatus & MCG_STATUS_LMCES;

    /* 3단계: MCA 뱅크 순회 — 에러 정보 수집 */
    for (i = 0; i < this_cpu_read(mce_num_banks); i++) {
        m.status = mce_rdmsrl(mca_msr_reg(i, MCA_STATUS));
        if (!(m.status & MCI_STATUS_VAL))
            continue;
        /* severity 평가, worst 갱신 */
        worst = mce_severity(&m, regs, ...);
    }

    /* 4단계: LMCE면 랑데부 건너뛰기 */
    if (!lmce) {
        /* 브로드캐스트 MCE — Monarch 랑데부 진입 */
        order = mce_start(&no_way_out);
        /* ... 모든 CPU 동기화 후 Monarch 판정 ... */
        mce_end(order);
    } else {
        /* LMCE — 이 CPU만 로컬 처리 */
        /* 랑데부 불필요, 바로 에러 처리 진행 */
    }

    /* 5단계: 에러 로깅 및 액션 */
    mce_log(&m);

    if (worst >= MCE_PANIC_SEVERITY && !lmce)
        mce_panic("Fatal MCE", &m, msg);
    else if (worst >= MCE_AR_SEVERITY)
        kill_me_maybe(cb);  /* 프로세스 kill 또는 페이지 오프라인 */
}

MCE와 KVM 가상화

물리 서버에서 하드웨어 메모리 오류가 발생하면, 호스트 커널의 MCE 핸들러가 먼저 처리합니다. 해당 오류가 게스트 VM에 할당된 메모리 영역에 영향을 미치는 경우, KVM 하이퍼바이저는 게스트에도 MCE를 주입하여 게스트 OS가 적절히 대응할 수 있도록 합니다.

호스트→게스트 MCE 전파 흐름

VMEXIT와 #MC 인터셉트

Intel VT-x 및 AMD-V는 게스트 실행 중 #MC 예외가 발생하면 무조건 VMEXIT를 수행합니다. 호스트가 반드시 먼저 제어권을 확보하는 구조입니다.

KVM_X86_SET_MCE ioctl을 통한 게스트 MCE 주입

/* include/uapi/linux/kvm.h — MCE 주입 구조체 */
struct kvm_x86_mce {
    __u64 status;      /* MCi_STATUS 값 */
    __u64 addr;        /* MCi_ADDR 값 */
    __u64 misc;        /* MCi_MISC 값 */
    __u64 mcg_status;  /* MCG_STATUS 값 */
    __u8  bank;        /* MCA 뱅크 번호 */
    __u8  pad1[7];
    __u64 pad2[3];
};

/* QEMU에서의 MCE 주입 예시 */
struct kvm_x86_mce mce = {
    .status    = MCI_STATUS_VAL | MCI_STATUS_UC | MCI_STATUS_EN
               | MCI_STATUS_ADDRV | 0x0136,  /* SRAR: Data Load */
    .addr      = guest_phys_addr,
    .mcg_status = MCG_STATUS_MCIP | MCG_STATUS_EIPV,
    .bank      = 1,
};
ioctl(vcpu_fd, KVM_X86_SET_MCE, &mce);

HWPoison과 게스트 메모리 영향

호스트가 물리 페이지를 HWPoison으로 마킹하면, KVM은 GPA↔HPA 매핑을 추적하여 해당 게스트에 MCE를 주입합니다. 동시에 EPT/NPT 테이블에서 매핑을 제거합니다.

/* arch/x86/kvm/x86.c — MCE 브로드캐스트 및 주입 (개념 코드) */
void kvm_mce_broadcast(struct kvm *kvm, unsigned long pfn)
{
    struct kvm_vcpu *vcpu;
    gfn_t gfn = kvm_pfn_to_gfn(pfn);

    kvm_for_each_vcpu(i, vcpu, kvm) {
        struct kvm_x86_mce mce = {
            .status = MCI_STATUS_VAL | MCI_STATUS_UC | 0x0136,
            .addr   = gfn << PAGE_SHIFT,
            .bank   = 1,
        };
        /* LMCE 지원 시 오류 소유 vCPU에만 주입 */
        if (kvm_vcpu_supports_lmce(vcpu) && kvm_vcpu_owns_gfn(vcpu, gfn)) {
            mce.mcg_status |= MCG_STATUS_LMCE_S;
            kvm_inject_mce(vcpu, &mce);
            break;
        }
        kvm_inject_mce(vcpu, &mce); /* LMCE 미지원: 브로드캐스트 */
    }
}

라이브 마이그레이션과 MCE/HWPoison

APEI/GHES 통합

APEI(ACPI Platform Error Interface)는 플랫폼 펌웨어와 OS 간의 표준 에러 보고 인터페이스입니다. 서버 플랫폼에서는 펌웨어가 먼저 에러를 수집하고(Firmware-First), GHES(Generic Hardware Error Source)를 통해 OS에 전달하는 방식이 일반적입니다.

APEI 테이블 구성요소

CPER (Common Platform Error Record)

GHES가 전달하는 에러 데이터는 CPER 포맷을 따릅니다. 각 에러 레코드에는 하나 이상의 Section이 포함되며, 섹션 타입별로 메모리 에러, PCIe 에러, 프로세서 에러 등을 구분합니다.

/* drivers/acpi/apei/ghes.c — GHES 처리 */
static int ghes_proc(struct ghes *ghes)
{
    struct acpi_hest_generic_status *estatus;

    estatus = ghes->estatus;
    ghes_copy_tofrom_phys(estatus, ghes->buffer_paddr, ...);

    /* CPER 섹션 순회 */
    apei_estatus_for_each_section(estatus, gdata) {
        guid_t *sec_type = (guid_t *)gdata->section_type;

        if (guid_equal(sec_type, &CPER_SEC_PLATFORM_MEM)) {
            /* 메모리 에러 → memory_failure() */
            ghes_handle_memory_failure(gdata, sev);
        } else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
            /* PCIe 에러 */
            ghes_handle_aer(gdata);
        }
    }
}

GHES 통지 방법

GHES는 에러를 OS에 알리는 여러 통지 메커니즘을 지원합니다. 통지 방법은 HEST 테이블에 정의되며, 에러 심각도에 따라 다른 경로를 사용합니다.

BERT (Boot Error Record Table)

이전 부팅에서 치명적 에러로 시스템이 리셋된 경우, 펌웨어는 에러 정보를 BERT 영역에 저장합니다. 다음 부팅 시 커널이 BERT를 읽어 이전 에러를 dmesg에 출력합니다.

# BERT 데이터 확인
$ dmesg | grep BERT
[    0.123456] BERT: Error records from previous boot:
[    0.123457] [Firmware Error]: Hardware error from APEI Generic Hardware Error Source: 0
[    0.123458] severity: fatal

# BERT ACPI 테이블 덤프 (디버그)
$ sudo cat /sys/firmware/acpi/tables/BERT | hexdump -C | head

ERST (Error Record Serialization Table)

ERST는 에러 레코드를 비휘발성 저장소(플래시, NVRAM)에 영속적으로 저장하는 인터페이스입니다. 커널은 /sys/firmware/acpi/tables/ERST를 통해 에러 레코드를 쓰고 읽을 수 있습니다. 이는 crash dump와 함께 사후 분석에 활용됩니다.

CPER 메모리 에러 섹션 구조

GHES가 전달하는 메모리 에러는 UEFI 표준의 CPER Memory Error Section (CPER_SEC_PLATFORM_MEM) 포맷을 따릅니다. 각 필드에는 Validation Bits가 있어 해당 필드가 유효한지를 나타냅니다.

/* drivers/acpi/apei/ghes.c — CPER 메모리 섹션 처리 */
static void ghes_handle_memory_failure(
    struct acpi_hest_generic_data *gdata, int sev)
{
    struct cper_sec_mem_err *mem_err;
    unsigned long pfn;

    mem_err = acpi_hest_get_payload(gdata);

    /* Validation Bits 확인: 물리 주소 유효한지 */
    if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
        return;

    /* Physical Address to PFN 변환 */
    pfn = mem_err->physical_addr >> PAGE_SHIFT;

    /* Physical Address Mask 적용 (유효 범위 계산) */
    if (mem_err->validation_bits & CPER_MEM_VALID_PA_MASK)
        pfn &= ~(mem_err->physical_addr_mask >> PAGE_SHIFT);

    /* severity에 따라 분기 */
    if (sev == GHES_SEV_RECOVERABLE) {
        /* Action Required: 즉시 memory_failure() */
        memory_failure_queue(pfn, MF_ACTION_REQUIRED);
    } else {
        /* Corrected: soft offline (예방적 페이지 격리) */
        memory_failure_queue(pfn, 0);
    }

    /* 트레이스 이벤트 발생 — rasdaemon/mcelog 수집용 */
    trace_mc_event(err_type, ...,
        mem_err->node, mem_err->card, mem_err->module,
        mem_err->bank, mem_err->device,
        mem_err->row, mem_err->column, ...);
}

GHES 에러 심각도 매핑

GHES의 에러 심각도(CPER Error Severity)는 커널 내부의 MCE severity 수준으로 매핑됩니다. 이 매핑은 에러 처리 액션(패닉, 프로세스 kill, 로깅 등)을 결정합니다.

Firmware-First vs OS-First 선택 기준

에러 처리의 주체를 펌웨어(Firmware-First)와 OS(OS-First) 중 어디로 설정할지는 플랫폼 유형과 운영 환경에 따라 달라집니다. 다음 표는 실무 기준의 선택 가이드입니다.

EDAC 서브시스템 연동

EDAC(Error Detection And Correction)은 ECC 메모리 에러를 추적하고 물리적 DIMM 위치까지 디코딩하는 리눅스 커널 서브시스템입니다. MCE 또는 GHES로부터 에러 통지를 받아 어떤 DIMM의 어떤 행/열에서 에러가 발생했는지 알려줍니다.

주요 EDAC 드라이버

/* drivers/edac/edac_mc.c */
void edac_mc_handle_error(
    const enum hw_event_mc_err_type type,
    struct mem_ctl_info *mci,
    const u16 error_count,
    const unsigned long page_frame_number,
    const unsigned long offset_in_page,
    const unsigned long syndrome,
    const int top_layer,      /* 채널 */
    const int mid_layer,      /* DIMM */
    const int low_layer,      /* 행/열 */
    const char *msg,
    const char *other_detail)
{
    /* EDAC 에러 카운터 증가 + tracepoint + sysfs 업데이트 */
    trace_mc_event(type, msg, label, error_count, ...);
    edac_inc_ce_error(mci, enable_per_layer_report, pos);
}

EDAC sysfs 인터페이스 상세

EDAC은 /sys/devices/system/edac/ 아래에 계층적 sysfs 인터페이스를 제공합니다. 메모리 컨트롤러(mc), 칩셋 검증(pci), 에러 카운터 등을 확인할 수 있습니다.

# EDAC 메모리 컨트롤러 계층
/sys/devices/system/edac/mc/
├── mc0/                          # 메모리 컨트롤러 0
│   ├── ce_count                  # 총 CE 횟수
│   ├── ue_count                  # 총 UE 횟수
│   ├── ce_noinfo_count           # 위치 정보 없는 CE
│   ├── ue_noinfo_count           # 위치 정보 없는 UE
│   ├── seconds_since_reset       # 카운터 리셋 후 경과 시간
│   ├── mc_name                   # 드라이버 이름 (예: "skx_edac")
│   ├── size_mb                   # 총 메모리 크기
│   ├── dimm0/                    # DIMM 0
│   │   ├── dimm_ce_count         # 이 DIMM의 CE 횟수
│   │   ├── dimm_dev_type         # DDR4, DDR5 등
│   │   ├── dimm_edac_mode        # SECDED, Chipkill 등
│   │   ├── dimm_label            # DIMM 물리 위치 레이블
│   │   ├── dimm_location         # 채널/슬롯/랭크
│   │   └── dimm_mem_type         # Registered, Unbuffered
│   └── csrow0/                   # 칩-셀렉트 행 0
│       ├── ch0_ce_count          # 채널 0의 CE
│       └── ch1_ce_count          # 채널 1의 CE

EDAC 주소 디코딩 알고리즘

MCE/GHES로부터 전달받은 물리 주소를 실제 DIMM 위치로 변환하는 과정은 플랫폼마다 다릅니다. 주소 인터리빙, 채널 해싱, 랭크 인터리빙 등 메모리 컨트롤러 설정에 따라 동일한 물리 주소라도 다른 DIMM에 매핑될 수 있습니다.

/* Intel ADXL 기반 디코딩 — drivers/edac/skx_common.c */
static int skx_adxl_decode(struct decoded_addr *res, bool error_in_1st_level_mem)
{
    struct skx_dev *d;
    int i, len = 0;

    /* ADXL 라이브러리에 물리 주소 전달 → 디코드 테이블 참조 */
    if (adxl_decode(res->addr, adxl_values)) {
        edac_dbg(0, "Failed to decode addr 0x%llx\n", res->addr);
        return -EINVAL;
    }

    /* 디코드 결과에서 소켓/IMC/채널/DIMM/랭크 추출 */
    res->socket  = (int)adxl_values[adxl_component_indices[INDEX_SOCKET]];
    res->imc     = (int)adxl_values[adxl_component_indices[INDEX_MEMCTRL]];
    res->channel = (int)adxl_values[adxl_component_indices[INDEX_CHANNEL]];
    res->dimm    = (int)adxl_values[adxl_component_indices[INDEX_DIMM]];
    res->rank    = (int)adxl_values[adxl_component_indices[INDEX_RANK]];

    /* mem_ctl_info에서 해당 컨트롤러/DIMM 구조체 검색 */
    if (skx_adxl_get_mci(res))
        return -ENODEV;

    return 0;
}

/* AMD UMC 기반 디코딩 — drivers/edac/amd64_edac.c */
static int umc_normaddr_to_sysaddr(u64 norm_addr, u16 nid,
                                     u8 umc, u64 *sys_addr)
{
    /* UMC 정규화 주소 → 시스템 물리 주소 변환 */
    /* Data Fabric interleave 비트, NPS 모드, CS base/mask 참조 */
    get_df_interleave(nid, umc, &intlv_num_chan, &intlv_addr_sel);
    /* ... */
}

EDAC과 rasdaemon 연동

rasdaemon은 커널 EDAC 서브시스템이 발생시키는 ras:mc_event tracepoint를 구독하여 메모리 에러를 SQLite 데이터베이스에 기록합니다. 이를 통해 장기적인 DIMM 건강 추이 분석과 사전 교체 판단이 가능합니다.

# rasdaemon 설치 및 서비스 시작
$ sudo apt install rasdaemon          # Debian/Ubuntu
$ sudo dnf install rasdaemon          # RHEL/Fedora
$ sudo systemctl enable --now rasdaemon

# rasdaemon이 trace event를 수신하는지 확인
$ sudo cat /sys/kernel/tracing/events/ras/mc_event/enable
1

# SQLite DB 위치 확인
$ ls -la /var/lib/rasdaemon/ras-mc_event.db

DIMM 건강 분석 SQL 쿼리: rasdaemon의 SQLite DB를 직접 쿼리하면 EDAC sysfs보다 훨씬 풍부한 시계열 분석이 가능합니다.

-- 최근 7일간 DIMM별 CE 추이
SELECT
    date(timestamp, 'unixepoch') AS day,
    mc, top_layer AS channel, mid_layer AS dimm,
    COUNT(*) AS ce_count
FROM mc_event
WHERE err_type = 'Corrected'
  AND timestamp > strftime('%s', 'now', '-7 days')
GROUP BY day, mc, channel, dimm
ORDER BY day, ce_count DESC;

-- 에러가 가장 많은 상위 5개 DIMM
SELECT
    mc, top_layer AS channel, mid_layer AS dimm,
    SUM(CASE WHEN err_type = 'Corrected' THEN error_count ELSE 0 END) AS total_ce,
    SUM(CASE WHEN err_type = 'Uncorrected' THEN error_count ELSE 0 END) AS total_ue,
    MIN(datetime(timestamp, 'unixepoch')) AS first_error,
    MAX(datetime(timestamp, 'unixepoch')) AS last_error
FROM mc_event
GROUP BY mc, channel, dimm
ORDER BY total_ce + total_ue * 1000 DESC
LIMIT 5;

-- CE → UE 에스컬레이션 탐지: CE 급증 후 UE 발생한 DIMM
SELECT ue.mc, ue.top_layer AS channel, ue.mid_layer AS dimm,
    ce_before.ce_count AS ce_before_ue,
    datetime(ue.timestamp, 'unixepoch') AS ue_time
FROM mc_event ue
JOIN (
    SELECT mc, top_layer, mid_layer, COUNT(*) AS ce_count,
           MAX(timestamp) AS last_ce
    FROM mc_event
    WHERE err_type = 'Corrected'
    GROUP BY mc, top_layer, mid_layer
) ce_before ON ue.mc = ce_before.mc
    AND ue.top_layer = ce_before.top_layer
    AND ue.mid_layer = ce_before.mid_layer
WHERE ue.err_type = 'Uncorrected'
    AND ce_before.ce_count > 10
ORDER BY ce_before.ce_count DESC;

RAS 유저스페이스 도구

MCE 이벤트를 수집, 디코딩, 분석하는 유저스페이스 도구입니다. mcelog은 레거시이고, 현재는 rasdaemon이 표준입니다.

도구 비교

rasdaemon 설정 및 사용

# 설치 (RHEL/CentOS)
$ sudo yum install rasdaemon

# 서비스 시작
$ sudo systemctl enable --now rasdaemon

# 에러 요약 조회
$ sudo ras-mc-ctl --summary
Memory controller events summary:
        Corrected on DIMM Label(s): CPU_SrcID#0_MC#0_Chan#0_DIMM#0 location: 0:0:0:-1 errors: 42
        No Uncorrected errors.

# SQLite DB 직접 조회
$ sudo sqlite3 /var/lib/rasdaemon/ras-mc_event.db \
  "SELECT timestamp, err_type, mc, top_layer, mid_layer, msg FROM mc_event ORDER BY id DESC LIMIT 10;"

# MCE 이벤트 조회
$ sudo ras-mc-ctl --errors
$ sudo sqlite3 /var/lib/rasdaemon/ras-mc_event.db \
  "SELECT timestamp, mcgstatus, status, addr, bank FROM mce_record ORDER BY id DESC LIMIT 5;"

rasdaemon 아키텍처

rasdaemon은 커널의 perf_event tracepoint를 구독하여 에러 이벤트를 수집합니다. ras:mc_event, ras:aer_event, ras:mce_record, ras:cxl_poison 등의 tracepoint를 모니터링하며, 수집된 데이터를 SQLite 데이터베이스에 저장합니다.

# rasdaemon이 구독하는 tracepoint 확인
$ sudo ls /sys/kernel/debug/tracing/events/ras/
aer_event      cxl_general_media  cxl_poison       mc_event
arm_event      cxl_memory_module  extlog_mem_event mce_record
cxl_dram       cxl_overflow       non_standard_event

# 실시간 트레이스 확인 (디버그 용)
$ sudo cat /sys/kernel/debug/tracing/events/ras/mc_event/enable
1
$ sudo cat /sys/kernel/debug/tracing/trace_pipe | grep mc_event

rasdaemon vs mcelog 마이그레이션

기존 mcelog 사용 환경에서 rasdaemon으로 전환할 때 주의할 점:

• /dev/mcelog 인터페이스는 커널 6.x에서 제거 추세 — mcelog 사용 불가해질 수 있음
• rasdaemon은 모든 RAS 소스(MCE/EDAC/AER/CXL/ARM)를 통합 관리
• SQLite 기반이므로 SQL 쿼리로 유연한 분석 가능
• ABRT(Automatic Bug Reporting Tool)와 연동하여 자동 리포팅 가능

# mcelog → rasdaemon 전환
$ sudo systemctl stop mcelog
$ sudo systemctl disable mcelog
$ sudo systemctl enable --now rasdaemon

# 이전 mcelog 데이터는 수동 마이그레이션 필요
# rasdaemon은 tracepoint 기반이므로 /dev/mcelog 비사용

CXL 메모리 에러와 MCE

CXL(Compute Express Link) 메모리 장치는 기존 DRAM과는 다른 에러 보고 경로를 사용합니다. CXL 프로토콜 에러는 PCIe AER 또는 GHES를 통해 보고되며, 궁극적으로 memory_failure()로 이어집니다.

CXL 에러 경로

/* drivers/cxl/core/mbox.c — Poison List 조회 */
int cxl_mem_get_poison(struct cxl_memdev *cxlmd,
                       u64 offset, u64 len,
                       struct cxl_region *cxlr)
{
    struct cxl_mbox_poison_out *po;
    int rc;

    rc = cxl_internal_send_cmd(mds, &mbox_cmd);
    if (rc)
        return rc;

    /* Poison 리스트 엔트리 순회 */
    for (i = 0; i < le16_to_cpu(po->count); i++) {
        trace_cxl_poison(cxlmd, cxlr, &po->record[i],
                         po->flags, po->overflow_ts, CXL_POISON_TRACE_LIST);
    }
    return 0;
}

GPU/가속기 MCE 연쇄 에러 분석

현대 데이터센터와 AI/ML 학습 클러스터에서 GPU 및 하드웨어 가속기에서 발생하는 하드웨어 에러(ECC 오류, DMA 장애 등)는 PCIe AER을 거쳐 CPU의 IIO MCA 뱅크에 기록되고, 최종적으로 MCE로 전파됩니다. 이 연쇄 과정을 정확히 이해해야 장애 원인을 신속하게 격리할 수 있습니다.

GPU 에러 연쇄 전파 경로

Xid 에러 코드와 MCE 상관관계

GPU Xid와 MCE 뱅크/IIO 스택 상관분석

# GPU의 PCIe 위치 확인
$ lspci -d 10de: -vvs 41:00.0
41:00.0 3D controller: NVIDIA Corporation A100
    UESta:  0x00004000  # ← Completion Abort 비트

# MCE 로그에서 Bank 번호 → IIO 스택 역추적
# Bank 6 = IIO Stack 1 (Skylake-SP 기준)
mce: [Hardware Error]: CPU 24 Bank 6:
  STATUS 0xbc20000001000136
  # MSCOD=0x0136: Received Parity Error
  # UC=1, PCC=1 → 프로세서 컨텍스트 손상

# GPU ECC 상태 확인
$ nvidia-smi --query-gpu=ecc.errors.corrected.volatile.total,\
ecc.errors.uncorrected.volatile.total,retired_pages.count --format=csv

GPU 관련 MCE 패턴 종합표

AI/ML 학습 클러스터 MCE 영향

/* 분산 학습 중 단일 GPU ECC UE 발생 시 타임라인 */
T+0ms    GPU 3의 HBM에서 DBE(Double Bit Error) 발생
T+0.1ms  NVIDIA 드라이버 Xid 48 기록
T+0.5ms  PCIe AER Uncorrectable Error 전파
T+1ms    IIO MCA Bank 7에 기록 → MCE 핸들러 호출
T+2ms    memory_failure() 호출 — 오염 페이지 오프라인
T+100ms  GPU CUDA 컨텍스트 무효화
T+200ms  PyTorch/NCCL: Rank 3 통신 실패 감지
T+30s    NCCL timeout → 전체 AllReduce 데드락
T+60s    모든 Rank 학습 중단 → 마지막 체크포인트로 롤백 필요

// 영향: 8-GPU 노드 1대의 GPU 1개 장애
//       → 전체 클러스터 학습 중단

클러스터 운영 권장사항

• 사전 모니터링: rasdaemon과 nvidia-smi 연동, CE 급증 시 자동 노드 드레인
• 체크포인트 전략: CE 급증 시 체크포인트 주기 단축
• tolerant 설정: tolerant=1로 복구 가능 MCE 패닉 방지
• GPU 헬스체크: dcgmi diag -r 3(NVIDIA DCGM)으로 주기적 GPU 진단
• NUMA/IIO 인지 배치: GPU와 동일 소켓/IIO 스택의 DIMM CE 감시 → NUMA 토폴로지 기반 장애 격리

아키텍처별 하드웨어 에러 처리 비교

MCE는 x86 고유 개념이지만, ARM, RISC-V, POWER 등 모든 서버급 아키텍처에 유사한 하드웨어 에러 보고 메커니즘이 있습니다. 각 아키텍처의 에러 감지/보고/복구 설계를 비교하면 하드웨어 RAS(Reliability, Availability, Serviceability)의 본질적인 문제와 해결 패턴을 더 깊이 이해할 수 있습니다.

ARM RAS Extension 상세

/* arch/arm64/mm/fault.c — SEA 처리 */
static int do_sea(unsigned long far, unsigned long esr,
                  struct pt_regs *regs)
{
    /* GHES SEA handler에 먼저 전달 */
    if (ghes_notify_sea() >= 0)
        return 0;  /* GHES가 처리 완료 */

    /* GHES가 처리하지 못하면 프로세스 킬 */
    arm64_notify_die("Synchronous External Abort", regs, esr);
    return 0;
}

ARM RAS Extension v1 레지스터

ARM RAS Extension v1은 x86 MCA 뱅크와 유사한 에러 레코드 레지스터를 정의합니다. 각 에러 노드(Error Record)는 ERRn 접두사를 가진 시스템 레지스터 세트로 구성됩니다.

RISC-V 하드웨어 에러 표준화 현황

RISC-V는 아직 하드웨어 에러 보고에 대한 공식 표준이 확립되지 않았습니다. 현재 진행 중인 표준화 작업과 벤더 독자 구현이 혼재합니다:

• SBI MPXY (Message Proxy Extension) — 펌웨어-OS 간 에러 메시지 전달
• SiFive S76 — BEU(Bus Error Unit) + 커스텀 인터럽트
• T-Head C910 — 플랫폼 고유 CSR 기반 에러 보고
• UEFI 서버 — ACPI GHES 경유 (x86과 동일한 최종 경로)

IBM POWER EEH (Enhanced Error Handling) 상세

IBM POWER 아키텍처는 PCI I/O 에러 처리를 위해 EEH(Enhanced Error Handling)를 제공합니다. x86의 AER과 유사한 역할이지만, 하이퍼바이저 계층을 통한 격리와 자동화된 단계적 복구에 초점을 맞춥니다.

EEH 동작 메커니즘

1. 에러 감지: PHB(PCI Host Bridge)가 PCI/PCIe 버스 에러를 감지
2. PE 격리: 에러 발생 PE(Partitionable Endpoint)를 즉시 I/O 격리(frozen) 상태로 전환. MMIO 읽기는 모두 0xFF 반환
3. OPAL 통지: 하이퍼바이저가 OS에 EEH 이벤트 전달
4. 단계적 복구: I/O 재시도 → 슬롯 리셋 → PHB 리셋 → 실패 시 PE 영구 비활성화 (최대 5회)

/* arch/powerpc/kernel/eeh_driver.c — EEH 복구 콜백 */
static int eeh_report_error(struct eeh_dev *edev, struct eeh_pe *pe)
{
    struct pci_driver *drv = eeh_pcid_get(edev->pdev);
    if (!drv || !drv->err_handler || !drv->err_handler->error_detected)
        return PCI_ERS_RESULT_NONE;
    /* 드라이버에 에러 통지 — 복구 가능 여부 응답 */
    return drv->err_handler->error_detected(edev->pdev, edev->state);
}

POWER vs x86 vs ARM 에러 처리 비교

ARM RAS Extension v1/v1.1

ARMv8.2-A에서 도입된 FEAT_RAS(RAS Extension v1)는 하드웨어 에러 감지와 보고를 표준화한 것으로, x86 MCA에 대응하는 ARM의 공식 RAS 프레임워크입니다. ARMv8.4-A에서 FEAT_RASv1p1(v1.1)으로 강화되었습니다.

ARM FEAT_RAS vs FEAT_RASv1p1 차이

ARM Neoverse 플랫폼별 RAS 구현

ARM Neoverse는 서버/인프라용 CPU IP로, 세대별로 RAS 기능이 다릅니다. AWS Graviton, Ampere Altra, Microsoft Cobalt 등 클라우드 서버에 사용됩니다.

ARM CMN (Coherent Mesh Network) 에러

ARM 서버 SoC의 인터커넥트인 CMN-600/CMN-700은 x86의 Mesh/CHA에 대응합니다. CMN 에러는 별도의 에러 노드를 통해 보고되며, GHES 경로로 OS에 전달됩니다.

Intel vs AMD MCA 아키텍처 차이 종합

x86 내에서도 Intel과 AMD는 MCA 구현에 상당한 차이가 있습니다. 같은 "MCA"라도 뱅크 식별 방식, 에러 분류, 복구 메커니즘, 레지스터 확장이 다릅니다.

크로스 아키텍처 에러 처리 종합 비교

x86(Intel/AMD), ARM, RISC-V, POWER를 포괄하는 종합 비교표입니다. 서버 플랫폼을 설계하거나 다중 아키텍처 환경을 운영할 때 참고합니다.

IBM POWER의 EEH (Enhanced Error Handling)

IBM POWER 아키텍처의 EEH는 PCIe 에러 처리에서 x86 AER/IIO MCA보다 진보된 모델입니다. x86에서는 PCIe UC 에러 시 장치가 사실상 죽지만, POWER EEH는 자동 복구 단계를 제공합니다.

RISC-V 하드웨어 에러 표준화 현황

RISC-V는 아직 하드웨어 에러 보고에 대한 공식 표준이 확립되지 않았습니다. 현재 진행 중인 표준화 작업과 벤더 독자 구현이 혼재합니다:

• SBI MPXY (Message Proxy Extension) — 펌웨어-OS 간 에러 메시지 전달
• SiFive S76 — BEU(Bus Error Unit) + 커스텀 인터럽트
• T-Head C910 — 플랫폼 고유 CSR 기반 에러 보고
• UEFI 서버 — ACPI GHES 경유 (x86과 동일한 최종 경로)
• Sscofpmf — 성능 카운터 오버플로 확장 (에러 카운팅에 활용 가능)
• Smcdeleg — 카운터 위임 확장 (에러 모니터링 위임)

MCE 테스트 주입

MCE 처리 경로의 정확성을 검증하려면 하드웨어 에러를 시뮬레이션해야 합니다. 리눅스 커널은 여러 단계의 주입 메커니즘을 제공합니다.

주입 방법 비교

mce-inject 사용법

# mce-inject 모듈 로드
$ sudo modprobe mce-inject

# 주입 파일 작성 (SRAO 메모리 에러)
$ cat > /tmp/mce-test.txt <<EOF
CPU 0 BANK 9
STATUS 0xBD2000000000017A
ADDR 0x12345678
MISC 0x0000000000000086
MCGSTATUS 0x0
EOF

# 주입 실행
$ sudo sh -c "cat /tmp/mce-test.txt > /sys/kernel/debug/mce-inject/mce-inject"

# dmesg 확인
$ dmesg | tail -20

EINJ (Error Injection) 사용법

# EINJ 모듈 로드
$ sudo modprobe einj

# 지원되는 에러 유형 확인
$ cat /sys/kernel/debug/apei/einj/available_error_type
0x00000002    Memory Correctable
0x00000008    Memory Uncorrectable non-fatal
0x00000010    Memory Uncorrectable fatal

# CE 주입 (특정 물리 주소)
$ sudo sh -c "echo 0x2 > /sys/kernel/debug/apei/einj/error_type"
$ sudo sh -c "echo 0x100000000 > /sys/kernel/debug/apei/einj/param1"   # 물리 주소
$ sudo sh -c "echo 0xFFFFFFFFFFFFF000 > /sys/kernel/debug/apei/einj/param2"  # 마스크
$ sudo sh -c "echo 1 > /sys/kernel/debug/apei/einj/error_inject"

hwpoison-inject 사용법

# 특정 PFN에 HWPoison 주입
$ sudo sh -c "echo 0x12345 > /sys/kernel/debug/hwpoison/corrupt-pfn"

# soft offline (CE 예방)
$ sudo sh -c "echo 0x12345 > /sys/kernel/debug/hwpoison/soft-offline-pfn"

# HWPoison 해제
$ sudo sh -c "echo 0x12345 > /sys/kernel/debug/hwpoison/unpoison-pfn"

MCE 테스트 시나리오 매트릭스

가상 머신에서의 MCE 테스트

QEMU/KVM에서 MCE를 주입하여 게스트 커널의 MCE 핸들링을 테스트할 수 있습니다.

# QEMU 모니터에서 게스트에 MCE 주입
(qemu) mce 0 9 0xBD2000000000017A 0x12345678 0x86

# 파라미터: CPU BANK STATUS ADDR MISC
# CPU 0, Bank 9, STATUS = SRAO 메모리 에러

# KVM에서 ioctl로 프로그래밍 주입
# KVM_X86_SET_MCE ioctl → struct kvm_x86_mce

MCE 디버깅 기법 (perf/ftrace/eBPF)

MCE 이벤트는 하드웨어 오류의 핵심 진단 정보를 담고 있지만, 발생 빈도가 낮고 재현이 어려워 체계적인 디버깅 도구 활용이 필수적입니다. 리눅스 커널은 perf, ftrace, eBPF 등 다양한 트레이싱 프레임워크를 통해 MCE 이벤트를 실시간 모니터링하고 분석할 수 있는 인프라를 제공합니다.

perf를 이용한 MCE 이벤트 추적

# MCE 관련 트레이스포인트 확인
$ perf list 'ras:*'

# MCE 이벤트 실시간 기록
$ perf record -e ras:mce_record -a --overwrite -o mce_trace.data

# 기록된 MCE 이벤트 상세 출력
$ perf script -i mce_trace.data

# EDAC/AER 이벤트도 함께 추적
$ perf record -e ras:mce_record -e ras:mc_event -e ras:aer_event -a -o ras_all.data

ftrace를 이용한 MCE 핸들러 추적

# function_graph 트레이서로 MCE 핸들러 추적
$ cd /sys/kernel/debug/tracing
$ echo 0 > tracing_on
$ echo function_graph > current_tracer
$ echo do_machine_check > set_graph_function
$ echo 1 > tracing_on

# MCE 관련 함수만 필터링
$ echo do_machine_check > set_ftrace_filter
$ echo mce_severity >> set_ftrace_filter
$ echo mce_reign >> set_ftrace_filter

# 트레이스포인트 직접 활성화
$ echo 1 > events/ras/mce_record/enable

eBPF/bpftrace를 이용한 MCE 모니터링

# MCE 이벤트 발생 시 뱅크 번호와 상태 출력
$ bpftrace -e '
tracepoint:ras:mce_record {
    printf("MCE: cpu=%d bank=%d status=0x%llx addr=0x%llx\n",
           args->cpu, args->bank, args->status, args->addr);
}'

# MCE 뱅크별 발생 횟수 집계
$ bpftrace -e '
tracepoint:ras:mce_record {
    @mce_by_bank[args->bank] = count();
    @mce_by_cpu[args->cpu] = count();
}'

# 물리 주소 기반 반복 오류 감지
$ bpftrace -e '
tracepoint:ras:mce_record {
    @addr_count[args->addr] = count();
    if (@addr_count[args->addr] >= 3) {
        printf("WARNING: 반복 MCE at addr=0x%llx (count=%d)\n",
               args->addr, @addr_count[args->addr]);
    }
}'

# do_machine_check() 실행 시간 측정
$ bpftrace -e '
kprobe:do_machine_check { @start[tid] = nsecs; }
kretprobe:do_machine_check /@start[tid]/ {
    @mce_latency_us = hist((nsecs - @start[tid]) / 1000);
    delete(@start[tid]);
}'

크래시 덤프 분석 (kdump + crash)

치명적 MCE로 인한 커널 패닉 이후에는 kdump가 캡처한 메모리 덤프를 crash 유틸리티로 분석합니다.

# crash 유틸리티로 덤프 분석
$ crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/<timestamp>/vmcore

# crash 프롬프트에서 MCE 정보 조회
crash> log | grep -i "mce\|machine check"
crash> bt -a              # 모든 CPU 백트레이스
crash> struct mce mcelog.entry[0]
crash> px mcelog.entry[0].status
crash> px mcelog.entry[0].addr

MCE 이벤트 상관 분석

# 타임스탬프 기반 통합 분석
$ journalctl --since "2 hours ago" -k | \
  grep -iE "mce|edac|aer|ghes|hardware.error" | \
  sort -k1,3 | tee /tmp/hw_error_timeline.log

# rasdaemon DB에서 시간 범위 기반 교차 조회
$ sqlite3 /var/lib/rasdaemon/ras-mc_event.db "
  SELECT 'MCE' as type, timestamp, error_msg FROM mce_record
  WHERE timestamp > datetime('now', '-2 hours')
  UNION ALL
  SELECT 'MC' as type, timestamp, error_msg FROM mc_event
  WHERE timestamp > datetime('now', '-2 hours')
  UNION ALL
  SELECT 'AER' as type, timestamp, error_msg FROM aer_event
  WHERE timestamp > datetime('now', '-2 hours')
  ORDER BY timestamp;"

커널 설정 옵션

MCE/RAS 관련 커널 설정 옵션의 종합 목록입니다. 프로덕션 서버에서는 대부분 활성화하는 것이 권장됩니다.

MCE 로그 디코딩 실전

실제 MCE 로그를 단계별로 해석하는 실전 가이드입니다. dmesg에 출력되는 MCE 메시지의 각 필드가 무엇을 의미하는지 분석합니다.

STATUS 디코딩 단계별 안내

예시: STATUS = 0xBE00000000800400

# 64비트 이진 분해
0xBE00000000800400 =
  1  0  1  1  1  1  1  0  0000...  1000 0000 0000 0100 0000 0000
  63 62 61 60 59 58 57 56          [31:16]   [15:0] = 0x0400

# 상위 비트 해석
bit 63 (VAL)   = 1 → 유효한 에러
bit 62 (OVER)  = 0 → 오버플로 없음
bit 61 (UC)    = 1 → 교정 불가 (Uncorrected)
bit 60 (EN)    = 1 → 에러 보고 활성
bit 59 (MISCV) = 1 → MISC 레지스터 유효
bit 58 (ADDRV) = 1 → ADDR 레지스터 유효
bit 57 (PCC)   = 1 → 프로세서 컨텍스트 손상!
bit 56 (S)     = 0 → MCG_SER_P 미지원 또는 비활성

# 에러 코드 (bits 15:0) = 0x0400
0x0400 = 0000 0100 0000 0000
→ Internal Timer Error (Simple Error Code)

# 결론: UC + PCC → 프로세서 상태 복구 불가 → 시스템 패닉

유용한 디코딩 도구

# mcelog으로 디코딩 (레거시)
$ sudo mcelog --ascii --file /tmp/mce.log

# rasdaemon SQLite 쿼리
$ sudo sqlite3 /var/lib/rasdaemon/ras-mc_event.db \
  "SELECT datetime(timestamp,'unixepoch'), bank, status, addr,
          CASE WHEN (status >> 61) & 1 THEN 'UC' ELSE 'CE' END as type
   FROM mce_record ORDER BY id DESC LIMIT 10;"

# edac-util로 DIMM 매핑 확인
$ edac-util -s
$ edac-util -r

CE (Corrected Error) 로그 예제

# EDAC CE 로그 예시
[54321.987] EDAC MC0: 1 CE memory read error on CPU_SrcID#0_MC#0_Chan#0_DIMM#0
            (channel:0 slot:0 page:0x1234 offset:0x0 grain:32 syndrome:0x0)
[54321.987] EDAC MC0: 1 CE ... area:DRAM err_code:0001:0091

# 해석:
# - MC0: 메모리 컨트롤러 0
# - 1 CE: Corrected Error 1회
# - Channel 0, Slot 0: 첫 번째 채널의 첫 번째 DIMM
# - page:0x1234: 물리 페이지 프레임 번호
# - grain:32: 에러 입도 (바이트)
# - err_code:0001:0091: 계층/에러 코드

SRAR (Action Required) 로그 예제

[98765.432] mce: [Hardware Error]: CPU 12 Bank 7: bd80000000100134
[98765.432] mce: [Hardware Error]: RIP !INEXACT! 33:<00007f1234567890>
[98765.432] mce: [Hardware Error]: TSC a1b2c3d4e5f67890 ADDR 0000000087654000
[98765.432] mce: [Hardware Error]: MISC 000000000000008c PPIN 1234567890abcdef
[98765.432] mce: [Hardware Error]: PROCESSOR 2:806f8 TIME 1710000000 SOCKET 1 APIC 24
[98765.432] Memory failure 0x87654: recovery action for dirty LRU page: Recovered

# STATUS 0xBD80000000100134 디코딩:
# bit 63 VAL=1, bit 61 UC=1, bit 60 EN=1
# bit 59 MISCV=1, bit 58 ADDRV=1
# bit 57 PCC=0 → 프로세서 컨텍스트 정상
# bit 56 S=1, bit 55 AR=1 → SRAR
# Error Code (bits 15:0) = 0x0134 → L3 캐시 데이터 읽기 에러
# 결과: memory_failure()로 페이지 복구 성공 ("Recovered")

자주 발생하는 MCE 패턴

데이터센터에서 흔히 관찰되는 MCE 패턴과 각각의 원인, 대응 방법을 정리합니다.

패턴 1: CE 누적 (DIMM 열화)

패턴 2: UC no PCC (복구 가능한 에러)

패턴 3: UC + PCC (시스템 패닉)

패턴 4: OVER + UC (에러 오버플로)

패턴 5: Thermal MCE

패턴 6: 버스/인터커넥트 에러

패턴 7: IIO PCIe Completion Timeout

패턴 8: IIO Poisoned TLP (데이터 독성 전파)

패턴 9: TOR (Table of Requests) 타임아웃

패턴 10: UPI 링크 에러 (멀티소켓)

패턴 11: M2M Patrol Scrub UC (사전 발견 메모리 에러)

패턴 12: GPU/가속기 관련 IIO 연쇄 에러

패턴 13: Row Hammer 유발 MCE

Row Hammer는 DRAM의 물리적 특성을 이용한 현상으로, 특정 행을 반복 접근(Hammering)하면 인접 행(Victim Row)의 셀에서 전하 누출이 발생하여 비트 플립(Bit Flip)이 일어납니다. 이는 의도적 공격뿐 아니라 고부하 워크로드에서도 자연적으로 발생할 수 있습니다.

Row Hammer → MCE 발생 경로

1. 반복 행 활성화: 공격자 또는 워크로드가 동일 DRAM 행을 수만~수십만 회 반복 접근 (clflush + 메모리 읽기 루프)
2. 인접 행 비트 플립: Victim Row의 셀 커패시터(Capacitor) 전하가 누출되어 0→1 또는 1→0 전환
3. ECC 감지: 메모리 컨트롤러의 ECC가 비트 오류를 감지 — 단일 비트 → CE, 다중 비트 → UCE → memory_failure() 호출
4. MCE 생성: MCA 뱅크(메모리 컨트롤러)에 에러 기록, STATUS.VAL=1 설정

TRR (Target Row Refresh)과 한계

DDR4 이후 DRAM 제조사들은 TRR(Target Row Refresh)을 도입하여 Aggressor Row 감지 시 Victim Row를 사전 리프레시(Refresh)합니다. 그러나 TRRespass, Half-Double, Blacksmith 등 연구에서 TRR 우회 패턴이 발견되었으며, DDR5에서는 표준화된 RFM(Refresh Management) 명령으로 개선되었으나 공정 미세화에 따라 취약성은 증가 추세입니다.

성능 영향과 튜닝

MCE 서브시스템은 정상 상태에서 거의 오버헤드가 없지만, 에러 발생 시나 폴링 설정에 따라 성능에 영향을 줄 수 있습니다. 대규모 서버 클러스터에서는 MCE 관련 설정이 전체 가용성에 영향을 미칠 수 있으므로 적절한 튜닝이 필요합니다.

MCE 관련 커널 부트 파라미터

sysfs 튜닝 파라미터

ECC Patrol Scrubbing

메모리 스크러빙은 DRAM의 모든 위치를 주기적으로 읽어 CE를 사전에 발견하고 교정합니다. 스크럽 주기가 짧을수록 UC 에러(CE 누적 → 2비트 오류)를 예방하지만, 메모리 대역폭을 소비합니다.

성능 영향 요약

Prometheus + Grafana 모니터링 구축

대규모 서버 환경에서는 rasdaemon의 SQLite DB를 Prometheus 메트릭으로 변환하여 Grafana 대시보드에서 실시간 모니터링하고, Alertmanager로 임계값 알림을 설정합니다. node_exporter의 textfile collector를 활용하면 별도 exporter 개발 없이 구현 가능합니다.

#!/bin/bash
# /usr/local/bin/edac-metrics.sh
# node_exporter textfile collector용 EDAC 메트릭 생성 스크립트
# cron: */5 * * * * /usr/local/bin/edac-metrics.sh

TEXTFILE_DIR="/var/lib/node_exporter/textfile_collector"
PROM_FILE="${TEXTFILE_DIR}/edac.prom"
TMP_FILE="${PROM_FILE}.tmp"
DB="/var/lib/rasdaemon/ras-mc_event.db"

mkdir -p "${TEXTFILE_DIR}"

{
  echo "# HELP edac_ce_total Total corrected errors per DIMM"
  echo "# TYPE edac_ce_total counter"

  # EDAC sysfs에서 직접 메트릭 수집
  for mc in /sys/devices/system/edac/mc/mc*; do
    [ -d "$mc" ] || continue
    mc_id=$(basename "$mc" | sed 's/mc//')
    for dimm in "${mc}"/dimm*; do
      [ -d "$dimm" ] || continue
      dimm_id=$(basename "$dimm" | sed 's/dimm//')
      label=$(cat "${dimm}/dimm_label" 2>/dev/null || echo "unknown")
      ce=$(cat "${dimm}/dimm_ce_count" 2>/dev/null || echo 0)
      ue=$(cat "${dimm}/dimm_ue_count" 2>/dev/null || echo 0)
      echo "edac_ce_total{mc=\"${mc_id}\",dimm=\"${dimm_id}\",label=\"${label}\"} ${ce}"
      echo "edac_ue_total{mc=\"${mc_id}\",dimm=\"${dimm_id}\",label=\"${label}\"} ${ue}"
    done
  done

  echo "# HELP edac_ue_total Total uncorrected errors per DIMM"
  echo "# TYPE edac_ue_total counter"

  # rasdaemon DB에서 최근 1시간 CE rate 계산
  echo "# HELP edac_ce_rate_1h CE count in last hour"
  echo "# TYPE edac_ce_rate_1h gauge"
  if [ -f "${DB}" ]; then
    sqlite3 "${DB}" "SELECT mc, top_layer, mid_layer, COUNT(*) FROM mc_event \
      WHERE err_type='Corrected' AND timestamp > strftime('%s','now','-1 hour') \
      GROUP BY mc, top_layer, mid_layer;" | while IFS='|' read mc ch dm cnt; do
      echo "edac_ce_rate_1h{mc=\"${mc}\",channel=\"${ch}\",dimm=\"${dm}\"} ${cnt}"
    done
  fi
} > "${TMP_FILE}"

mv "${TMP_FILE}" "${PROM_FILE}"

# node_exporter 실행 시 textfile collector 경로 지정
$ node_exporter --collector.textfile.directory=/var/lib/node_exporter/textfile_collector

# Prometheus에서 확인
$ curl -s http://localhost:9090/api/v1/query?query=edac_ce_total | jq .

# Alertmanager 규칙 예시 (prometheus.rules.yml)
# CE가 1시간에 50회 이상이면 경고, UE 발생 시 긴급

# Prometheus alerting rules — /etc/prometheus/rules/edac.rules.yml
groups:
  - name: edac_alerts
    rules:
      - alert: HighCorrectedErrorRate
        expr: increase(edac_ce_total[1h]) > 50
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "DIMM {{ $labels.label }} CE 급증 ({{ $value }}/h)"
          description: "MC {{ $labels.mc }} DIMM {{ $labels.dimm }}에서 1시간 내 {{ $value }}건의 CE 발생. DIMM 교체 검토 필요."

      - alert: UncorrectedError
        expr: increase(edac_ue_total[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: "DIMM {{ $labels.label }} UE 발생!"
          description: "MC {{ $labels.mc }} DIMM {{ $labels.dimm }}에서 복구 불가 에러. 즉시 DIMM 교체 필요."

      - alert: CEtoUEEscalation
        expr: increase(edac_ce_total[24h]) > 100 and increase(edac_ue_total[24h]) > 0
        labels:
          severity: critical
        annotations:
          summary: "CE→UE 에스컬레이션 감지: {{ $labels.label }}"

대규모 서버 클러스터 MCE 통계

Google, Meta(Facebook), Microsoft 등이 발표한 대규모 데이터센터 연구에서 DRAM 에러율과 DIMM 수명 패턴에 대한 실측 데이터를 확인할 수 있습니다. 이 데이터는 DIMM 교체 정책과 용량 계획에 중요한 근거가 됩니다.

CE → UE 에스컬레이션 확률

DIMM 수명 곡선 (Bathtub Curve)

MCE와 ECC 메모리 모드

서버 메모리 컨트롤러는 여러 ECC/RAS 모드를 지원하며, 가용성과 성능 사이의 트레이드오프에 따라 적절한 모드를 선택해야 합니다. BIOS/UEFI에서 설정하며, MCE/EDAC이 보고하는 에러 유형과 복구 능력에 직접 영향을 줍니다.

DDR5 On-Die ECC와 MCE 변화

DDR5는 JEDEC 표준으로 On-Die ECC를 필수 기능으로 규정합니다. 각 DRAM 다이(Die) 내부에 ECC 엔진이 탑재되어, 데이터가 DRAM 칩 외부로 나가기 전에 단일 비트 오류를 자체 교정합니다. 이 변화는 호스트 측 MCE 패턴에 근본적인 영향을 미칩니다.

On-Die ECC 동작 원리

• 내부 구조: DDR5 다이는 128비트 데이터에 8비트 ECC 체크 비트를 추가하여 총 136비트를 저장. 읽기 시 내부에서 SECDED 수행
• 투명성: On-Die ECC 교정은 호스트 메모리 컨트롤러에 투명(Transparent)하므로, 교정된 오류는 CE MCE로 보고되지 않음
• 2계층 ECC: DDR5 서버 환경에서는 On-Die ECC(1차) + 호스트 ECC/Chipkill(2차)의 이중 보호가 적용됨

MCE 모니터링에 미치는 영향

• CE 감소 착시: DIMM 셀이 열화되더라도 On-Die ECC가 교정하므로 호스트 CE 카운트가 낮게 유지됨. DIMM이 실제로는 악화 중이어도 "정상"으로 보일 수 있음
• 급격한 UCE 전환: On-Die ECC 교정 한계를 넘는 오류(2비트 이상)가 발생하면, CE 없이 갑자기 UCE로 나타날 수 있음
• 기존 CE 임계값 무효화: DDR4 시절 "CE 100회/일 초과 시 DIMM 교체" 같은 정책이 DDR5에서는 적합하지 않을 수 있음

DDR5 시대의 대안적 건강 모니터링

1. DDR5 ECS(Error Check and Scrub): JEDEC 표준의 인밴드(In-band) ECS 명령으로 DRAM 내부 오류 카운터 조회 가능. 호스트 메모리 컨트롤러가 주기적으로 ECS 수행
2. 내부 에러 로깅: 일부 DDR5 DRAM은 MR(Mode Register)를 통해 On-Die ECC 교정 횟수를 노출. 하드웨어 벤더별 지원 수준 차이 있음
3. CXL 메모리 건강 명령: CXL 연결 메모리의 경우 CXL 2.0+ Health Status 명령(Get Health Info)으로 미디어 에러율, 온도, 수명 정보를 직접 조회
4. Intel PPR(Post Package Repair): Hard PPR은 결함 있는 DRAM 행을 영구적으로 스페어 행으로 대체. Soft PPR은 재부팅 전까지만 유효한 임시 수리
5. Device-level Sparing: Intel Sapphire Rapids 이후, 결함 DRAM 디바이스를 투명하게 스페어 디바이스로 교체 (ADDDC 확장)

DDR4 ECC vs DDR5 On-Die ECC + Host ECC 비교

MCE 운영 플레이북

CE 인시던트 대응 체크리스트

1. 에러 수집: ras-mc-ctl --summary로 DIMM별 CE 카운트 확인
2. 추세 분석: rasdaemon SQLite에서 시간대별 CE 빈도 쿼리
3. DIMM 식별: EDAC sysfs에서 소켓/채널/DIMM 슬롯 위치 확인
4. 임계값 판단: 24시간 내 CE > 100 → DIMM 교체 권장 (벤더 가이드 참조)
5. 선제 조치: soft_offline_page()로 문제 페이지 사전 격리 고려

UC 인시던트 대응 체크리스트

1. 서비스 영향 확인: SIGBUS로 종료된 프로세스 확인 (dmesg | grep -i sigbus)
2. HWPoison 상태: page-types -l -b hwpoison으로 오프라인 페이지 수 확인
3. 이전 CE 이력: 동일 DIMM에서 CE 누적이 있었는지 확인 (예측 가능했는지)
4. DIMM 교체: UC 발생 DIMM은 교체 우선순위 최상위로 에스컬레이션
5. 마이크로코드: 최신 마이크로코드 적용 여부 확인

패닉 후 복구 체크리스트

1. BERT 확인: 재부팅 후 dmesg | grep BERT로 이전 에러 정보 수집
2. crash dump: kdump/ERST로 저장된 vmcore 분석 (crash 유틸리티)
3. BIOS 에러 로그: BMC/IPMI SEL 로그 확인 (ipmitool sel list)
4. 하드웨어 점검: CPU/DIMM/보드 교체 결정
5. 사후 보고서: 타임라인, root cause, 재발 방지 작성