yin
(kunlun_yinmengyu)
1
// 此模板仅供参考，如果不适用可以修改
问题描述
南向接口仓component_drivers仓适配的网卡SF400T，LPe32002均出现该问题，BMC重启时概现PCIeDevice，PCIeCard，PCIeNicCard的Position属性为空。
查看南向接口仓创建PCIeNicCard对象在pcie_device组件仓会生成PCIeDevice对象，并且Position属性由资源树向设备树同步，根源在于PCIeDevice的Position获取失败。PCIeDevice对象的Position在初始化阶段阶段从Component对象的Name属性上获取。目前根据添加日志打印，Component对象的Name属性正常，发现在执行self:set_prop(‘Position’, position)前后PCIeDevice的self.mds[‘Position’]仍然为空。概现的setprop设置失败。
setprop前：
pcie_device/src/lualib/device/class/pcie_device.lua
setprop后：
init()函数中属性变化通知：
后续尝试过对self:set_prop(‘Position’, position)添加重试，即写后验证self:get_prop(‘Position’)为空，就重复执行self:set_prop(‘Position’, position)。仍然存在BMC重启时Position为空的情况。
想咨询下为什么只有南向接口中配置的网卡存在这种情况，这种情况应该怎么解决呢？
环境信息
-
操作系统：[如 Ubuntu 24.04]
-
软件版本：[如 OpenUBMC2603]
-
硬件配置：[如 CPU、内存等]
重现步骤
-
[第一步]
-
[第二步]
-
[第三步]
期望结果
[您希望实现什么]
实际结果
[实际发生了什么，包含错误信息]
尝试过的解决方案
[列出您已经尝试过的解决方案及结果]
分析结论
[详细总结您对此问题的分析结论]
答案内容由AI生成，仅供参考：
总结
| 维度 |
详细内容 |
| 根因 |
南向接口网卡的 Position 设置依赖于资源树 Component 对象的 Name 属性，但 BMC 重启期间该对象路径未知或 pcie_device 服务拓扑读取失败，导致 setprop 无效。非南向加载（如 VPD）使用静态数据，故不受影响。 |
| 解决方向 |
① 等待 Component 对象就绪；② 通过 CSR 静态定义位置；③ 利用 PCIeNicCard 自身位置信息；④ 强化异常处理与降级；⑤ 调整初始化顺序。 |
| 关键引用 |
- 文档块2：Unknown object path /bmc/kepler/Systems/1/Components/Component_ComPCIeCard1_0101010D02
- 知识图谱：PCIeDevice Object 由 CSR 定义属性；pcie_device 服务获取 Name 失败
- 搜索到的结果2：南向加载与 VPD 加载的稳定性差异，以及对异常处理的疑问 |
通过上述针对性调整，可大幅减少 BMC 重启时南向网卡 Position 属性获取失败的概率。若需要更深度的细节（如具体 CSR 修改示例或代码等待逻辑），可进一步参考 openUBMC 组件开发文档或联系 component_drivers 维护团队。
点击此处查看详细分析解答
问题原因分析
根据提供的知识图谱和文档块信息，该问题源于南向接口适配网卡在BMC重启时，PCIeDevice 对象的 Position 属性依赖的资源树 Component 对象路径不可用，导致 setprop 设置失败。具体分析如下：
-
位置信息来源的依赖关系
- PCIeDevice 对象的 Position 属性在初始化阶段从 Component 对象的 Name 属性获取（用户描述）。
- 知识图谱中实体
Component_ComPCIeCard1_0101010D02 是一个组件对象，其在资源树中的路径为 /bmc/kepler/Systems/1/Components/Component_ComPCIeCard1_0101010D02。
- 文档块2的错误日志明确显示：
Object Event_PCIeRAIDCardFault_0101010D02's property Component access referenced object's property Name failed, err: org.freedesktop.DBus.Error.UnknownObject: Unknown object path /bmc/kepler/Systems/1/Components/Component_ComPCIeCard1_0101010D02
说明 Component 对象路径在 BMC 启动时未注册或不存在，导致引用属性失败。
-
pcie_device 服务初始化异常
- 知识图谱中多个关系指出，
bmc.kepler.pcie_device 服务在启动时无法获取 PCIe 卡的 Name 属性，原因是未知对象路径（如 PCIeCard_1_0101010104、PCIeCard_1_0101010106）。
- 文档块2同样记录了
pcie_device ERROR: topo_reader.lua(147): [BizTopoMonitor] read topo info fail，表明拓扑信息读取失败，直接影响 PCIe 卡的位置信息获取。
- 南向接口适配的网卡依赖
pcie_device 组件生成 PCIeDevice 对象并同步位置数据，而该组件在 BMC 重启初期可能因 DBus 对象未就绪或拓扑读取失败而无法正确设置 Position。
-
南向加载与非南向加载的差异
- 搜索到的结果2描述了同类问题：走南向加载时重启 OS 后网卡温度获取不到，而走 VPD 加载则正常。这提示南向加载的初始化过程存在时序敏感、容错性差的问题。
- 其他加载方式（如 VPD 加载）可能直接从 CSR 或设备树预定义数据中获取位置信息，不依赖动态解析 Component 对象，因此状态稳定。
-
setprop 失败的本质
- 用户在
self:set_prop('Position', position) 前后发现 self.mds['Position'] 仍为空，即使添加重试也未能解决。
- 这很可能是因为底层的 DBus 调用因目标对象路径不存在而静默失败（类似文档块2中
org.freedesktop.DBus.Error.UnknownObject 错误），导致写操作未生效。
解决方案建议
基于上下文中的线索，可以采取以下措施解决（或规避）该问题：
1. 确保 Component 对象就绪后再设置 Position
- 在 PCIeDevice 对象初始化时，增加等待/重试机制，使用条件循环检测 Component 对象是否已在资源树中注册（如通过
busctl 或 lsobj 检查路径存在性），确认后再执行 setprop。
- 可参考文档块2中事件注册失败的处理：当发现对象路径未知时，先等待对象创建完成，避免过早写入。
2. 直接从 CSR 或设备树静态配置 Position
- 知识图谱中明确：CSR files define PCIeDevice objects to describe device attributes such as slot and type in openUBMC（PCIeDevice Object 实体）。
- 建议在网卡的 CSR（Component Self-description Record）文件中固定 PCIeDevice 对象的 Position、Slot 等属性，使其不依赖运行时从 Component.Name 解析。
- 这类似于文档块3中 aliens_to_mars 提出的“通过自己增加卡的 csr 配置，确定卡默认速率”的思想，可类比用于位置信息。
3. 从 PCIeNicCard 对象直接获取位置信息
- 南向接口创建 PCIeNicCard 对象时，通常已知道网卡插入的物理位置（如槽位号）。可以在 PCIeNicCard 对象中保存 Slot 或 Position 属性，然后让 PCIeDevice 对象直接从同路径的 PCIeNicCard 对象继承位置数据，避免跨树依赖。
- 文档块1中 xushuo25 提到：“南向组件的 PCIeNicCard 对象获取到值后会同步到资源树上的 NetworkAdapter 对象”，说明同步机制存在，但 Position 同步同样需要确保数据源可靠。
4. 完善异常处理与降级逻辑
- 搜索到的结果2末尾提出了关键问题：“南向加载代码是不是需要对传入做异常处理”。
- 建议在
setprop 失败时采用降级策略：
- 读取失败后，尝试使用默认位置值（如 0）或从其他可靠接口（如
/redfish/v1/Chassis/1/PCIeDevices/PCIeCardN 中的 Location 字段）回退。
- 同时记录告警日志，提示位置信息未正确获取，避免系统后续依赖错误位置（如带宽告警）。
5. 调整组件启动顺序
- 确保
pcie_device 服务在 component_drivers 和资源树基础对象创建完成之后再启动。
- 知识图谱中
bmc.kepler.pcie_device 被描述为“remote service”，其启动顺序可能影响对 Component 对象的访问。可以通过系统服务依赖或启动脚本来串行化初始化流程。
总结
| 维度 |
详细内容 |
| 根因 |
南向接口网卡的 Position 设置依赖于资源树 Component 对象的 Name 属性，但 BMC 重启期间该对象路径未知或 pcie_device 服务拓扑读取失败，导致 setprop 无效。非南向加载（如 VPD）使用静态数据，故不受影响。 |
| 解决方向 |
① 等待 Component 对象就绪；② 通过 CSR 静态定义位置；③ 利用 PCIeNicCard 自身位置信息；④ 强化异常处理与降级；⑤ 调整初始化顺序。 |
| 关键引用 |
- 文档块2：Unknown object path /bmc/kepler/Systems/1/Components/Component_ComPCIeCard1_0101010D02
- 知识图谱：PCIeDevice Object 由 CSR 定义属性；pcie_device 服务获取 Name 失败
- 搜索到的结果2：南向加载与 VPD 加载的稳定性差异，以及对异常处理的疑问 |
通过上述针对性调整，可大幅减少 BMC 重启时南向网卡 Position 属性获取失败的概率。若需要更深度的细节（如具体 CSR 修改示例或代码等待逻辑），可进一步参考 openUBMC 组件开发文档或联系 component_drivers 维护团队。
检查一下是否position配置为了Scanner，导致无法赋值
yin
(kunlun_yinmengyu)
4
没有配置scanner，这是一个偶现问题，大概4/100的概率
yin
(kunlun_yinmengyu)
8
参考修改进行验证，跑长时间BMC重启验证，仍然存在问题，概率5/500。
查看问题日志信息，情况与之前一致，对应RiserCard的Component_RiserCard_01010103.Name=PCIeRiser1，PCIeDevice,PCIeCard，PCIeNICCard的Postion属性均为空。
yin
(kunlun_yinmengyu)
9
使用反合了630版本的分支去跑长时间 200次没出现该问题，该问题还有其他相关的pr修改嘛
