问题描述
跑AC长稳概率出现内存温度获取失败告警产生又消除的情况
环境信息
- 软件版本：基于430的开发基线
重现步骤
跑AC长时间
期望结果
不产生告警
实际结果
告警产生并消除
尝试过的解决方案
增加PMU的Status判断，但是未能解决当前问题
分析结论
[详细总结您对此问题的分析结论]
答案内容由AI生成，仅供参考：
总结
| 项目 | 描述 |
|---|---|
| 根本原因 | AC循环后，BMC系统初始化过程中，IMU和IPMB通道尚未就绪，导致compute组件采集温度数据失败。 |
| 告警消除原因 | 系统启动完成后，IMU和IPMB通道恢复正常，后续的数据采集成功，故障条件解除。 |
| 核心矛盾 | 温度数据采集模块的启动速度快于底层通信模块（IPMB/IMU）的就绪速度。 |
| 解决方向 | 调整模块启动时序、增加数据采集重试机制，或由compute组件开发人员定位并修复。 |
点击此处查看详细分析解答
好的，根据您提供的Context中的信息，我将对“AC长稳概率出现内存温度获取失败告警产生又消除”这一问题进行综合分析。
问题分析与结论
根据已知信息，您在运行AC（交流电循环）长稳测试时，观察到系统会概率性地产生“Failed to obtain data of the memory (CPU1/CPU2) temperature.”的告警，并在约1-2分钟后自动消除。此现象有多个案例记录，其根本原因指向系统初始化过程中的时序问题。
根因分析
-
系统初始化未完成：AC循环会导致系统（特别是BMC）完全重启。在重启过程的早期，负责提供CPU和内存温度数据的核心组件——IMU（Intelligent Management Unit） 可能尚未完全就绪。当BMC中的
compute组件（负责定期采集数据）尝试通过IPMI命令向IMU查询温度时，由于IMU未响应或通信通道未建立，导致数据获取失败，从而触发了告警。文档6297的分析结论明确指出：“ac/dc过程中bmc通过imu没有获取到信息，可能imu还未就绪”。 -
IPMB通信故障：温度数据的传输依赖于IPMB（Intelligent Platform Management Bus）通道。在AC重启后，该通道的建立和稳定需要一定时间。如果
compute组件的温度采集模块在 IPMB 通道尚未就绪时就启动查询，就会导致读取失败。文档5028中提及的排查方向就是“排查下ipmb通道是否正常”，文档2916也怀疑与“ipmb通道有关”。 -
事件代码与状态对应：根据您提供的日志截图，Asserted（告警产生）状态对应事件码
0x0100003F，而Deasserted（告警消除）状态对应事件码0x01000040。知识库明确指出0x0100003F是“内存温度数据失败”的标识符，这印证了告警触发的原因。 -
告警自动消除的原因：当AC循环完成，系统启动稳定后，IMU和IPMB通道恢复正常工作。
compute组件后续的轮询查询能够成功获取到温度数据，于是系统自动判定故障条件消失，触发恢复事件0x01000040，告警状态转为Deasserted。
解决方向建议
根据知识库中的专家讨论，解决此类问题可以考虑以下几个方向：
-
调整模块启动时序：核心思路是确保
compute组件的温度采集功能在 IPMB通道 和 IMU 均完成初始化并准备就绪之后才启动。相关讨论指出：“ipmi_core模块ipmb注册时间晚于computer模块更新温度时间”，这暗示了启动顺序的不当。 -
增加重试机制：在首次查询失败或返回特殊值（如知识库中提到的表示失败的
0x8000）后，增加一个或几个短间隔的重试逻辑。如果重试成功，则不触发告警。 -
涉及闭源组件：从已有的分析结论（文档
6297）看，此问题涉及ipmi_core等闭源compute组件。因此，定位和修改具体代码需要相关组件的开发人员介入。
总结
| 项目 | 描述 |
|---|---|
| 根本原因 | AC循环后，BMC系统初始化过程中，IMU和IPMB通道尚未就绪，导致compute组件采集温度数据失败。 |
| 告警消除原因 | 系统启动完成后，IMU和IPMB通道恢复正常，后续的数据采集成功，故障条件解除。 |
| 核心矛盾 | 温度数据采集模块的启动速度快于底层通信模块（IPMB/IMU）的就绪速度。 |
| 解决方向 | 调整模块启动时序、增加数据采集重试机制，或由compute组件开发人员定位并修复。 |
您已经尝试“增加PMU的Status判断”未能解决问题，这进一步印证了核心问题不在于PMU本身的状态，而更倾向于IMU和底层通信通道（IPMB）的时序问题。建议重点排查 compute 组件与 ipmi_core 组件的启动顺序及相互依赖关系。
看appdump/event日志里的sync_property_trace
会记录最近的3次值
你的场景一般都是因为初始值有问题导致告警
读到正常值后就恢复了
请问这里的初始值指的是Event_Cpu1MemoryTempFail事件的Reading的初始值，还是指的是CPU的MaxMemoryTemperatureCelsius的初始值？
一键收集：
dump_info.tar.gz (3.9 MB)
Event初始值
所以要分析的就是这个初始值来源
||行 10332: 2026-05-28 13:14:02.189320 event NOTICE: events.lua(106): System minor count change 0 to 1 by [Event_Cpu1MemoryTempFail_010101].|
||行 10333: 2026-05-28 13:14:02.191553 event NOTICE: events.lua(127): System Health change Normal to Minor.|
||行 10335: 2026-05-28 13:14:02.211392 event NOTICE: hardware_event.lua(573): Event_Cpu1MemoryTempFail_010101|{value:[32768,1],source:{expressions:[expr($2 == 0 ? 0 : ($1 == 32768 ? 1 : 0))],properties:[{Property:MaxMemoryTemperatureCelsius,Interface:bmc.kepler.Systems.Processor.CPU,Path:/bmc/kepler/Systems/1/Processors/CPU/CPU_1_010101,Service:bmc.kepler.compute},{Property:Value,Interface:bmc.kepler.Scanner,Path:/bmc/kepler/Scanner/Scanner_PowerGood_010101,Service:bmc.kepler.hwproxy}]},type:synchronization}|
||行 10337: 2026-05-28 13:14:02.229666 sensor NOTICE: sensor_instance.lua(331): [DiscreteSensor_Cpu1MemoryHot_010101] assert an event [event dir: 1]|
||行 10340: 2026-05-28 13:14:02.355431 event NOTICE: abstract_event.lua(241): [Event_Cpu1MemoryTempFail_010101] generate an event [assert] while Reading change to [1].|