CpuBoard的Fru健康状态异常

l00012320 · 2026 年2 月 27 日 06:07

看代码是九月份上库的MR相关,但是远程RPC方法UpdateHealth始终是在的.
修复Fru的Health属性为0问题-frudata-AtomGit | GitCode

想问下FruData组件的UpdateHealth方法,是由哪个组件进行调用的,什么条件下会上报轻微告警? 没有相关日志打印.

KunLun2280V2_2103050SHG10S1100016_20260226-1245.tar.zip.001.txt (7.6 MB)
KunLun2280V2_2103050SHG10S1100016_20260226-1245.tar.zip.002.txt (4.9 MB)

ubmc_assistant · 2026 年2 月 27 日 06:20

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

总结

问题	解答
`UpdateHealth` 由谁调用？	主要由 `frudata` 在读取电子标签失败后调用 `Component_CpuBoard.UpdateHealth()`
何时上报轻微告警？	当 `frudata` 无法获取 CPU 板的电子标签数据（EEPROM 读取失败）时触发
为何没有日志？	可能因日志级别过高、hwproxy 无详细错误、或未启用组件日志
Health 为何不是 0？	因为数据未成功读取，系统认为处于异常状态，故未修复为 0
MR 修复的是什么？	修复的是“本该恢复正常却仍报错”的情况，不是解决读取失败本身

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

关于 `frudata` 组件中 `UpdateHealth` 方法的调用机制及轻微告警触发条件分析

根据您提供的日志信息和上下文内容，针对 FruData 组件的 UpdateHealth 方法由哪个组件调用、健康状态（Health）为 0 的修复问题以及 何时上报“获取 CPU 板电子标签失败”这一轻微告警，结合知识库内容进行如下综合分析：

一、`UpdateHealth` 方法是由哪个组件调用的？

调用者：多种硬件管理组件在状态变更时主动调用 `UpdateHealth`

从知识图谱和文档中可得出，UpdateHealth 是 Component 类中的一个方法，用于更新组件健康状态，其调用者因具体硬件类型而异。

主要调用组件包括：

frudata 组件本身
fructrl（FRU控制模块）
各硬件专属管理组件（如 PCIe、CPU、NPU 等）

依据如下：

知识图谱实体 Component 定义：
```
"class Component": {
  "FruId": "int",
  "Type": "int",
  "Name": "string",
  "SerialNumber": "string",
  "UpdateHealth()": "void"
}
```
表明：所有硬件组件都继承了 UpdateHealth() 接口，可在其内部逻辑中主动调用。
日志中事件触发路径表明：frudata 是事件源
在您的日志中出现：
```
$1: bmc.kepler.frudata /bmc/kepler/Systems/1/Frus/Fru_CpuBoard_010101 ...
```
说明该健康状态变化或告警触发来源于 bmc.kepler.frudata 服务，即 frudata 在检测到 CPU 板电子标签读取失败后，更新了对应 Component 的 Health 状态。
frudata 的功能角色支持此行为
- frudata 是负责 电子标签（FRU EEPROM）数据管理的核心组件。
- 当它尝试读取 CPU Board 的电子标签数据失败时，会通过调用 Component.UpdateHealth() 来标记该 FRU 健康状态异常。
搜索结果补充说明：

“frudata组件负责电子标签管理，支持标准电子标签和非标定制能力。”

进一步确认其职责包括：读取 EEPROM 数据 → 解析 → 更新系统对象（含 Health 状态）

二、什么条件下会上报“轻微告警”？为什么没有日志打印？

触发条件：未能成功获取 CPU 板电子标签数据

您提到的日志：

Failed to obtain electronic label data of CPU board 1 (SN:1025BG260099)

这是典型的 FRU 数据读取失败场景。触发流程如下：

触发链路分析：

系统上电或自发现阶段，硬件自发现 模块将 Fru_CpuBoard_010101 对象注册并分发给 frudata。
frudata 尝试通过 hwproxy 读取该板卡的 EEPROM 数据（通常存储在 I2C 上的 FRU 存储器）。
若读取失败（如 I2C 通信超时、CRC 校验错误、EEPROM 空等），则：
- frudata 调用 Component_CpuBoard.UpdateHealth()，将 Health 设为非 0 值（如 1，表示 Minor）。
- 同时依据 Event 配置（如 Event_CpuBoardAccessFRUableFailure），生成一条告警事件。
该事件被写入 SEL（System Event Log），并通过 Redfish/API 对外暴露。

条件总结（触发轻微告警的条件）：

触发条件	是否匹配
无法读取 CPU Board 的 EEPROM 数据	匹配（报错信息明确指出）
EEPROM 内容损坏或为空	可能
I2C 总线异常或设备未响应	可能
`frudata` 初始化阶段未及时获取数据	可能（尤其在并发加载时）

为何没有相关日志打印？

尽管事件已记录在 current_event.txt 中，但 缺少中间过程日志 可能源于以下原因：

1. 日志级别设置过严

若 frudata 日志等级为 ERROR 或以上，可能不会输出 DEBUG/INFO 级别的 EEPROM 读取重试、失败等中间步骤。
建议检查 /etc/rsyslog.d/frudata.conf 或运行时参数中的 log level。

2. EEPROM 访问无详细追踪

hwproxy 层可能仅返回失败码，未附带详细错误类型（如 NACK, timeout），导致 frudata 无法区分失败原因，也就无法记录更细粒度日志。

3. 日志缓冲或异步写入

如果系统崩溃或快速重启，部分日志可能未及时刷盘，造成“日志缺失”假象。

4. 事件已配置但日志未关联

事件 Event_CpuBoardAccessFRUableFailure 已定义，但是否启用了 对应组件的日志输出？
检查 component_CpuBoard 是否加载了日志模块或启用 pcall + retry 防护机制（如搜索结果 #3 提及）。

三、关于“修复 Fru 的 Health 属性为 0”的理解

您提到的 MR（Merge Request）应是为了解决：

“某些情况下，即使读取成功，Health 仍被错误地设为 1（Minor）” —— 因此需修复为 0（OK）

但目前问题却是 Health 没有变为 0，说明：

修复 仅适用于正常场景下的状态重置机制
而当前问题 是根本没读到数据，所以 Health 仍为 1（或 2），符合预期设计

即：“修复 Health 为 0” 是事后恢复机制，前提是先能获取数据。

四、建议排查步骤

检查 EEPROM 通信状态
```
i2cdetect -y <bus_id>
i2cget -f -y <bus_id> <device_addr>
```
确认 CPU Board 的 FRU EEPROM 是否在 I2C 上可识别。
查看 frudata 是否收到对象分发
```
busctl tree bmc.kepler.frudata
```
检查是否存在 /bmc/kepler/Systems/1/Frus/Fru_CpuBoard_010101

手动触发 UpdateHealth（测试用）

busctl call bmc.kepler.Systems.FruBoard ... UpdateHealth

增强日志输出
- 修改 frudata 启动参数，加入 --log-level=DEBUG
- 或在 fru_dump.lua 中添加 print() 调试语句
确认 CSR 配置是否完整
查看 CPU Board 对应的 CSR 配置中是否有：
```
"StorageType": "eeprom",
"FruDataId": "FruData_CpuBoard"
```

总结

问题	解答
`UpdateHealth` 由谁调用？	主要由 `frudata` 在读取电子标签失败后调用 `Component_CpuBoard.UpdateHealth()`
何时上报轻微告警？	当 `frudata` 无法获取 CPU 板的电子标签数据（EEPROM 读取失败）时触发
为何没有日志？	可能因日志级别过高、hwproxy 无详细错误、或未启用组件日志
Health 为何不是 0？	因为数据未成功读取，系统认为处于异常状态，故未修复为 0
MR 修复的是什么？	修复的是“本该恢复正常却仍报错”的情况，不是解决读取失败本身

最终建议：
聚焦于 底层 EEPROM 是否可访问 和 frudata 是否正确解析 CSR 配置，这是解决问题的根本方向。

zhangbaocun · 2026 年2 月 27 日 13:36

这个属性是frudata更新的，属于开源组件，可以看一下源码

l00012320 · 2026 年2 月 28 日 01:41

FruData内的更新入口是一个方法,UpdateHealth,但是方法调用的入口不在FruData内,需要帮忙找一下调用这个方法的地方.
要么我看错了,帮忙找一下其它的入口.

KuiTai_FanChunYang · 2026 年2 月 28 日 01:48

这个是会去读fru看是否成功，错误连续读取10次，不成功会把frudata的health置为1。fru对象的health是在关联的cpuboard有告警时会变为1，更新frudata的health代码就在frudata这个组件的

l00012320 · 2026 年2 月 28 日 01:54

我看代码,Fru的Health更新只有ImplComponentComponentUpdateHealth与update_fru_health这两个函数处,但是最终都是关联到入口的方法ImplComponentComponentUpdateHealth这里啊,没有见到你说的关联CpuBoard有告警,或者连续读取10次什么的
方便帮忙捋一下具体更新的逻辑吗

l00012320 · 2026 年2 月 28 日 01:56

噢看见了,十二月更新的代码里有==

l00012320 · 2026 年2 月 28 日 02:06

我们的代码是基于frudata/1.70.39这个版本来的,没有带上这个十二月份的需求,不是从这里进行更新的.而且这里更新的是Frudata的Health,是一个新增属性,也不是Fru本身的Health. 更新FRU的入口依然只有update_fru_health, 麻烦再帮忙看下呢

spjisgood_2lbdb · 2026 年2 月 28 日 02:07

可以参考下春阳的帖子喲

l00012320 · 2026 年2 月 28 日 02:11

看下我上面的答复,我们的代码是基于frudata/1.70.39这个版本来的,没有带上这个十二月份的需求,不是从这里进行更新的.而且这里更新的是Frudata的Health,是一个新增属性,也不是Fru本身的Health. 更新FRU的入口依然只有update_fru_health

春阳那个应该不是更新Fru的入口,还是得再帮忙找下.目前只能看见这个方法调用.

spjisgood_2lbdb · 2026 年2 月 28 日 02:40

产生精细化告警的时候

会更新fru健康状态

参考春阳的帖子意思是你们是同一个问题

l00012320 · 2026 年2 月 28 日 02:45

不是啊,精细化告警的Reading关联的是FRU的Health,怎么会是产生精细化告警后,再反过来更新Health状态呢,这不可能啊.

是先有FRU属性发生变更,产生精细化告警的.

KuiTai_FanChunYang · 2026 年2 月 28 日 07:10

所以这里配置错了呀，要改成frudata的health

l00012320 · 2026 年2 月 28 日 07:41

大概流程是, Scanner状态异常,触发CpuBrd过温告警, Component_CpuBoard状态变为异常,然后Event(闭源)组件修改关联的FRU的状态为异常,从而触发Fru_CpuBoard.Health异常,最终导致产生电子标签告警.

但是关联Fru_CpuBoard.Health,同时又关联Component_CpuBoard,会导致异常状态无法消除.

所以根因在于过温告警的产生,而不是Elabel的状态异常.

话题		回复	浏览量
【已评审】支持配置电子标签读取失败告警的属性 Interface评审	1	36	2025 年12 月 4 日
请问基于2509的Atlas 300I A2是否有FRU信息？交流互助区提问求助	17	147	2026 年2 月 3 日
Mngmnt Health值没有被同步，或者怎么触发？交流互助区提问求助	1	56	2025 年12 月 8 日
PSU电子标签与FRUDATA组件的电子标签数据同步机制 bmc_core SIG 提问求助	4	81	2025 年12 月 21 日
OS启动/重启阶段，误报Mngmnt Health告警交流互助区提问求助	7	97	2026 年2 月 28 日