内存CE风暴产生后一段时间没有产生Deassert事件

[AweiHe (hkzy-hewei)]

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

问题描述

持续向内存注入内存CE错误产生CE风暴后，不再注入，等了一段事件后
bios上报了一条 remove ras storm的日志，但是看bmc的告警逻辑是关联MemoryRAS的CorrectableECCOverfrequencyCount属性。我理解bios上报这个日志后，bmc就应该消除这个告警

“CorrectableECCOverfrequencyCount”: {
“baseType”: “U32”,
“readOnly”: true,
“description”: “系统运行期间，内存CE故障发生频率超门限的次数。取值范围：0~0xFFFFFFFF。系统上下电/复位时，统计次数清零。”
}

环境信息

• 操作系统：[如 Ubuntu 24.04]

• 软件版本：[如 OpenUBMC2509]

• 硬件配置：[如 CPU、内存等]

重现步骤

1. [第一步]

2. [第二步]

3. [第三步]

期望结果

消除内存CE风暴告警

实际结果

静置环境未消除，只有在系统上下电/复位时，告警才消除

尝试过的解决方案

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

分析结论

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

[ubmc_assistant (openUBMC_Assistant)]

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

结论与建议

1. 根本原因：CorrectableECCOverfrequencyCount 属性是只读累计计数，仅在系统上下电/复位时清零，不具备自动降低或重置机制。因此，即使BIOS上报“remove ras storm”，BMC的告警仍无法自动消除。
2. 社区版本状态：CE风暴相关事件已在社区版本移除，当前版本可能缺少对应的Deassert逻辑，需要检查产品是否需要该功能。
3. 临时解决方案：
   • 使用 ClearCurrentPeriodMetrics 方法手动重置计数器（若系统支持）。
   • 执行系统下电/复位操作以清除计数。
4. 长期建议：
   • 确认产品需求后，同步社区最新代码，或自定义实现告警的恢复逻辑（例如增加一个独立的恢复属性或监听BIOS上报的“remove ras storm”信号来触发属性重置）。
   • 参考 event_def.json 中的事件配置，检查是否存在 LifeCycleId 或 DeassertFlag 相关配置缺失。

注意：上述结论完全基于提供的上下文信息，未引入外部知识。如需进一步排查，建议检查 alarm.log 中是否有事件注册记录，以及 CorrectableECCOverfrequencyCount 在BIOS上报后的实际值是否发生变化。

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

根据提供的上下文信息，以下是对“内存CE风暴产生后一段时间没有产生Deassert事件”问题的分析：

---

问题根因分析

1. 告警关联的属性机制

内存CE风暴告警关联的是 CorrectableECCOverfrequencyCount 属性。根据知识图谱和文档块中的描述：

• CorrectableECCOverfrequencyCount 是一个 只读（readOnly） 的U32属性，表示“系统运行期间，内存CE故障发生频率超门限的次数”，取值范围 0~0xFFFFFFFF。
• 该属性的 清零条件 仅为：系统上下电/复位时，统计次数清零（见文档块4、知识库中属性描述）。
• 该属性没有提供自动衰减或递减的机制，且不支持手动写入（只读）。

2. 告警的Deassert逻辑

系统事件告警的Deassert（消除）通常依赖于监听的 Reading 值 回退到安全阈值以下。但对于 CorrectableECCOverfrequencyCount，它是一个累计计数，只增不减，不会因BIOS上报“remove ras storm”而自动减少。因此，在同一个系统运行周期内，只要该计数值仍大于配置的阈值，告警状态就会持续保持，不会自动产生Deassert事件。

3. 社区版本的变更

知识图谱中明确说明：

CorrectableECCStorm 事件已在社区版本去除，openUBMC建议用户根据产品需求同步社区代码（BeanLin在issue中的回复）。

同时，文档块1中也提到：

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

这表明当前版本的CE风暴事件可能已被社区移除或处于不完整状态，导致告警的Deassert逻辑未正确实现。

4. 手动重置的方法

知识图谱中列出了 ClearCurrentPeriodMetrics 方法，该方法可以重置 CorrectableECCOverfrequencyCount 计数器，从而触发告警消除。但该方法并非自动调用，需要手动触发。

---

期望结果与实际结果对比

项目	期望	实际
告警消除条件	BIOS上报remove ras storm后自动Deassert	仅系统上下电/复位时消除，静置不消除
属性回退机制	应有自动递减或清零	只读累计，无自动清零机制

---

结论与建议

1. 根本原因：CorrectableECCOverfrequencyCount 属性是只读累计计数，仅在系统上下电/复位时清零，不具备自动降低或重置机制。因此，即使BIOS上报“remove ras storm”，BMC的告警仍无法自动消除。
2. 社区版本状态：CE风暴相关事件已在社区版本移除，当前版本可能缺少对应的Deassert逻辑，需要检查产品是否需要该功能。
3. 临时解决方案：
   • 使用 ClearCurrentPeriodMetrics 方法手动重置计数器（若系统支持）。
   • 执行系统下电/复位操作以清除计数。
4. 长期建议：
   • 确认产品需求后，同步社区最新代码，或自定义实现告警的恢复逻辑（例如增加一个独立的恢复属性或监听BIOS上报的“remove ras storm”信号来触发属性重置）。
   • 参考 event_def.json 中的事件配置，检查是否存在 LifeCycleId 或 DeassertFlag 相关配置缺失。

注意：上述结论完全基于提供的上下文信息，未引入外部知识。如需进一步排查，建议检查 alarm.log 中是否有事件注册记录，以及 CorrectableECCOverfrequencyCount 在BIOS上报后的实际值是否发生变化。

[AweiHe (hkzy-hewei)]

有专家懂这个背景的不

[duzhou13_51cdj (wanghaozhou)]

可以先实际查看一下，该 CorrectableECCOverfrequencyCount 属性是否满足了配置的 event 事件恢复的条件，以明确是数据源机制问题还是告警恢复机制问题

[AweiHe (hkzy-hewei)]

系统上下电/复位时，统计次数清零，告警就Deassert了。
我的意思是对这个告警设计的疑问，停止注入后bios日志打印 remove ras storm，但是bmc没有恢复告警，告警内容为 The memory (%1) is in Memory CE Storm. 当前已经不再注入了，我理解这个告警就应该消除了

[BeanLin]

风暴告警描述的是本次系统启动后内存是否出现过高频CE故障，而内存颗粒故障存在是客观事实，与BIOS打印无关，与硬件器件特性相关：系统重启/上下电BIOS会对内存重训练，刷新颗粒数据不再报错，大概率才可以判断为软失效，所以告警消除机制仅通过OS系统重新/上下电消除。