走南向加载的SP670、SP681网卡端口属性里的总线信息是0000:00:00.0，并非实际值

交流互助区
1

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

问题描述

走南向加载的SP670、SP680网卡端口属性里的总线信息是0000:00:00.0，并非实际值

环境信息

  • 软件版本：OpenUBMC2603

重现步骤

1、两张网卡按照2603走南向加载，总线信息就是0000:00:00.0

期望结果

预期总线信能正常显示

实际结果

显示0000:00:00.0

image
image1252×793 27.5 KB

尝试过的解决方案

1、改回走VPD加载，总线信息可正常显示

img_v3_02137_58f8f2b0-03ff-47ca-b43d-19b1aee97f8g
img_v3_02137_58f8f2b0-03ff-47ca-b43d-19b1aee97f8g1290×776 136 KB

2、走南向加载的时候，在card_update_identifier.lua的card_update_identifier.update_port_bdf里面加调试日志，把val打印出来，发现实际上设置成功了

image
image711×275 153 KB

3、但是mdbctl查属性还是0，所以web上显示不正确

image
image534×306 88.1 KB

分析结论

走南向和走vpd的差异性在哪里，南向有问题，vpd没问题

2

答案内容由AI生成，仅供参考：
根据您提供的问题描述及上下文信息，现对“走南向加载的SP670、SP681网卡端口属性总线信息显示为0000:00:00.0，而改走VPD加载正常”这一现象进行分析。以下回答严格基于知识图谱、文档块和搜索结果中的内容。

问题分析

从上下文可知，SP670、SP681网卡在 OpenUBMC 2603 版本中，走南向驱动加载时，端口总线信息未能正确显示，而回退到 VPD（重要产品数据）加载 后恢复正常。关键差异点可能源于两种加载方式使用的 CSR（配置空间寄存器）版本 不同，以及 对象模型加载完整性 的差异。

差异根源：CSR 版本与管理路径

1. CSR 版本并存机制

根据文档 openUBMC RAID南向部件驱动特性设计说明书.md 的描述：

  • 南向驱动CSR（5.0） 与 历史应用层CSR（3.0） 在代码仓中并存。
  • 通过 VPD打包策略 决定实际加载哪种CSR：
    • 加载历史CSR（3.0）→ 走应用层管理路径（即传统的VPD加载方式）。
    • 加载南向驱动CSR（5.0）→ 走南向驱动管理路径。

因此， VPD加载 对应的是 历史CSR（3.0） ，而 南向加载 对应的是 南向驱动CSR（5.0） 。两种CSR对端口总线信息的处理逻辑可能存在差异。

2. 南向驱动CSR可能缺少端口总线信息配置

在 SP681网卡异常告警，网卡chip加载问题 中，提到：

  • SP681的CSR中配置了相关chip，但资源树中并没有Eeprom_NetCard、Chip_Hi1822对象。
  • 手动访问EEPROM返回失败，network_adapter也没有任何SP681网卡信息获取相关的打印。
  • 提问：“chip+network_adapter与南向驱动是两个独立的板卡加载、信息获取通道么？”

这暗示 南向驱动加载 可能未能正确创建或初始化与端口总线信息相关的对象（如 Chip_Hi1822、Eeprom_NetCard 等），从而导致端口属性的总线信息字段未被正确填充，最终显示为默认值 0000:00:00.0。

相比之下， VPD加载 使用历史CSR，这些对象（以及对应的总线信息映射）在应用层管理路径中能够正常加载，因此端口总线信息可以正确显示（如在 card_update_identifier.lua 中成功设置，并通过 mdbctl 查询到）。

3. mdbctl属性查询结果为0但日志设置成功

您在调试中发现 update_port_bdf 中的 val 设置成功，但 mdbctl 查属性仍为0。这进一步说明 南向加载时，属性值虽然被写入，但由于对象模型不完整或持久化机制不同，导致最终查询不到正确值 。而VPD加载对应的对象模型完整，属性能被正确持久化和读取。

结论

  • 走南向加载（南向驱动CSR 5.0） 时，端口总线信息缺失的根本原因很可能是：

    • 南向驱动CSR中未配置或未正确映射端口的总线信息字段（如 RootBDF、BDF 等）。
    • 南向驱动加载过程未能完整创建与端口相关的硬件抽象对象（如 Chip、Eeprom），导致属性无法正常更新。
    • 即使代码中尝试设置总线信息，由于对象模型不完整，该值未被持久化或无法通过 mdbctl 正确查询。

  • 走VPD加载（历史应用层CSR 3.0） 时，总线信息正常，说明历史CSR包含完整的端口总线信息配置，且应用层管理路径能正确创建所有必需的对象，确保属性持久化与查询一致。

因此，差异主要体现在 CSR版本选择 导致的 管理路径不同 以及 南向驱动对象模型完整性不足。建议参考南向驱动CSR的设计文档，核对SP670/SP681网卡的CSR中是否包含正确的端口总线信息字段，或通过补充CSR配置/调整对象加载顺序来解决。

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

根据您提供的问题描述及上下文信息，现对“走南向加载的SP670、SP681网卡端口属性总线信息显示为0000:00:00.0，而改走VPD加载正常”这一现象进行分析。以下回答严格基于知识图谱、文档块和搜索结果中的内容。

问题分析

从上下文可知，SP670、SP681网卡在 OpenUBMC 2603 版本中，走南向驱动加载时，端口总线信息未能正确显示，而回退到 VPD（重要产品数据）加载 后恢复正常。关键差异点可能源于两种加载方式使用的 CSR（配置空间寄存器）版本 不同，以及 对象模型加载完整性 的差异。

差异根源：CSR 版本与管理路径

1. CSR 版本并存机制

根据文档 openUBMC RAID南向部件驱动特性设计说明书.md 的描述：

  • 南向驱动CSR（5.0） 与 历史应用层CSR（3.0） 在代码仓中并存。
  • 通过 VPD打包策略 决定实际加载哪种CSR：
    • 加载历史CSR（3.0）→ 走应用层管理路径（即传统的VPD加载方式）。
    • 加载南向驱动CSR（5.0）→ 走南向驱动管理路径。

因此， VPD加载 对应的是 历史CSR（3.0） ，而 南向加载 对应的是 南向驱动CSR（5.0） 。两种CSR对端口总线信息的处理逻辑可能存在差异。

2. 南向驱动CSR可能缺少端口总线信息配置

在 SP681网卡异常告警，网卡chip加载问题 中，提到：

  • SP681的CSR中配置了相关chip，但资源树中并没有Eeprom_NetCard、Chip_Hi1822对象。
  • 手动访问EEPROM返回失败，network_adapter也没有任何SP681网卡信息获取相关的打印。
  • 提问：“chip+network_adapter与南向驱动是两个独立的板卡加载、信息获取通道么？”

这暗示 南向驱动加载 可能未能正确创建或初始化与端口总线信息相关的对象（如 Chip_Hi1822、Eeprom_NetCard 等），从而导致端口属性的总线信息字段未被正确填充，最终显示为默认值 0000:00:00.0。

相比之下， VPD加载 使用历史CSR，这些对象（以及对应的总线信息映射）在应用层管理路径中能够正常加载，因此端口总线信息可以正确显示（如在 card_update_identifier.lua 中成功设置，并通过 mdbctl 查询到）。

3. mdbctl属性查询结果为0但日志设置成功

您在调试中发现 update_port_bdf 中的 val 设置成功，但 mdbctl 查属性仍为0。这进一步说明 南向加载时，属性值虽然被写入，但由于对象模型不完整或持久化机制不同，导致最终查询不到正确值 。而VPD加载对应的对象模型完整，属性能被正确持久化和读取。

结论

  • 走南向加载（南向驱动CSR 5.0） 时，端口总线信息缺失的根本原因很可能是：

    • 南向驱动CSR中未配置或未正确映射端口的总线信息字段（如 RootBDF、BDF 等）。
    • 南向驱动加载过程未能完整创建与端口相关的硬件抽象对象（如 Chip、Eeprom），导致属性无法正常更新。
    • 即使代码中尝试设置总线信息，由于对象模型不完整，该值未被持久化或无法通过 mdbctl 正确查询。

  • 走VPD加载（历史应用层CSR 3.0） 时，总线信息正常，说明历史CSR包含完整的端口总线信息配置，且应用层管理路径能正确创建所有必需的对象，确保属性持久化与查询一致。

因此，差异主要体现在 CSR版本选择 导致的 管理路径不同 以及 南向驱动对象模型完整性不足。建议参考南向驱动CSR的设计文档，核对SP670/SP681网卡的CSR中是否包含正确的端口总线信息字段，或通过补充CSR配置/调整对象加载顺序来解决。

3

能否发一份一键日志收集协助定位呢？

4

已发至邮箱，请查收

5

1.可否在network_adapter组件src/lualib/device/class/nic_mgmt/port_mgmt.lua中的listen_device_obj_property_change和synchronize_property这两个函数中补充日志打印，把orm_obj[prop_table[k]] = value赋值时BDF属性的相关信息打印出来？
2. 【已评审】Endpoint新增调试时打印报文功能 - Interface SIG / Interface评审 - openUBMC 论坛 参照该链接方法抓取一下SP670网卡的ncsi报文内容辅助分析（tracemctp Endpoint_xxx start）

6

1、加打印

img_v3_0213c_cd7cb0d4-eb6f-4b64-a565-dc7d5065729g
img_v3_0213c_cd7cb0d4-eb6f-4b64-a565-dc7d5065729g1126×701 432 KB

img_v3_0213c_efab1c7c-8a79-470a-aeb2-8d39a3bb10dg
img_v3_0213c_efab1c7c-8a79-470a-aeb2-8d39a3bb10dg1124×384 227 KB

7

2、报文已收集发至邮件，请查收

8

你提供的SP681网卡的报文中，获取端口bdf信息的返回报文中（如下），
0A 00 00 12 00 30 00 81 B4 1A 00 03 C0 09 0B 01
02（ncsi协议） 00 01 00 41 D0 01 00 10 00 00 00 00 00 00 00
00（以上16字节为报文头） 00 00（response_code） 00 00（reason_code） 00 00 07 DB（manufacturer_id） 00（reserved） 00（oem_command_id） 01（sub_command_id） 01（reserved_2） 00（reserved） 00（bus） 00（device）
00（function） FF FF 26 D1（check_sum） 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
根据你提供的报文来看，目前已经确定是由于网卡固件返回的BDF均为0，设备树获取到全0
的BDF后同步更新到资源树，将原有的在card_update_identifier.lua中card_update_identifier.update_port_bdf更新的BDF给覆盖掉了。

9

走1.0加载的网卡，它在执行这个函数function c_network_port:update_BDF_by_ncsi()中，判断了 if s and (s.bus ~= 0 or s.device ~= 0 or s.func ~= 0) and self.WorkloadType ~= 1 then带外获取到的值是否为全0，如果全0则不用带外的值更新端口的bdf，因此1.0带外更新没有出现这个问题，资源树上端口bdf是通过function c_network_adapter:update_port_bdf(ports)这个函数更新的正确的值。

10

目前这个问题需要咨询一下182x网卡固件的同事，询问一下为什么带外获取的BDF全为0

11

好的 感谢