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 가상화(Virtualization) 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 디버깅(Debugging) 기법(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);
    }
}

MCA 뱅크 레지스터 상세 레이아웃

각 MCA 뱅크의 4개 핵심 레지스터(CTL/STATUS/ADDR/MISC)는 서로 다른 역할을 수행하며, 에러 처리 과정에서 순차적으로 참조됩니다. 아래 다이어그램은 단일 뱅크의 레지스터 간 데이터 흐름과 비트 필드 구조를 상세하게 보여줍니다.

커널 모듈(Kernel Module)에서 MCA 뱅크 MSR 읽기

다음은 커널 모듈에서 직접 MCA 뱅크 레지스터를 읽어 에러 상태를 진단하는 예제입니다. 프로덕션 환경에서는 rasdaemon이나 perf를 사용하는 것이 권장되지만, 디버깅이나 커스텀 RAS 모니터링 도구 개발 시 직접 MSR을 읽어야 할 때가 있습니다.

/* mce_reader.c — MCA 뱅크 MSR을 직접 읽는 커널 모듈 예제 */
#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/msr.h>
#include <asm/mce.h>

#define MSR_IA32_MCG_CAP        0x179
#define MSR_IA32_MCG_STATUS     0x17A
#define MCG_BANKCNT_MASK        0xFF

/* MCi_STATUS 비트 매크로 */
#define MCI_STATUS_VAL          (1ULL << 63)
#define MCI_STATUS_OVER         (1ULL << 62)
#define MCI_STATUS_UC           (1ULL << 61)
#define MCI_STATUS_EN           (1ULL << 60)
#define MCI_STATUS_MISCV        (1ULL << 59)
#define MCI_STATUS_ADDRV        (1ULL << 58)
#define MCI_STATUS_PCC          (1ULL << 57)
#define MCI_STATUS_S            (1ULL << 56)
#define MCI_STATUS_AR           (1ULL << 55)

static void decode_mci_status(int bank, u64 status)
{
    if (!(status & MCI_STATUS_VAL)) {
        pr_info("  Bank %d: 에러 없음 (VAL=0)\n", bank);
        return;
    }

    pr_info("  Bank %d: STATUS=0x%016llx\n", bank, status);
    pr_info("    VAL=%d OVER=%d UC=%d EN=%d MISCV=%d ADDRV=%d PCC=%d S=%d AR=%d\n",
        !!(status & MCI_STATUS_VAL),
        !!(status & MCI_STATUS_OVER),
        !!(status & MCI_STATUS_UC),
        !!(status & MCI_STATUS_EN),
        !!(status & MCI_STATUS_MISCV),
        !!(status & MCI_STATUS_ADDRV),
        !!(status & MCI_STATUS_PCC),
        !!(status & MCI_STATUS_S),
        !!(status & MCI_STATUS_AR));

    /* MCA 에러 코드 (하위 16비트) */
    pr_info("    MCA Error Code: 0x%04x, MSCOD: 0x%04x\n",
        (u16)(status & 0xFFFF),
        (u16)((status >> 16) & 0xFFFF));

    /* 심각도 판별 */
    if (status & MCI_STATUS_UC) {
        if (status & MCI_STATUS_PCC)
            pr_err("    심각도: UC+PCC → 프로세서 컨텍스트 손상 (PANIC 대상)\n");
        else if ((status & MCI_STATUS_S) && (status & MCI_STATUS_AR))
            pr_warn("    심각도: SRAR → 즉시 복구 필요\n");
        else if (status & MCI_STATUS_S)
            pr_warn("    심각도: SRAO → 백그라운드 처리\n");
        else
            pr_info("    심각도: UCNA → 정보성 보고\n");
    } else {
        pr_info("    심각도: CE → 하드웨어 자동 교정\n");
    }
}

static int __init mce_reader_init(void)
{
    u64 cap, status, addr, misc;
    int num_banks, i;

    /* 1. MCG_CAP에서 뱅크 수 읽기 */
    rdmsrl(MSR_IA32_MCG_CAP, cap);
    num_banks = cap & MCG_BANKCNT_MASK;
    pr_info("MCE Reader: MCG_CAP=0x%016llx, 뱅크 수=%d\n", cap, num_banks);
    pr_info("  MCG_EXT_P=%d MCG_SER_P=%d MCG_ELOG_P=%d MCG_LMCE_P=%d\n",
        !!(cap & (1ULL << 9)),   /* MCG_EXT_P */
        !!(cap & (1ULL << 24)),  /* MCG_SER_P: Software Error Recovery */
        !!(cap & (1ULL << 26)),  /* MCG_ELOG_P: Extended Error Logging */
        !!(cap & (1ULL << 27))); /* MCG_LMCE_P: Local MCE */

    /* 2. 각 뱅크의 STATUS/ADDR/MISC 읽기 */
    for (i = 0; i < num_banks; i++) {
        rdmsrl(MSR_IA32_MCx_STATUS(i), status);
        decode_mci_status(i, status);

        if ((status & MCI_STATUS_VAL) && (status & MCI_STATUS_ADDRV)) {
            rdmsrl(MSR_IA32_MCx_ADDR(i), addr);
            pr_info("    ADDR=0x%016llx (PFN=0x%lx)\n",
                addr, (unsigned long)(addr >> PAGE_SHIFT));
        }
        if ((status & MCI_STATUS_VAL) && (status & MCI_STATUS_MISCV)) {
            rdmsrl(MSR_IA32_MCx_MISC(i), misc);
            pr_info("    MISC=0x%016llx (AddrLSB=%d, AddrMode=%d)\n",
                misc, (int)(misc & 0x3F), (int)((misc >> 6) & 7));
        }
    }
    return 0;
}

static void __exit mce_reader_exit(void)
{
    pr_info("MCE Reader: 모듈 언로드\n");
}

module_init(mce_reader_init);
module_exit(mce_reader_exit);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("MCA Bank Register Reader for Diagnostics");

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;
    }
}

severities[] 테이블 상세 — 매칭 순서와 우선순위(Priority)

커널의 severities[] 배열은 위에서 아래로 순차 검사되며, 첫 번째 매칭이 최종 심각도를 결정합니다. 따라서 배열 순서가 곧 우선순위입니다. 아래는 최근 6.x 계열의 주요 엔트리와 매칭 조건입니다.

/* arch/x86/kernel/cpu/mce/severity.c — severities[] 테이블 (핵심 엔트리) */
static struct severity severities[] = {
    /* --- 무효/비활성 에러 → 무시 --- */
    MCESEV(NO, "Invalid",
        SER, BITCLR(MCI_STATUS_VAL)),        /* VAL=0: 유효하지 않음 */
    MCESEV(NO, "Not enabled",
        SER, BITCLR(MCI_STATUS_EN)),         /* EN=0: 보고 비활성 */

    /* --- 무조건 패닉 --- */
    MCESEV(PANIC, "Processor context corrupt",
        BITSET(MCI_STATUS_PCC)),             /* PCC=1: 어떤 조건이든 패닉 */

    /* --- 오버플로 + UC → 패닉 --- */
    MCESEV(PANIC, "Overflowed uncorrected",
        EXCP, BITSET(MCI_STATUS_OVER | MCI_STATUS_UC)),

    /* --- SRAR (Action Required) --- */
    MCESEV(AR, "Action required: data load error in user process",
        SER, BITSET(MCI_STATUS_UC | MCI_STATUS_S | MCI_STATUS_AR),
        USER),                               /* 사용자 모드에서 데이터 소비 */

    MCESEV(AR, "Action required with lost events",
        SER, BITSET(MCI_STATUS_UC | MCI_STATUS_S | MCI_STATUS_AR | MCI_STATUS_OVER)),

    /* --- SRAO (Action Optional) --- */
    MCESEV(UC, "Action optional: memory scrubbing error",
        SER, BITSET(MCI_STATUS_UC | MCI_STATUS_S), BITCLR(MCI_STATUS_AR),
        MASK(MCI_UC_SAO, MCI_STATUS_MCA)),   /* 패트롤 스크러빙 에러 */

    /* --- UCNA (No Action) --- */
    MCESEV(UCNA, "Uncorrected no action required",
        SER, BITSET(MCI_STATUS_UC), BITCLR(MCI_STATUS_S)),

    /* --- CE (Corrected) --- */
    MCESEV(KEEP, "Corrected error",
        BITCLR(MCI_STATUS_UC)),              /* UC=0: 하드웨어 자동 교정 */

    /* --- 기본값 (매칭 실패 시) --- */
    MCESEV(SOME, "Machine check"),
};

커널 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);
}

do_machine_check() 소스 코드 상세 분석

do_machine_check()의 내부 로직을 단계별로 더 깊이 분석합니다. 이 함수는 noinstr 속성으로 선언되어 계측 코드(ftrace, kprobes)가 삽입되지 않으며, NMI와 유사한 제약 환경에서 실행됩니다. 메모리 할당, 슬립(Sleep), printk 등 일반적인 커널 기능을 사용할 수 없으므로, 미리 할당된 per-CPU 구조체와 원자적 연산(Atomic Operation)만 사용합니다.

/* do_machine_check() 상세 흐름 (최근 6.x 계열, 핵심 로직 발췌) */
noinstr void do_machine_check(struct pt_regs *regs)
{
    struct mce m, *final;
    int worst = MCE_NO_SEVERITY;
    int order, no_way_out, kill_current_task = 0;
    int i, lmce, cfg_monarch_timeout;
    struct mca_config *cfg = &mca_cfg;

    /*
     * Phase 0: 초기화 및 컨텍스트 설정
     * - per-CPU mce 구조체 초기화
     * - 인터럽트/프리엠션 비활성 확인
     * - MCG_STATUS 읽기 (MCIP 비트 확인)
     */
    mce_gather_info(&m, regs);
    final = this_cpu_ptr(&mces_seen);
    *final = m;

    /* MCG_STATUS.MCIP 확인 — 이미 MCE 처리 중이면 이중 MCE */
    if (m.mcgstatus & MCG_STATUS_MCIP) {
        /* 이미 MCE 핸들러 안에서 새 MCE → 복구 불가 */
        mce_panic("MCE while already in MCE handler", &m, NULL);
    }

    /* LMCE(Local MCE) 여부 확인 — 다른 CPU에 브로드캐스트 안 됨 */
    lmce = m.mcgstatus & MCG_STATUS_LMCE_S;

    /*
     * Phase 1: Monarch 랑데부 (LMCE가 아닌 경우)
     * - LMCE면 이 CPU만 처리, Monarch 건너뜀
     * - 브로드캐스트 MCE면 모든 CPU 동기화
     */
    if (!lmce) {
        order = mce_start(&no_way_out);
    } else {
        order = -1;  /* LMCE: Monarch 없이 독립 처리 */
        no_way_out = 0;
    }

    /*
     * Phase 2: 자신의 MCA 뱅크 전체 스캔
     * - 모든 뱅크의 MCi_STATUS 읽기
     * - 각 에러의 심각도(severity) 판별
     * - 최악 심각도(worst) 추적
     * - mce_log()로 링 버퍼에 기록
     */
    for (i = 0; i < this_cpu_read(mce_num_banks); i++) {
        __clear_bit(i, this_cpu_ptr(mce_poll_banks));

        m.bank = i;
        m.status = mce_rdmsrl(MSR_IA32_MCx_STATUS(i));

        if (!(m.status & MCI_STATUS_VAL))
            continue;  /* 이 뱅크에 에러 없음 */

        /* ADDR/MISC 조건부 읽기 */
        if (m.status & MCI_STATUS_ADDRV)
            m.addr = mce_rdmsrl(MSR_IA32_MCx_ADDR(i));
        if (m.status & MCI_STATUS_MISCV)
            m.misc = mce_rdmsrl(MSR_IA32_MCx_MISC(i));

        /* 심각도 판별 — severity.c의 severities[] 테이블 매칭 */
        int severity = mce_severity(&m, regs, NULL, true);

        if (severity == MCE_PANIC_SEVERITY)
            no_way_out = 1;  /* 패닉 불가피 */

        if (severity > worst) {
            worst = severity;
            *final = m;  /* 최악 에러 정보 보존 */
        }

        /* 링 버퍼에 기록 + tracepoint 발생 */
        mce_log(&m);
    }

    /*
     * Phase 3: Monarch 결정 (브로드캐스트 MCE인 경우)
     * - Monarch CPU(order==1)가 모든 CPU의 worst severity 수집
     * - global_worst 기반으로 패닉/복구/로그 결정
     */
    if (!lmce) {
        if (order == 1)
            mce_reign();  /* Monarch: 최종 결정 */
        mce_end(order);
    }

    /*
     * Phase 4: 복구 동작 실행
     * - SRAR → kill_current_task = 1, memory_failure() 큐잉
     * - SRAO → memory_failure_queue() (워크큐 비동기 처리)
     * - CE/UCNA → 로깅만
     */
    if (worst >= MCE_AR_SEVERITY && mce_usable_address(final)) {
        /* AR(Action Required): 동기 MCE, 데이터 소비 에러 */
        if (!(final->mcgstatus & MCG_STATUS_RIPV))
            kill_current_task = 1;
        /* memory_failure를 큐에 넣음 (MCE 핸들러 내에서 직접 호출 불가) */
        memory_failure_queue(final->addr >> PAGE_SHIFT,
                             MF_ACTION_REQUIRED);
    } else if (worst >= MCE_UC_SEVERITY && mce_usable_address(final)) {
        /* UC + !PCC: 비동기 복구 가능 */
        memory_failure_queue(final->addr >> PAGE_SHIFT, 0);
    }

    /*
     * Phase 5: 에러 클리어 및 상태 복원
     * - MCi_STATUS = 0 쓰기 (에러 ACK)
     * - MCG_STATUS.MCIP 클리어 (다음 MCE 수신 허용)
     */
    for (i = 0; i < this_cpu_read(mce_num_banks); i++)
        mce_wrmsrl(MSR_IA32_MCx_STATUS(i), 0);
    mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);

    /* 현재 태스크 kill이 필요한 경우 */
    if (kill_current_task)
        force_sig(SIGBUS);
}

mce_gather_info() — 초기 컨텍스트 수집

MCE 핸들러 진입 직후 호출되는 mce_gather_info()는 MCG_STATUS 및 실행 컨텍스트를 수집하여 struct mce에 기록합니다. 이 정보는 이후 모든 단계에서 참조됩니다.

/* arch/x86/kernel/cpu/mce/core.c — 초기 정보 수집 */
static noinstr void mce_gather_info(struct mce *m, struct pt_regs *regs)
{
    /* 구조체 초기화 */
    mce_setup(m);

    /* MCG_STATUS: MCIP, RIPV, EIPV, LMCE_S 비트 */
    m->mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);

    /* TSC(Time Stamp Counter) — 에러 발생 시각의 정밀 타임스탬프 */
    m->tsc = rdtsc();

    /* 현재 실행 컨텍스트 기록 */
    if (regs) {
        m->ip = regs->ip;        /* 에러 발생 시 명령 포인터 */
        m->cs = regs->cs;        /* 코드 세그먼트 → ring 레벨 판별 */
    }

    /* CPU 식별 정보 */
    m->cpuvendor = boot_cpu_data.x86_vendor;
    m->cpuid     = cpuid_eax(1);
    m->socketid  = cpu_data(m->extcpu).phys_proc_id;
    m->apicid    = cpu_data(m->extcpu).initial_apicid;
    m->microcode = boot_cpu_data.microcode;

    /* Intel PPIN(Protected Processor Inventory Number) — CPU 고유 식별자 */
    if (cpu_has(c, X86_FEATURE_INTEL_PPIN))
        rdmsrl(MSR_PPIN, m->ppin);
}

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;
}

HWPoison 페이지 격리(Isolation) 상세 흐름

memory_failure()가 페이지를 HWPoison으로 마킹한 후, 해당 페이지가 시스템에서 완전히 격리되기까지의 상세한 내부 흐름입니다. 이 과정은 페이지 유형에 따라 크게 달라지며, 각 단계에서 실패할 수 있는 지점이 있습니다.

/* mm/memory-failure.c — HWPoison 격리 상세 흐름 (커널 6.x) */
int memory_failure(unsigned long pfn, int flags)
{
    struct page *p = pfn_to_page(pfn);
    int result = MF_FAILED;

    /* ========== 1단계: 기본 검증 ========== */
    if (!pfn_valid(pfn))
        return -ENXIO;  /* 유효하지 않은 PFN */

    if (TestSetPageHWPoison(p)) {
        pr_err("Memory failure: 0x%lx: already hardware poisoned\n", pfn);
        return 0;  /* 이미 HWPoison 상태 */
    }

    num_poisoned_pages_inc();  /* /proc/meminfo HardwareCorrupted 증가 */

    /* ========== 2단계: 페이지 참조 확인 ========== */
    /* shake_page: LRU에서 제거 시도 (pagevec flush 등) */
    shake_page(p);

    lock_page(p);

    /* ========== 3단계: 특수 페이지 유형 처리 ========== */
    if (PageHuge(p)) {
        /* Huge page: 4KB 서브페이지로 분리 후 해당 페이지만 재처리 */
        unlock_page(p);
        return memory_failure_hugetlb(pfn, p, flags);
    }

    if (PageTransHuge(p)) {
        /* THP(Transparent Huge Page): split 후 재처리 */
        if (try_to_split_thp_page(p) < 0) {
            pr_err("Memory failure: THP split 실패 0x%lx\n", pfn);
            return -EBUSY;
        }
    }

    /* ========== 4단계: 프로세스 알림 ========== */
    /* rmap(reverse mapping)으로 이 페이지를 매핑한 모든 프로세스 찾기 */
    collect_procs(p, &tokill, flags & MF_ACTION_REQUIRED);

    /* Early Kill: vm.memory_failure_early_kill=1이면 즉시 SIGBUS */
    /* Late Kill: 다음 접근 시점에 SIGBUS (기본값) */
    kill_procs(&tokill, flags & MF_ACTION_REQUIRED, pfn, flags);

    /* ========== 5단계: 페이지 격리 (유형별) ========== */
    struct page_state *ps = error_page_state(p);
    result = ps->action(p, pfn);

    /* ========== 6단계: buddy allocator에서 영구 제거 ========== */
    /* 페이지가 free list에 있으면 dissolve하여 재할당 방지 */
    if (PageBuddy(p))
        take_page_off_buddy(p);

    unlock_page(p);

    return result == MF_RECOVERED ? 0 : -EBUSY;
}

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;
}

CMCI 임계값 메커니즘 상세

CMCI의 임계값 메커니즘은 CE 빈도에 따라 인터럽트와 폴링 사이를 자동으로 전환하는 적응형(adaptive) 시스템입니다. 커널은 이 메커니즘을 통해 CE 폭주(storm) 상황에서도 시스템 안정성을 유지하면서 에러 정보를 놓치지 않습니다.

/* arch/x86/kernel/cpu/mce/intel.c — CMCI 스톰 감지 전체 흐름 */

/* 1. CMCI 인터럽트 핸들러 */
void intel_threshold_interrupt(void)
{
    /* CMCI 인터럽트 수신 — 뱅크별 CE 확인 */
    machine_check_poll(MCP_TIMESTAMP, this_cpu_ptr(mce_poll_banks));

    /* 스톰 감지: 짧은 시간에 CMCI가 반복되는지 확인 */
    if (cmci_storm_detect()) {
        /* 스톰 → 해당 뱅크의 CMCI 비활성화 + 폴링 전환 */
        cmci_storm_begin(bank);
    }
}

/* 2. 스톰 감지 알고리즘 */
static bool cmci_storm_detect(void)
{
    unsigned long now = jiffies;
    unsigned long last = this_cpu_read(cmci_time_stamp);

    /* CMCI 간격이 CMCI_STORM_INTERVAL보다 짧으면 스톰 */
    if (now - last < CMCI_STORM_INTERVAL) {
        this_cpu_inc(cmci_storm_cnt);
        if (this_cpu_read(cmci_storm_cnt) > CMCI_STORM_THRESHOLD)
            return true;  /* 스톰 확정 */
    } else {
        this_cpu_write(cmci_storm_cnt, 0);  /* 카운터 리셋 */
    }
    this_cpu_write(cmci_time_stamp, now);
    return false;
}

/* 3. 폴링 타이머 콜백 — 스톰 중에도 CE 수집 */
static void mce_timer_fn(struct timer_list *t)
{
    /* 폴링 모드에서 주기적으로 MCA 뱅크 스캔 */
    machine_check_poll(MCP_TIMESTAMP, this_cpu_ptr(mce_poll_banks));

    /* CE 빈도가 감소했는지 확인 */
    if (cmci_storm_subsided()) {
        cmci_storm_end(bank);  /* CMCI 재활성화 */
    } else {
        /* 타이머 재등록 (폴링 계속) */
        mod_timer(t, jiffies + CMCI_POLL_INTERVAL);
    }
}

CMCI 성능 영향과 최적화

CMCI는 정상 상태에서 오버헤드가 거의 없지만, CE가 빈번한 환경에서는 CMCI 인터럽트 자체가 CPU 사이클을 소비합니다. 다음은 환경별 최적 설정입니다.

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에 기록 → 소프트웨어가 선제 대응 가능 */

Intel vs AMD MCA 심각도 평가 비교

MCE 발생 시 커널은 에러의 심각도(Severity)를 평가하여 패닉(Panic), 프로세스 킬(Kill), 또는 로깅만 수행할지 결정합니다. Intel과 AMD는 서로 다른 심각도 평가 알고리즘을 사용합니다.

/* arch/x86/kernel/cpu/mce/severity.c — 심각도 판정 핵심 로직 (Intel/AMD 공통) */
static noinstr int mce_severity(struct mce *m, struct pt_regs *regs,
                                char **msg, bool is_excp)
{
    /* PCC(Processor Context Corrupt) = 1 → PANIC 필수 */
    if (m->status & MCI_STATUS_PCC)
        return MCE_PANIC_SEVERITY;

    /* UC + EN + S + AR → SRAR: 데이터 소비 에러, 즉시 복구 시도 */
    if ((m->status & (MCI_STATUS_UC | MCI_STATUS_EN |
                       MCI_STATUS_S | MCI_STATUS_AR)) ==
        (MCI_STATUS_UC | MCI_STATUS_EN |
         MCI_STATUS_S | MCI_STATUS_AR))
        return MCE_AR_SEVERITY;  /* memory_failure() 호출 */

    /* AMD SMCA: Deferred bit 확인 */
    if (mce_is_deferred(m))
        return MCE_DEFERRED_SEVERITY;  /* 선제적 오프라인 */

    /* ... 추가 심각도 레벨 판정 ... */
}

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

KVM MCE 주입 상세 — 테스트 시나리오

가상화 환경에서 MCE 처리 경로를 테스트하려면 호스트에서 게스트로 다양한 유형의 MCE를 주입해야 합니다. 아래는 각 심각도별 MCE 주입 방법과 게스트에서의 예상 동작입니다.

/* KVM MCE 주입 테스트 — 심각도별 시나리오 (C 프로그램) */
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/kvm.h>

void inject_mce(int vcpu_fd, u64 status, u64 addr,
               u64 misc, u8 bank, const char *desc)
{
    struct kvm_x86_mce mce = {
        .status    = status,
        .addr      = addr,
        .misc      = misc,
        .mcg_status = (1ULL << 2),  /* MCG_STATUS_MCIP */
        .bank      = bank,
    };

    printf("주입: %s (Bank=%d STATUS=0x%016llx)\n", desc, bank, status);
    int ret = ioctl(vcpu_fd, KVM_X86_SET_MCE, &mce);
    if (ret < 0)
        perror("KVM_X86_SET_MCE 실패");
}

int main(void)
{
    int vcpu_fd = open("/dev/kvm", O_RDWR);
    /* ... KVM VM/vCPU 생성 코드 생략 ... */

    /* 시나리오 1: CE (Corrected Error) — 게스트 로그만 기록 */
    inject_mce(vcpu_fd,
        0x9C00000000000150ULL,  /* VAL+EN+MISCV+ADDRV, UC=0 */
        0x0000000012340000ULL,  /* 물리 주소 */
        0x0000000000000086ULL,  /* AddrMode=물리, LSB=6 */
        9,                       /* Bank 9: 메모리 컨트롤러 */
        "CE 메모리 에러");

    /* 시나리오 2: SRAR — 게스트 프로세스 SIGBUS */
    inject_mce(vcpu_fd,
        0xBD80000000100134ULL,  /* VAL+UC+EN+MISCV+ADDRV+S+AR */
        0x0000000087650000ULL,  /* 에러 물리 주소 */
        0x000000000000008CULL,  /* AddrMode=물리, LSB=12(페이지) */
        7,                       /* Bank 7 */
        "SRAR 데이터 소비 에러");

    /* 시나리오 3: UC+PCC — 게스트 패닉 */
    inject_mce(vcpu_fd,
        0xBE00000000000400ULL,  /* VAL+OVER+UC+EN+MISCV+ADDRV+PCC */
        0x0000000000000000ULL,
        0x0000000000000000ULL,
        4,                       /* Bank 4: PCU */
        "UC+PCC 치명적 에러");

    return 0;
}

# QEMU 모니터를 통한 간편 MCE 주입 방법

# QEMU 실행 시 MCE 기능 활성화
$ qemu-system-x86_64 \
    -cpu host,+mce,+mca,+lmce \
    -enable-kvm \
    -m 8G \
    -monitor stdio \
    -drive file=guest.qcow2,format=qcow2

# 모니터에서 CE 주입 (게스트 커널 로그에만 기록)
(qemu) mce 0 9 0x9C00000000000150 0x12340000 0x86

# 모니터에서 SRAR 주입 (게스트 프로세스 SIGBUS)
(qemu) mce 0 7 0xBD80000000100134 0x87650000 0x8C

# 모니터에서 UC+PCC 주입 (게스트 패닉 — 주의!)
(qemu) mce 0 4 0xBE00000000000400 0x0 0x0

# 파라미터 형식: mce CPU BANK STATUS ADDR MISC
# 게스트에서 확인: dmesg | grep -i "mce\|hardware error"

KVM HWPoison 전파 메커니즘 상세

호스트에서 물리 메모리 페이지에 HWPoison이 설정되면, KVM은 해당 페이지를 매핑하고 있는 모든 게스트를 식별하여 적절한 조치를 수행합니다. 이 과정은 여러 서브시스템의 협력으로 이루어집니다.

/* KVM HWPoison 전파 경로 (최근 6.x 계열 개념 코드) */

/* 1단계: 호스트 memory_failure()가 페이지를 HWPoison으로 마킹 */
/*   → collect_procs()가 해당 HPA를 매핑한 프로세스(QEMU 포함) 수집 */
/*   → QEMU 프로세스에 SIGBUS(BUS_MCEERR_AO) 전달 */

/* 2단계: QEMU SIGBUS 핸들러 */
static void kvm_hwpoison_page_add(ram_addr_t addr)
{
    /* HPA → GPA 변환 */
    ram_addr_t ram_addr = qemu_ram_addr_from_host(siginfo->si_addr);
    hwaddr paddr = ram_addr;  /* QEMU 내부 물리 주소 = GPA */

    /* 3단계: KVM ioctl로 게스트에 MCE 주입 */
    struct kvm_x86_mce mce = {
        .status = MCI_STATUS_VAL | MCI_STATUS_UC | MCI_STATUS_EN
                | MCI_STATUS_ADDRV | MCI_STATUS_MISCV
                | MCI_STATUS_S | MCI_STATUS_AR  /* SRAR */
                | 0x0134,  /* L3 Data Read error code */
        .addr = paddr,
        .misc = (2ULL << 6) | PAGE_SHIFT, /* 물리 주소 모드, 페이지 정밀도 */
        .mcg_status = MCG_STATUS_MCIP | MCG_STATUS_RIPV,
        .bank = 9,
    };

    /* 4단계: LMCE 지원 시 해당 vCPU에만 주입 */
    for_each_vcpu(vcpu) {
        if (kvm_vcpu_ioctl(vcpu, KVM_X86_SET_MCE, &mce) < 0)
            error_report("MCE 주입 실패: vCPU %d", vcpu->id);
    }

    /* 5단계: EPT/NPT에서 해당 GPA의 매핑 제거 */
    /*   → 게스트가 이 주소에 다시 접근하면 EPT violation → KVM 핸들러 */
    /*   → KVM이 에러 반환 (KVM_EXIT_SHUTDOWN 또는 MCE 재주입) */
}

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 급증 시 자동 노드 드레인
• 체크포인트(Checkpoint) 전략: 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]);
}'

크래시 덤프(Dump) 분석 (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 인프라 변화 (v6.7~v6.14)

MCE 서브시스템은 하드웨어 벤더의 변화(Intel EMCA2, AMD Zen5, CXL 메모리 계층)에 발맞춰 꾸준히 확장되고 있습니다. 운영 관점에서 주요 신기능 중심으로 정리합니다.

Intel EMCA2 (Extended MCA 2, v6.7+)

Intel의 EMCA2는 Skylake-SP에서 도입된 EMCA의 확장판으로, Sapphire Rapids 이후 프로세서에서 지원됩니다. 핵심은 "더 많은 에러 클래스에 대한 firmware-first 처리"와 "에러 컨텍스트의 확장된 필드"입니다.

• Firmware-first 경로: 기존에는 치명적 에러만 BIOS/펌웨어가 먼저 수집하고 SCI를 통해 OS에 전달했지만, EMCA2는 대부분의 corrected error까지 펌웨어가 수집합니다. OS는 apei_mce_report_mem_error()로 보고를 받고 그 안에 포함된 확장 필드(뱅크 타입, 에러 severity, 벤더 종속 컨텍스트)를 참조합니다.
• Enhanced Error Source Table: ACPI HEST의 EMCA2 엔트리(GHES v3)가 확장되어 에러 소스별 상세 메타데이터가 노출됩니다. 커널은 drivers/acpi/apei/ghes.c에서 이를 해석해 RAS 이벤트로 변환.
• EDAC 자동 매핑: v6.10에서 i10nm_edac이 EMCA2 경로의 주소를 DIMM 채널/슬롯에 직접 매핑하도록 확장되어, 사용자 공간 rasdaemon의 리포팅이 별도 설정 없이 상세해졌습니다.

/* arch/x86/kernel/cpu/mce/apei.c (v6.7+) - EMCA2 경로 */
void apei_mce_report_mem_error(int severity, struct cper_sec_mem_err *mem_err)
{
    struct mce m;

    mce_setup(&m);
    m.bank = -1;                      /* firmware-first: 뱅크 미상 */
    m.status = MCI_STATUS_VAL | MCI_STATUS_UC | (severity << 56);
    m.addr = mem_err->physical_addr;
    /* EMCA2 확장 필드 전달 */
    if (mem_err->validation_bits & CPER_MEM_VALID_NODE)
        m.node = mem_err->node;

    mce_log(&m);
}

AMD Zen5 / Turin 대응 (v6.11~v6.13)

AMD 5세대 Zen(코드네임 Turin, EPYC 9005 시리즈)는 SMCA에 새로운 뱅크 타입을 추가하고, AI 가속기 오류 처리 경로를 정비했습니다. 리눅스 대응 현황:

• v6.11: Zen5 CPU 식별 및 기본 MCA 뱅크 인식(CPUID 기반). arch/x86/kernel/cpu/mce/amd.c의 smca_bank_names[]가 확장됨.
• v6.12: Zen5의 새로운 "Memory Controller v2" 뱅크 타입 추가. 기존 UMC(Unified Memory Controller)와 분리된 DDR5 전용 에러 경로.
• v6.13: AI accelerator(XDNA2 NPU)의 on-die 에러가 SMCA 뱅크로 승격되어 OS에 보고되도록 통합. 해당 뱅크는 주로 CE(Correctable Error)로 동작하지만, AI 모델 실행 중 데이터 corruption을 조기 감지.
• CXL 1.1 컨트롤러: Zen5의 내장 CXL 컨트롤러 오류가 SMCA_CS(Core & System) 뱅크에 매핑됨. CXL 디바이스 자체 오류(cxl_mem)는 별도 RAS 경로로 처리.

Memory Tiering과 MCE (v6.10+)

CXL 메모리, PMEM(Persistent Memory), 또는 NUMA hotplug로 도입된 메모리는 기존 DRAM과는 다른 신뢰도 특성을 가집니다. v6.10 이후 MCE 경로는 다음을 개선했습니다.

• Tier 식별: 에러가 발생한 물리 주소가 어떤 NUMA 노드/메모리 티어에 속하는지 식별해 로그에 포함. /sys/bus/nd/devices/*의 nd_region 정보와 상관 분석 가능.
• HWPoison과 메모리 migration: "이 페이지는 손상된 메모리에 있다"고 표시되면, 정상 DRAM의 페이지로 자동 복사한 뒤 원본 페이지를 오프라인합니다. v6.12에서 CXL 메모리의 poison 이벤트가 이 경로에 통합되어, 응용 프로그램이 크래시하지 않고 계속 동작 가능한 범위가 확대되었습니다.
• DAX 디바이스 에러: dax/pmem의 DIMM 수준 에러가 memory_failure() 경로와 일관되게 처리됩니다. 파일시스템(Filesystem) (ext4/xfs DAX)에서 해당 파일 접근 시 SIGBUS를 반환.

MCE Severity 분류 개선 (v6.9+)

MCE severity 분류는 오랫동안 "복구 가능 vs 패닉"의 이분법에 가까웠습니다. v6.9 이후 mce_severity() 경로가 다음과 같이 세분화되었습니다.

• AO vs UCNA: 이전에는 모두 "correctable과 비슷하게 처리"로 묶였으나, AO는 명시적 복구 절차가 있고 UCNA는 단순 기록/오프라인만 가능하다는 차이를 코드에서 구분합니다.
• 사용자 공간 노출: rasdaemon이 이러한 세분화를 인식해 보고하도록 v2.24+ 버전에서 업데이트되었습니다. 서비스 운영에서는 rasdaemon --sevnames 옵션을 확인하세요.

최신 MCE/RAS 인프라 변화 (v6.15~v6.17)

Linux v6.14까지의 변화는 앞 절에서 다루었습니다. 이 절에서는 v6.15 이후 메인라인에 병합된 주요 변화를 정리합니다.

EDAC Memory Repair Control 프레임워크 (v6.15)

Linux 6.15에서 EDAC 서브시스템에 Memory Repair Control 프레임워크가 추가되었습니다. 이 프레임워크는 메모리 하드웨어가 제공하는 자가 복구 기능을 커널에서 표준 인터페이스로 노출합니다.

지원하는 복구 동작:

• PPR (Post Package Repair): 손상된 DRAM 행(row)을 예비 행으로 교체합니다.
  • Soft PPR — 전원 차단 시 효과가 소멸되는 임시 복구
  • Hard PPR — 영구적인 행 교체 (JEDEC DDR4/DDR5 표준)
• Memory Sparing: 메모리 컨트롤러 수준에서 캐시라인·행·뱅크·랭크 단위 예비 교체를 지원합니다.

사용자 공간에서는 /sys/bus/edac/devices/<dev>/mem_repair/ 하위의 sysfs 인터페이스를 통해 복구 동작을 트리거할 수 있으며, rasdaemon이 이 인터페이스와 연동되도록 업데이트되었습니다. 상세 사용법은 커널 문서 Documentation/edac/memory_repair.rst를 참조하십시오.

커널 v6.15: EDAC Memory Repair Control 프레임워크 (PPR soft/hard, Memory Sparing) sysfs 인터페이스 추가.

CXL RAS/EDAC 통합 강화 (v6.16)

Linux 6.16에서는 CXL(Compute Express Link) 장치의 RAS 기능이 EDAC 프레임워크와 더욱 깊이 통합되었습니다. CXL 3.2 사양 및 JEDEC 표준에 정의된 다음 기능들이 커널에 추가되었습니다.

이 기능들은 /sys/bus/edac/devices/ 및 /sys/bus/cxl/ 하위의 sysfs를 통해 사용자 공간에 노출됩니다. 스크럽 인터페이스에 대한 전반적인 설명은 Documentation/edac/scrub.rst를 참조하십시오.

커널 v6.16: CXL RAS — Patrol Scrub Control, ECS (DDR5), Perform Maintenance, Memory Sparing이 EDAC 프레임워크에 통합.

SGX EPC 페이지 독극물(Poison) 처리 수정 (v6.16)

Intel SGX(Software Guard Extensions)에서 Enclave Page Cache(EPC) 페이지에 MCE가 발생하면 해당 페이지가 독극물 처리(poisoned)됩니다. v6.16 이전에는 독극물 처리된 EPC 페이지가 sgx_active_page_list에 잔류하여 커널 reclaimer가 해당 페이지를 EWB(Enclave Write Back) 마이크로코드 작업으로 내보내려 시도할 수 있었습니다. 그러나 EWB 명령은 독극물 처리된 페이지에 대해 또 다른 MCE를 발생시켜 CPU 강제 종료 → 나머지 CPU panic으로 이어지는 치명적 결함이 있었습니다.

v6.16 수정 사항: reclaimer가 EPC 페이지를 처리하기 전에 poison 플래그를 확인하여 독극물 처리된 페이지는 즉시 건너뛰도록 변경되었습니다. 결과적으로 독극물 처리된 EPC 페이지가 정상적으로 sgx_active_page_list에서 제거되며 추가 MCE 발생이 방지됩니다.

커널 v6.16: SGX EPC 독극물 페이지 reclaim 경로에서 이중 MCE → panic 버그 수정. epc_page->poison 플래그 검사 추가.

HWPoison 대형 폴리오(folio) 처리 개선

메모리 오류 처리 경로(memory_failure())는 페이지 관리 구조가 folio로 전환됨에 따라 지속적인 리팩토링이 진행 중입니다. 특히 대형 폴리오(large folio)에 대한 독극물 처리 지원이 개선되었습니다.

• 대형 폴리오 분할(split) 후 독극물 플래그가 올바르게 전파되도록 수정
• 분할 과정에서 PG_hwpoison 추적 정확도 향상
• HWPoison 이벤트의 folio 단위 보고로 사용자 공간 정밀도 개선

이 작업은 v6.15~v6.17에 걸쳐 점진적으로 반영되고 있으며, 대규모 메모리를 운용하는 서버 환경에서 신뢰성 있는 MCE 복구 경로를 보장합니다.

커널 설정 옵션

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 열화)