DiscreteSensor状态初始化异常

[l00012320 (kunlun_luzhanghui)]

问题描述

PCIe Card BBU读值概率为NA，预期为0.

正常读值:

环境信息

• 软件版本：[openUBMC 25.12 LTS SP1]
  sensor/1.71.1.001@openubmc.dev/dev#d23671e26ff616fe5c2c4e3727225a6f%1775716355.9888885

重现步骤

OS下电后重启BMC，概率性产生状态为NA，产生NA后上电不会恢复。

期望结果

状态正常，读值正常显示。状态正常显示。

实际结果

OS下电后重启BMC，概率性产生状态为NA，产生NA后上电不会恢复。

分析结论

DiscreteSensor初始化关联Entity对象，存在时序问题，导致大量Sensor状态与代码配置不符。
传感器状态关联mdb_obj的EntityID与EntityInstance，host_id一般为0.

但是加打印后发现，会出现大量的[0|0|0]场景，而EntityInstance的默认值为96

查看sync_property_trace.log后发现，DiscreteSensor对象初值就绪概率性晚于代码初始化。

这里会导致问题1：代码找不到Entity对象时默认Sensor Enable，下电状态下预期被禁用的传感器，依然为Enable，可能导致误产生SEL。

问题2：RAID卡类似的PCIe设备，拓扑关系较长，无法获取整机PowerState，从而配死为1，但是Id与Instance也配死会导致关联到其它Entity（因为问题1，Entity部分没初始化完成），从而获取到不符合预期的Status。又由于PowerState与Presence配死，无法在后续OS上电时触发Listen函数，从而导致问题描述的问题发生。

如图，PSBoard的Id与RAID一致，EntityID默认为96，与RAID冲突，先注册了，导致RAID卡关联的Entity变为了PSBoard，获取到了不符合预期的PowerState

后续Entity更新正确后，Entity_RAIDCard的PowerState不会变更，导致对应的DiscreteSensor状态不会恢复，从而一直出现此问题。

诉求

希望有一个比较好的解决此问题的方法。
目前可以手动修改RAID卡的EntityInstance、ID或者把Capability去掉禁用标志，但感觉治标不治本。

[ubmc_assistant (openUBMC_Assistant)]

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

总结

项目	内容
问题本质	DiscreteSensor 初始化过早，Entity 对象尚未注册，导致绑定失败
核心原因	对象初始化时序混乱 + Entity ID 冲突 + PowerState 静态固化
短期方案	修改 Instance、Capabilites，避免冲突与误判
长期方案	引入依赖管理、动态状态监听、事件驱动初始化机制

建议推动架构优化：将 DiscreteSensor 创建流程从“静态同步加载”改为“事件驱动异步加载”，从根本上解决时序问题，提升系统健壮性与可观测性。

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

DiscreteSensor 状态初始化异常问题分析与解决方案

---

问题描述

在 openUBMC 25.12 LTS SP1 环境下，PCIe Card BBU 的 DiscreteSensor 读值存在概率性为 NA，预期值应为 0。该问题在 OS 下电后重启 BMC 时概率性出现，且一旦出现，在后续上电过程中无法自动恢复。

系统日志和传感器数据显示：

• 正常时：PCIe4 Card BBU 状态为 0x0，Reading 值为 0。
• 异常时：状态显示为 na，Raw Value 为 0x8000，Reading 显示 na。

---

根本原因分析

根据提供的日志、代码片段及系统行为分析，问题源自 DiscreteSensor 初始化过程中的对象关联时序问题，具体表现为以下两个层面：

1. Entity 对象初始化滞后导致 Sensor 初始化失败

DiscreteSensor 需要通过 EntityId 和 EntityInstance 与物理实体（如 RAID 卡、主板等）进行绑定，其初始化流程依赖于 Entity 对象的先期注册完成。

• 日志 sync_property_trace.log 显示：

  DiscreteSensor Watchdog2_00 EntityInstance: 96  
  $1: bmc.kepler.sensor ... sig_interfaces_added, 96
  

  表明 Entity 的 Instance 属性是在 DiscreteSensor 初始化之后才被赋值，存在明显的 时序错位。

• 在 sensor_instance:init_disp_status() 函数中，若传入的 data.id 或 data.instance 为 0，会触发默认返回 SCAN_ENABLED：

  if not data.id or not data.instance or not data.host_id then
      return utils.SCAN_ENABLED  -- 默认启用，导致误判
  end
  

  当 EntityId=0 或 EntityInstance=0 时，返回 status=1（即 SCAN_FAILURE），最终导致传感器状态异常、读数 NA。

关键点：EntityInstance 的 CSR 默认值为 96，但实际运行中却出现 [0|0|0] 场景，说明对象未完成初始化即被访问。

---

2. 拓扑冲突与 PowerState 固化问题

对于 PCIe RAID 卡等复杂设备，其 Entity 对象拓扑链较长，初始化耗时更久。而当前配置存在以下缺陷：

（1）Entity ID/Instance 配置冲突

• 多个设备（如 PSBoard 与 RAIDCard）使用了相同的 EntityId 和默认 Instance=96。
• 先注册的设备（如 PSBoard）占用了标识，导致 RAIDCard 关联到了错误的 Entity。
• 结果：RAIDCard 的 DiscreteSensor 获取了 PSBoard 的 PowerState，造成状态误判。

（2）PowerState 与 Presence 被“配死”为 1

• 由于无法动态获取整机 PowerState，部分配置将 PowerState 和 Presence 强制设为 1（始终在线）。
• 导致即使后续正确的 Entity_RAIDCard 初始化完成，也不会触发监听更新机制（如 Listen 事件），DiscreteSensor 状态无法重新同步。

（3）Capabilities 配置加剧问题

• Capabilities 字段中若设置了 [7]=1b（即“当实体不在位或禁用时忽略传感器”），则传感器是否启用依赖于 Entity 的 Presence 与 PowerState。
• 若 Entity 初始化失败或绑定错误，此处逻辑将失效，进一步加剧状态异常。

---

影响与风险

问题	风险
传感器读值为 NA	监控缺失，无法判断硬件状态
状态异常无法自恢复	需手动干预或重启 BMC
误判为 Enabled	可能触发错误 SEL 日志或告警
实体绑定错误	多设备冲突，系统可观测性下降

---

解决方案建议

短期缓解措施（临时可用）

1. 调整 RAIDCard 的 EntityInstance 值

   • 修改 SR 配置，确保 RAIDCard 使用唯一且非默认的 Instance 值（如 100），避免与其他设备冲突。

   "EntityInstance": "100"
   

2. 禁用 Capabilities 的忽略逻辑

   • 修改 Capabilities 字段，将 bit7 设为 0b，避免因 Entity 状态异常导致传感器被禁用：

   "Capabilities": 64  // 而非 192（bit7=1）
   

3. 增加初始化重试机制

   • 在 init_disp_status() 中对 get_status 失败的情况加入延迟重试（如最多重试 3 次，间隔 1s），等待 Entity 完成注册。

---

长期根本性解决方案

1. 引入 Entity 初始化依赖机制

• 在 CSR 层面支持 对象依赖声明，例如：

  "DiscreteSensor_PcieBBU": {
      "depends_on": "/Entity_RAIDCard",
      "EntityId": "<=/Entity_RAIDCard.Id",
      "EntityInstance": "<=/Entity_RAIDCard.Instance"
  }
  

• BMC 系统应在 Entity_RAIDCard 完全初始化后再创建该 DiscreteSensor 实例。

2. 改进 Entity Management 框架

• 实现 Entity 对象的 就绪状态通知机制（如 sig_entity_ready）。
• sensor 模块监听此信号，仅在收到通知后执行初始化，避免竞态。

3. 动态 PowerState 更新机制

• 不再将 PowerState 和 Presence 硬编码为 1，而是通过监听硬件事件（如 PCIe Link Up、电源状态变更）动态更新。
• 支持 Listen 事件在 Entity 属性变更时被重新触发，恢复传感器状态同步。

4. 增强日志与诊断能力

• 记录 DiscreteSensor 初始化时的完整上下文（EntityId, Instance, host_id）。
• 添加专门的调试命令，用于查询当前 Sensor 与 Entity 的绑定关系是否正确。

---

总结

项目	内容
问题本质	DiscreteSensor 初始化过早，Entity 对象尚未注册，导致绑定失败
核心原因	对象初始化时序混乱 + Entity ID 冲突 + PowerState 静态固化
短期方案	修改 Instance、Capabilites，避免冲突与误判
长期方案	引入依赖管理、动态状态监听、事件驱动初始化机制

建议推动架构优化：将 DiscreteSensor 创建流程从“静态同步加载”改为“事件驱动异步加载”，从根本上解决时序问题，提升系统健壮性与可观测性。

[l00012320 (kunlun_luzhanghui)]

加打印后的一键收集：
KunLun2180V2_123456_20260409-1953.tar.zip.002.txt (6.7 MB)
KunLun2180V2_123456_20260409-1953.tar.zip.001.txt (7.6 MB)

[duzhou13_51cdj (wanghaozhou)]

当前社区sensor组件实现：
1、保障了sensor对象一定是在关联的Entity对象注册后才会注册，那么Entity初始化时无需主动更新sensor的状态，而sensor初始化状态时也一定能获取到对应Entity的状态
2、针对概率性sensor注册时对应的Entity的Instance属性值还未更新为最新的结果，导致sensor获取状态时匹配到错误的Entity问题，当前也已修复，见 修复风扇传感器关联风扇可能错误的问题