📚 课程目录第4章操作系统与驱动层高可用

4. 操作系统与驱动层高可用

Intel Xeon 的 RAS 能力（Machine Check、内存镜像、DDDC、Patrol Scrub、PCIe AER、CMCI 等）最终要落到操作系统与驱动层才能被“看见”和“处置”。硬件只负责检测与记录，操作系统负责把错误从固件/硬件寄存器翻译成可读事件，再决定是纠正、隔离、降级还是触发宕机转储。理解这条链路，是判断一台关键业务服务器“能不能扛住一次可纠正错误、能不能在不可纠正错误前留下证据”的核心。

一、Linux 侧：从 MCE 到 EDAC 再到 mcelog/rasdaemon

Linux 对 Xeon RAS 的支持是分层递进的。最底层是 CPU 的 Machine Check Architecture（MCA），每个核心有若干组 MSR（如 IA32_MCi_STATUS、IA32_MCi_ADDR、IA32_MCi_MISC），记录错误类型、可纠正性、地址与 Bank。内核通过 CONFIG_X86_MCE 与 CONFIG_X86_MCE_INTEL 接管这些寄存器，在 CMCI 中断或轮询时读取并解码。

第二层是 EDAC（Error Detection And Correction）子系统。对 Xeon 而言，sb_edac（Sandy/Ivy Bridge-EP）、skx_edac（Skylake-SP 及后续）负责把内存控制器上报的 DRAM 错误翻译成“哪条内存通道、哪个 DIMM、哪个 Rank”。没有 EDAC，你只能看到“某个 Bank 出错”，无法定位到具体内存条。

第三层是用户态守护进程。传统方案是 mcelog，较新发行版推荐 rasdaemon，它同时消费 MCE、AER、EDAC 事件并写入 SQLite 数据库，便于长期统计。典型部署如下：

# 加载 EDAC 驱动（以 Skylake-SP 为例）
modprobe skx_edac

# 查看内存错误计数
edac-util -v
# 输出示例（教学示例，非实测）：
# mc0:csrow0:CPU_SrcID#0_MC#0_Chan#0_DIMM#0: 0 CE, 0 UE
# mc0:csrow1:CPU_SrcID#0_MC#0_Chan#1_DIMM#0: 12 CE, 0 UE

# 启动 rasdaemon 并记录
systemctl enable --now rasdaemon
ras-mc-ctl --summary
ras-mc-ctl --errors

判断依据很直接：CE（Corrected Error）持续增长但 UE（Uncorrectable Error）为 0，说明内存条在退化，应安排计划内更换；一旦出现 UE，且地址可定位到某 DIMM，通常意味着该内存条已不可信，需要立即隔离或更换。若 edac-util 只显示 mc0: 0 CE, 0 UE 而 dmesg 里却有 MCE，说明 EDAC 驱动未匹配或 DIMM 映射表缺失，此时应优先修复驱动兼容性，而不是忽略错误。

二、Windows 侧：WHEA 与事件日志

Windows 对应机制是 WHEA（Windows Hardware Error Architecture）。Xeon 的 MCA、PCIe AER、内存错误由固件通过 APEI（ACPI Platform Error Interface）或直接由 WHEA 驱动采集，统一抽象为 WHEA 错误记录，写入系统事件日志，来源为 Microsoft-Windows-WHEA-Logger。常见事件 ID：

Event ID 1：WHEA 错误，通常为可纠正错误（CE），记录 Bank、APIC ID、错误类型。
Event ID 17：已纠正的硬件错误，常见于内存 CE。
Event ID 18：已纠正的 PCIe 错误。
Event ID 19：不可纠正错误（UE），可能导致蓝屏。
Event ID 47：内存 CE 超过阈值，提示需要关注。

与 Linux 类似，Windows 也需要正确的芯片组/内存控制器驱动才能把错误定位到 DIMM。若只看到“WHEA-Logger Event ID 1”而无法定位插槽，应检查是否安装了厂商的 RAS 管理组件（如 Intel 的 Intel Platform Monitoring Technology 或服务器厂商的 System Management 驱动）。

三、驱动兼容性：RAS 能否生效的前提

RAS 特性对驱动版本高度敏感。以 DDDC（Demand Data Disable Correction）和 ADDDC 为例，它们需要 BIOS 开启、内核 EDAC 驱动支持对应 CPU 代际、并且内存控制器驱动版本匹配。常见兼容性问题包括：

内核版本过旧，skx_edac 尚未合入，导致 EDAC 无法识别 DIMM。
BIOS 中 RAS 选项（如 Patrol Scrub、Memory Mirroring）未开启，操作系统侧看不到对应能力。
PCIe AER 在 BIOS 中被关闭，或 pcie_ports=native 未设置，导致 AER 事件无法上报。
Windows 未安装 WHEA 相关更新，事件日志中错误记录不完整。

因此，部署关键业务前应做一次“RAS 能力核对”：确认 CPU 代际、BIOS RAS 选项、内核版本、EDAC 驱动、rasdaemon/WHEA 组件四者匹配。任何一环缺失，都会让硬件错误“静默丢失”。

四、内核转储：不可纠正错误前的最后证据

当 UE 发生且无法屏蔽时，系统可能立即宕机。此时 kdump（Linux）或 Crash Dump（Windows）是唯一能保留现场的手段。Linux 侧需要配置 crashkernel 预留内存并启用 kdump 服务：

# /etc/default/grub 中预留 512M 给 crashkernel
GRUB_CMDLINE_LINUX="crashkernel=512M"

# 启用 kdump
systemctl enable --now kdump
# 触发后 vmcore 位于 /var/crash/<timestamp>/vmcore
# 用 crash 工具分析：
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore

Windows 侧则配置“核心内存转储”或“完整内存转储”，转储文件默认位于 %SystemRoot%\MEMORY.DMP，可用 WinDbg 分析 !analyze -v 与 WHEA 相关扩展。转储的价值在于：它能告诉你 UE 发生在哪个 Bank、哪个地址、当时正在执行什么代码，从而区分是内存条故障、CPU 内部故障还是 PCIe 设备故障。

五、硬件错误上报路径总览

把上述内容串起来，Xeon 硬件错误从发生到被处置，大致经过“硬件检测 → 固件/中断 → 操作系统内核 → 用户态守护/日志 → 运维判断”五段。下图给出 Linux 与 Windows 两条并行路径的关键节点与分叉点，便于在排障时快速定位“错误卡在哪一层”。

实际排障时，建议按“先看日志有没有、再看定位准不准、最后看转储全不全”的顺序推进。如果 dmesg 或事件日志中完全没有错误记录，问题往往不在硬件本身，而在 BIOS RAS 选项未开、EDAC/WHEA 驱动未加载或内核版本不匹配；如果能看到错误但无法定位到 DIMM 或 PCIe 设备，则要检查厂商 RAS 组件与固件映射表；如果 UE 已导致宕机但无 vmcore/MEMORY.DMP，则说明 crashkernel 预留或转储配置未生效，需要在下一次故障前补齐。把这三层判断固化为例行巡检项，才能让 Xeon 的 RAS 能力真正转化为关键业务的可观测性与可恢复性。