当操作系统内核检测到可纠正（CE）或不可纠正（UE）ECC内存错误时，会直接向环形缓冲区（ring buffer）写入日志记录。通过 dmesg 命令查看，是最轻量、最即时的ECC错误诊断方式。
- 执行
dmesg | grep -i "ecc|correctable|uncorrectable|mce"，重点筛选包含CE（Correctable Error，可纠正错误）或UE（Uncorrectable Error，不可纠正错误）的日志行 - 如果输出为空，并不代表系统没有ECC错误——可能由于日志缓冲区被后续信息覆盖，建议配合
dmesg -T（附带时间戳）或查看/var/log/kern.log历史记录进一步确认 - 典型ECC错误行示例：
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传感器告警，单纯依赖
dmesg可能无法捕获全部错误，需结合其他工具交叉验证
edac-util 能查看哪些实时ECC累计计数
edac-util 是EDAC子系统提供的命令行工具，它通过读取 /sys/devices/system/edac/mc/ 接口，实时反映当前内存控制器的累计ECC错误状态。
- 首先确认EDAC模块已加载：
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查看ECC日志
为什么 mcelog 有时比 edac-util 更早发现ECC错误
因为MCE（Machine Check Exception，机器检查异常）是CPU级别的硬件异常，而EDAC是内存控制器级别的统计机制。当ECC错误严重到触发硬件中断时，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）信号，能够记录比内核更早、更全面的ECC错误事件。
- 登录iLO（HPE）、iDRAC（Dell）或XClarity（Lenovo），进入“Integrated Management Log”或“Hardware Log”，筛选关键词
ECC或Memory Correctable Error - 这里通常能看到内核根本没有上报的瞬时错误——例如开机自检阶段的单次CE错误，或系统宕机前最后几秒的UE错误爆发
- 特别留意时间戳：BMC日志使用UTC时间，而
dmesg默认使用本地时间，对比时务必统一时区，否则容易误判错误发生的因果关系 - 如果BMC中记录了大量ECC错误，但操作系统没有任何相关记录，应优先怀疑BIOS设置（如关闭了EDAC报告）或内核未启用对应驱动
在实际ECC内存故障排查中，dmesg 是第一响应工具，edac-util 用于定位具体内存模块，mcelog 或 rasdaemon 用于深挖物理地址，BMC日志则用于补全时间线——四者缺一不可。最容易忽略的两个环节是：BMC日志的时间偏移问题，以及EDAC驱动未正确加载的情况。
