UE是内存硬件级致命错误，需用dmesg -T | grep -i "ue|uncorrectable"筛选，重点识别“EDAC MC0: UE on CPU#0, channel#0, dimm#1”类日志；UE发生后必须停机换条，因已存在silent data corruption风险。
怎么从 dmesg 里揪出 UE（Uncorrectable Error）
UE 是内存硬件级致命错误，意味着 ECC 已完全失效，数据大概率已损坏或触发了 NMI 中断。它不会安静地出现在 dmesg 默认输出里，必须用带时间戳、大小写不敏感的关键词组合筛：
-
dmesg -T | grep -i "ue\|uncorrectable\|hardware.*error\|mce.*panic"——UE是最短也最可靠的信号，比uncorrectable更少被日志截断 - 重点看含
EDAC MC0: UE on CPU#0, channel#0, dimm#1这类结构的行：MC0是内存控制器编号，dimm#1是逻辑编号，不是物理槽位 - 若看到
mce: [Hardware Error]: Machine check events logged但没后续细节，说明内核捕获了 MCE 但未解析出内存位置——此时需立刻查rasdaemon日志，不能只信dmesg
为什么 edac-util -v 看不到 UE 计数增长
edac-util 显示的是 /sys/devices/system/edac/mc/ 下的 sysfs 值，而 UE 事件在现代内核中往往不更新 ue_count 文件，尤其在 Intel Ice Lake+ 或 AMD EPYC 7xx2+ 平台。这不是工具失效，是内核行为变更：
- UE 通常走 APEI (ACPI Platform Error Interface) 路径，直接进
/sys/firmware/acpi/apei/error_record或由rasdaemon消费tracefs事件 - 运行
cat /sys/devices/system/edac/mc/mc0/dimm0/ue_count 2>/dev/null返回空或 0，不代表没发生；要对比cat /sys/devices/system/edac/mc/mc0/csrow0/ue_count和csrow1/ue_count是否非零 - 更可靠的做法是：先确认
rasdaemon正在运行（systemctl is-active rasdaemon），再查journalctl -u rasdaemon --since "2 hours ago" | grep -i "uncorrectable\|memory_uncorrectable_error"
rasdaemon 日志里怎么定位到具体 DIMM 物理位置
rasdaemon 输出的 memory_uncorrectable_error 行含真实物理地址信息，但需要和 BIOS/DMIDECODE 对齐才能落到插槽。关键字段不是 dimm_label（常为空或错），而是 node_id + channel + rank：
- 典型日志：
memory_uncorrectable_error: node:0 card:0 module:0 rank:1 bank:0 page:0x1a2b3c row:0x456 col:0x78—— 其中node:0对应 CPU0，card:0是内存控制器，rank:1是该 DIMM 的 Rank 编号 - 用
dmidecode -t memory | grep -A 10 "Locator\|Bank\|Speed"查物理映射：重点关注Locator:字段（如A1,B2），它才是主板丝印标注的槽位名 - 交叉验证：若
rasdaemon报node:0 rank:1，而dmidecode显示Locator: A1对应Rank: 0/1，那大概率就是 A1 槽位的那根条 - 注意 DDR5 的 On-die ECC（ODECC）：
rasdaemon默认只报告主板级纠错，若 ODECC 已修正部分错误，UE 可能被压低——此时需进 BIOS 确认是否启用了 “Memory Mirroring” 或 “Rank Sparing”
UE 出现后还能继续跑业务吗
不能。UE 不是警告，是事后确认：错误已发生，且内核无法修复。哪怕系统没 panic，也极可能已发生 silent data corruption：
- 数据库 WAL 日志某字节翻转 → 主从不一致；Java 应用对象哈希值错位 → 缓存雪崩；Kubernetes etcd 的 raft term 错乱 → 集群脑裂
- 不要依赖
memtester复现：它测的是当前可分配内存，而 UE 往往发生在特定物理页+bank+row 组合，受温度、电压、老化共同影响，压力测试未必触发 - 唯一稳妥动作：记录所有
rasdaemon和dmesg -T中 UE 时间戳 → 对应时间段内排查是否曾有温升（sensors）、电源波动（ipmitool sdr type "Voltage"）、固件更新（dmidecode -s bios-version）→ 然后下电更换对应 DIMM
UE 的麻烦在于它不报错，只“留痕”。你看到的那条日志，已经是硬件故障的终点，不是起点。
