Linux怎么查看系统的内存ECC错误

内核在检测到可纠正（CE）或不可纠正（UE）ECC错误时，会直接打日志到ring buffer，dmesg 是最轻量、最即时的查看方式。

• 运行 dmesg | grep -i "ecc|correctable|uncorrectable|mce"，重点关注含 CE（Correctable Error）或 UE（Uncorrectable Error）的行
• 如果输出为空，不代表没错误——可能日志已被刷出缓冲区，需配合 dmesg -T（带时间戳）或检查 /var/log/kern.log 历史记录
• 典型错误行类似：EDAC MC0: 1 CE memory read error on CPU socket 0 channel 1 dimm 0 (csrow:2 page:0x12345678 offset:0x1000)
• 注意：某些厂商固件（如Dell iDRAC、HPE iLO）会把ECC事件转为IPMI sensor告警，dmesg 不一定捕获全部，需交叉验证

edac-util 能看到哪些实时ECC计数

edac-util 是EDAC子系统提供的命令行工具，它读取 /sys/devices/system/edac/mc/ 下的接口，反映当前内存控制器的累计错误状态。

• 先确认模块已加载：ls /sys/devices/system/edac/mc/，若无输出，需手动加载驱动，例如 modprobe amd64_edac_mod（AMD平台）或 modprobe i7core_edac（Intel旧平台）
• 运行 edac-util -v 查看详细计数，其中 CE 和 UE 列是关键指标；csrow 对应内存通道，dimm 对应插槽编号
• 注意：该数值是自系统启动以来的累加值，不会自动清零；若发现某 csrowX/dimmY 的 CE 值持续上涨，基本可锁定硬件故障点
• 部分新平台（如Intel Ice Lake+）使用 rasdaemon 替代 edac-util，此时需查 journalctl -u rasdaemon

为什么 mcelog 有时比 edac-util 更早报错

因为MCE（Machine Check Exception）是CPU级异常，而EDAC是内存控制器级统计。当错误严重到触发硬件中断时，mcelog 会解析原始MCE寄存器并生成更底层的定位信息。

• mcelog 已被标记为废弃，新系统推荐用 rasdaemon + systemd-rfkill 替代，但很多生产环境仍在用
• 运行 mcelog --client（需服务已运行），典型输出含 Memory error、bank:4、addr:0xdeadbeef 等字段，能精确定位物理地址
• 关键区别：edac-util 告诉你“哪根内存条错了”，mcelog 可能告诉你“错在哪个物理页+bank+row+column”，这对芯片级故障分析更有效
• 若 mcelog 报错但 edac-util 无记录，说明错误未被EDAC驱动捕获（常见于老旧内核或非标准内存控制器）

别漏掉BMC/iLO/DRAC里的硬件日志

服务器厂商的基板管理控制器（BMC）独立于操作系统运行，它通过SMBus或IPMI直接监听内存模块的AEC（Advanced ECC）信号，记录比内核更早、更全的错误事件。

• 登录iLO（HPE）、iDRAC（Dell）或XClarity（Lenovo），进入“Integrated Management Log”或“Hardware Log”，筛选关键词 ECC 或 Memory Correctable Error
• 这里常能看到内核根本没上报的瞬时错误——比如开机自检阶段的单次CE，或系统宕机前最后几秒的UE爆发
• 特别注意时间戳：BMC日志用UTC，而 dmesg 默认本地时间，比对时务必统一时区，否则容易误判因果关系
• 若BMC里有大量ECC错误但OS无任何记录，优先怀疑BIOS设置（如关闭了EDAC报告）或内核未启用对应驱动

真实排查中，dmesg 是第一响应，edac-util 定位模块，mcelog 或 rasdaemon 深挖物理地址，BMC日志补全时间线——四者缺一不可。最容易被忽略的是BMC日志的时间偏移和EDAC驱动未加载这两点。