RASTool注入未触发内存CE告警

AweiHe · 2026 年4 月 22 日 08:15

// 此模板仅供参考，如果不适用可以修改

问题描述

[在这里详细描述您遇到的问题]

环境信息

操作系统：Ubuntu 24.04
软件版本：如 OpenUBMC2509
硬件配置：[如 CPU、内存等]

重现步骤

setup那些就开启，阈值1，然后os下rastool工具注错0x1f那个，先连着注错10次，然后看fdm_diagnosis/fdm_output ，会打印dimm No.1 correctable error，然后等10分钟，再连续注错10次，看fdm output ，会打印个No.2，在等10分钟，注错10次，打印个No.3，bmc web就有dimm is in memory ce storm (sn: )
./RASTool --Se=1630V100

cat /proc/iomem |grep -i ram

./RASTool --E=0x1f --Sy=0x82088000000

./RASTool --E=0x1f --Sy=0x5fbf0000

[第一步]
[第二步]
[第三步]

期望结果

[您希望实现什么]
期望产生内存CE系统告警事件
0x01000017 MemoryUncorrectableErr

实际结果

[实际发生了什么，包含错误信息]

尝试过的解决方案

[列出您已经尝试过的解决方案及结果]

分析结论

[详细总结您对此问题的分析结论]

ubmc_assistant · 2026 年4 月 22 日 08:21

答案内容由AI生成，仅供参考：

总结

项目	说明
是否 Bug	否，当前行为合乎 RAS 设计逻辑
根本原因	注入的是 CE 错误，而非 UCE 错误
是否应触发 UCE 告警	不应，除非注入 UCE
推荐操作	使用支持 UCE 注入的方式重新测试

建议：区分 CE 与 UCE 的测试场景，分别验证其告警机制。若需测试 UCE 响应，请确保注入源能生成真实不可纠正错误。

点击此处查看详细分析解答

RASTool注入未触发内存CE告警问题分析

问题描述

使用 RASTool 工具在操作系统层面注入内存可纠正错误（Correctable Error, CE）后，尽管在 fdm_output.log 中能看到 DIMM 多次出现“correctable error rate exceeded threshold”记录，且累计次数达到3次，但 BMC Web界面仅上报“内存CE风暴”告警，而未产生预期的系统级内存不可纠正错误（UCE）告警事件 0x01000017 MemoryUncorrectableErr。

环境信息

操作系统: Ubuntu 24.04
软件版本: OpenUBMC 2509
硬件配置: 使用 RASTool --Se=1630V100 模拟注入，目标为 DDR3 类型内存（由日志中“Caused by DDR3 CE”推断）
注入工具: RASTool（Reliability, Availability, and Serviceability Tool）

重现步骤

在 BIOS 或 BMC 中开启 RAS 相关配置（如 Error Inject: Enable，设置 CE 告警阈值为 1）；
进入操作系统后，通过 cat /proc/iomem | grep -i ram 查看可用内存地址；

使用 RASTool 注入可纠正错误：

./RASTool --E=0x1f --Sy=0x82088000000
./RASTool --E=0x1f --Sy=0x5fbf0000

连续执行3轮，每轮注入10次 CE 错误，间隔约10分钟；
观察 fdm_diagnosis/fdm_output 日志输出。

实际结果

FDM日志输出：

2026-04-15 03:05:31: [Minor Warning], DIMM000 NO.1 correctable error rate exceeded threshold by PFAE.(Caused by DDR3 CE)
2026-04-15 03:22:10: [Minor Warning], DIMM000 NO.2 correctable error rate exceeded threshold by PFAE.(Caused by DDR3 CE)
2026-04-15 03:42:49: [Minor Warning], DIMM000 NO.3 correctable error rate exceeded threshold by PFAE.(Caused by DDR3 CE)

ARER 日志打印显示成功捕获 CE 错误，并定位到 DIMM000：
- 错误类型：CE（At least one error was corrected）
- 地址：0X2008F7F80 [DIMM000]
- Rank CE 计数器：30
最终现象：BMC Web 界面上报 “dimm is in memory ce storm (sn: )”，但 未生成 0x01000017 MemoryUncorrectableErr 的 UCE 告警事件。

期望结果

注入达到阈值的内存 CE 错误后，应触发以下行为：

产生 0x01000017 MemoryUncorrectableErr 系统告警事件；
在 BMC Web 界面或 IPMI SEL 日志中明确标识为“内存不可纠正错误”；
可能伴随系统宕机、记录诊断日志等 RAS 响应动作。

问题分析与结论

核心问题：注入的是 CE 而非 UCE，故不会触发 UCE 告警

根据所提供的上下文信息（特别是知识图谱和文档块），关键点如下：

CE 与 UCE 是两类不同的内存错误类型

Correctable Error (CE)：可由 ECC（Error-Correcting Code）自动修复的单比特或少数多比特错误。系统可正常运行，但频繁发生可能预示硬件劣化。
Uncorrectable Error (UCE)：超出 ECC 修正能力的严重内存错误，可能导致数据损坏或系统崩溃。0x01000017 MemoryUncorrectableErr 是专用于 UCE 的告警事件 ID。

RASTool 使用 `--E=0x1f` 注入的是 CE，不是 UCE

RASTool --E=0x1f 参数用于模拟 内存数据总线上的可纠正错误（例如 DQ 错误），这类错误通常会被 DDR 控制器识别并记录为 CE。
根据 ARER 日志内容：
```
Error Type: At least one error was corrected.(CE)
IERRCODE: 0X52 (HA access correct error)
```
明确表明这是 已被纠正的错误（CE），而非无法纠正的 UCE。

CE 频繁发生会触发“CE 风暴”告警，但不会升级为 UCE 告警

CorrectableECCStorm 属性：当单位时间内 CE 错误数量超过设定阈值时，系统判定为“CE 风暴”，用于预测潜在硬件故障。
根据知识图谱信息：

CorrectableECCStorm 表示在 MemoryOnChip 中发生了高频率的可纠正 ECC 错误风暴，值为 1 表示已发生。
在本案例中，多次触发 CE 导致：
- CorrectableECCOverfrequencyCount 增加；
- 最终触发了“dimm is in memory ce storm”告警。
但这属于 RAS 的预测性维护机制，与 UCE 告警是两个独立事件。

UCE 告警需实际注入不可纠正错误才能触发

要触发 0x01000017 MemoryUncorrectableErr，必须注入真正的 UCE 错误，例如：
- 模拟双比特或多比特错误（超出 ECC 修复能力）；
- 破坏 ECC 校验码本身；
- 引发地址总线错误或控制信号异常。
当前使用 --E=0x1f 无法达到此目的。

支持证据

来源	内容摘要
知识图谱：`CorrectableError`	“CorrectableError 是 PCIe 设备上可自动检测和纠正的错误……不会导致数据损坏或系统失败。”
知识图谱：`CorrectableECCStorm`	“指示在 MemoryOnChip 模块中发生了一次可纠正 ECC 错误风暴。”
搜索结果 #4：【RAS】在OS注入内存UCE故障后，BMC未告警	用户尝试在 OS 注入内存故障，但若方式错误（如注入地址错误）会导致错误触发于 Cache 层，而非真正内存 UCE。说明注入方法直接影响是否能生成正确告警。
搜索结果 #7 和 #9	提及新增 CLI 命令与属性来配置“内存 CE 风暴检测算法模式”及“CorrectableECCOverfrequencyCount”，说明 CE 风暴是独立于 UCE 的监控机制。

结论

未触发 0x01000017 MemoryUncorrectableErr 告警的根本原因在于：使用 RASTool 注入的是可纠正错误（CE），而目标告警是针对不可纠正错误（UCE）的，两者属于不同错误类别。

当前行为 符合预期设计逻辑：

注入 CE → 累计 CE 次数 → 触发 CE 超限警告 → 上报 CE Storm 告警；
并不会自动转换或映射为 UCE 告警。

解决方案建议

方法一：修改注入参数，注入真正的 UCE 错误

尝试使用 RASTool 注入更严重的错误类型，例如：

# 尝试注入 UCE 类型错误（需确认平台支持的具体编码）
./RASTool --E=0x20 --Sy=<target_address>

查阅 RASTool 手册，寻找代表 Uncorrectable ECC Error 或 Double-bit ECC Error 的错误代码。

方法二：通过 APEI EINJ 注入 UCE

Linux 提供 apei/einj 接口支持注入 UCE：

modprobe acpi_extlog
modprobe apei_einj

cd /sys/kernel/debug/apei/einj
echo 0x8 > error_type     # 0x8 表示 Memory Uncorrectable Error
echo <address> > param4   # 设置目标物理地址
echo 1 > error_inject

方法三：检查并确认告警策略配置

确保 BMC 中已启用 UCE 相关告警策略：

登录 BMC Web 或使用 IPMI 命令查看：

ipmitool sel list
ipmcget -t fdm -d memoryucealertenable

方法四：验证 UCE 事件定义是否存在

检查系统是否注册了 0x01000017 MemoryUncorrectableErr 事件：

查看 FDM 配置文件或事件定义数据库；
或通过命令导出所有事件列表进行比对。

总结

项目	说明
是否 Bug	否，当前行为合乎 RAS 设计逻辑
根本原因	注入的是 CE 错误，而非 UCE 错误
是否应触发 UCE 告警	不应，除非注入 UCE
推荐操作	使用支持 UCE 注入的方式重新测试

建议：区分 CE 与 UCE 的测试场景，分别验证其告警机制。若需测试 UCE 响应，请确保注入源能生成真实不可纠正错误。

BeanLin · 2026 年4 月 22 日 08:35

1.用例与实际预期不符，./RASTool --E=0x1f --Sy=0x5fbf0000 注入CE故障，是无法触发0x01000017 UCE告警的，请审视用例与预期结果；

2.如果希望触发UCE可以尝试使用–E=0x20；

3.ce storm事件已在社区版本去除，确认使用的产品是否需要该事件提示，及时同步社区代码，社区代码链接：

AweiHe · 2026 年4 月 23 日 03:14

CorrectableECC：表示内存已经发生过CE错误，BMC单次收到内存的CE错误IPMI消息即可置位；

CorrectableECCOverflow：表示具体内存已经发生CE错误超阈值事件，阈值和计数都在BIOS选项配置和统计；

CorrectableECCError：表示第3次CE超阈值后触发BIOS执行Bank替换事件，执行方也在BIOS；

Correct Error Threshold 3
Funnel Time 60

请教下为啥CorrectableECCError还是没有变化 @BeanLin

AweiHe · 2026 年4 月 23 日 03:15

openUBMC:/->mdbctl lsprop MemoryRAS_1_01010117
bmc.kepler.Object.Properties
ClassName=“MemoryRAS”
ObjectIdentifier=[1,“1”,“”,“01010117”]
ObjectName=“MemoryRAS_1_01010117”
TraceSamplingRate=0
bmc.kepler.Systems.FDMDomain.MemoryRAS
ConfigErrorCode=“”
ConfigErrorType=0
CorrectableECC=1
CorrectableECCError=0
CorrectableECCOverflow=1
CorrectableECCOverfrequencyCount=1
CorrectableECCStorm=0
CorrectableECCStormBurstCount=0
CurrentPeriodUncorrectableECCErrorCount=0
DataPoisoned=1
DimmId=0
ErrorStormCount=10
HealthScore=60
LastIsolationStatus=0
LastIsolationType=255
LastPredictTime=1775799758
LifeTimeUncorrectableECCErrorCount=24
LogicalChannelId=2
LogicalCpuId=0
Name=“DIMM000”
ParityError=0
PoorContactFault=0
PredictiveFault=0
ScrubingUncorrectableECC=0
SystemId=1
UncorrectableECCError=0

BeanLin · 2026 年4 月 23 日 06:17

你其实已经回答了，920X系列BIOS不会在3次超阈值后再触发任何隔离措施，所以不会上报该事件了，对应CorrectableECCError属性也就不会再被置位

AweiHe · 2026 年4 月 23 日 07:37

这个改动是有什么背景吗

BeanLin · 2026 年4 月 23 日 07:43

1.这属于BIOS的改动，建议提交问题到BIOS领域，聚焦BMC领域问题；

2.从920X天池架构开始，各软件责任能力需要归一，BIOS只提供隔离原子能力让带内/带外调度，不再自主执行隔离

l00012320 · 2026 年4 月 24 日 10:01

请问一下，CorrectableECCError这个属性的描述：表示第3次CE超阈值后触发BIOS执行Bank替换事件，是从哪里看见的？
我这边做UCE也遇见了类似的问题，UncorrectableECCError属性配置了也发生了UCE，但是没有变化。想看下是不是类似的问题

BeanLin · 2026 年4 月 25 日 06:49

已在原贴答复

话题		回复	浏览量
【RAS】通过rastool注入cpu uce告警之后，日志有打印，但实际无uce告警产生交流互助区提问求助	9	75	2026 年1 月 23 日
RAStool注入内存UCE，属性未发生变更交流互助区提问求助	8	25	2026 年4 月 25 日
【RAS】在OS注入内存UCE故障后，BMC未告警交流互助区提问求助	10	176	2026 年2 月 25 日
内存ce超门限CorrectableECCError如何触发交流互助区提问求助	2	34	2026 年4 月 3 日
注入内存错误超过CE阈值，BMC没有记录一笔BMC错误交流互助区提问求助	1	85	2026 年1 月 5 日

RASTool注入未触发内存CE告警

问题描述

环境信息

重现步骤

期望结果

实际结果

尝试过的解决方案

分析结论

总结

RASTool注入未触发内存CE告警问题分析

问题描述

环境信息

重现步骤

实际结果

期望结果

问题分析与结论

核心问题：注入的是 CE 而非 UCE，故不会触发 UCE 告警

CE 与 UCE 是两类不同的内存错误类型

RASTool 使用 --E=0x1f 注入的是 CE，不是 UCE

CE 频繁发生会触发“CE 风暴”告警，但不会升级为 UCE 告警

UCE 告警需实际注入不可纠正错误才能触发

支持证据

结论

解决方案建议

方法一：修改注入参数，注入真正的 UCE 错误

方法二：通过 APEI EINJ 注入 UCE

方法三：检查并确认告警策略配置

方法四：验证 UCE 事件定义是否存在

总结

相关话题

RASTool 使用 `--E=0x1f` 注入的是 CE，不是 UCE