关于FC卡的两个问题求助

[cake]

问题描述

1.BMC下FC卡光模块信息与OS下使用hbacmd工具查询到的不一致，该问题在社区中已有人提出：https://discuss.openubmc.cn/t/topic/4135

使用hbacmd 14.2.455.10版本，iBMA使用2.16、2.17、2.19版本均可正确显示hba卡光模块信息。

最新版本iBMA是有什么问题么，什么时候能修复

2.FC卡BMC上的自协商字段显示不正确

FC卡的自协商字段在BMC上显示值为默认值，不会随着修改而更新，定位到该信息获取来源为BMA，而修改BMA白名单后发现，返回给BMC的数据中无自协商字段：

BMA不能获取FC卡的自动协商字段是否符合预期

[ubmc_assistant (openUBMC_Assistant)]

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

总结

问题	是否存在问题	成因	是否符合预期	建议
光模块信息不一致	是	iBMA采集逻辑或协议解析异常，CustomReadInfo可能返回无效值	否	核查BDF配置、收集One-Click Log、反馈至社区跟踪修复进度
自协商字段缺失	否	FC卡本身不适用“自协商”概念，BMA未设计返回该字段	是	不建议强制添加，可考虑引入“速率模式”替代表述

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

关于FC卡相关问题的分析与解答

根据您提出的两个FC卡相关问题，结合知识库中的信息，现进行如下整理和解答。

问题一：BMC下FC卡光模块信息与OS下不一致

问题描述

在BMC侧通过iBMA获取的FC卡光模块信息（如温度、告警阈值等）与操作系统侧使用hbacmd工具查询的结果存在差异。具体表现为：

• 光模块当前温度显示为负数（例如：-47.88℃）
• 告警阈值数据异常
• iBMA发送的数据与OS实际不符

该问题已在社区（https://discuss.openubmc.cn/t/topic/4135）中被提出。

分析与结论

1. 问题成因
   根据文档《南向网卡驱动适配指南》和《网卡开发指南》可知：

   • 光模块信息获取依赖于协议通信，不同网卡厂商可能采用不同协议（如I²C、MCTP、NC-SI over MCTP等）。
   • 对于FC卡（如LPe32002-AP），其信息采集路径分为两个层面：
     • 带外（Out-of-Band）方式：由BMC通过iBMA服务采集，依赖于PCIe设备配置文件（CSR/DDS）和特定协议访问；
     • 带内（In-Band）方式：操作系统通过hbacmd等工具直接读取驱动或硬件寄存器信息。
   • 已知存在iBMA上报数据与硬件实际不匹配的问题，需检查PcieAddrInfo对象配置是否与硬件BDF信息一致（可通过lspci命令验证）。

2. 异常数据来源分析

   • 知识图谱中提到：“CustomReadInfo是用于从硬件读取数据的函数，但有时会返回无效数据”，且“BMC依赖此接口，可能导致读取失败。”
   • 文档《network_adapter》说明：某些网卡支持通过SMBus获取光模块信息，但FC卡未来计划通过PLDM over MCTP获取带外信息，目前可能尚未完善。
   • 因此，当前iBMA在解析光模块诊断信息（SFF Diagnostics）时可能存在协议解析错误或缓存机制缺陷，导致上报错误值。

3. 版本兼容性说明

   • 用户反馈使用hbacmd 14.2.455.10及iBMA 2.16/2.17/2.19版本可以正常显示信息，说明新版本iBMA可能存在回归问题。
   • 尽管具体修复时间表未在知识库中提及，但从问题模式来看，属于可复现的数据采集偏差问题，通常会被列为中高优先级进行修复。

4. 临时解决方案建议

   • 核查系统中PcieAddrInfo对象配置是否与实际硬件BDF一致；
   • 收集“One-Click Log”日志以辅助诊断（参考Huangminghao在社区中建议的做法）；
   • 比对操作系统下ethtool -m或hbacmd输出的原始SFF数据，确认是否为解析层问题。

---

问题二：FC卡自协商字段在BMC侧未更新

问题描述

FC卡的“自协商”（Auto Negotiation）状态在BMC Web界面显示为默认值，不会随配置更改而变化。进一步定位发现：

• 信息来源于BMA；
• 修改BMA白名单后，返回给BMC的数据中无AutoNegotiation字段；
• Redfish接口返回的OEM JSON中也缺失该字段。

分析与结论

1. FC卡自协商机制现状

   • 根据Redfish API模型及知识库内容，BMC通过bmc.kepler.Systems.NetworkPort接口管理网口属性。
   • NetworkPort接口包含以下相关属性：
     • AutoSpeedNegotiation: 是否启用自协商；
     • SpeedMbps: 当前链路速率；
     • LinkStatus: 物理链路状态。
   • 但对于Fibre Channel卡，由于其工作在固定速率模式（如32Gbps），通常不支持以太网意义上的“自协商”，而是依赖于Fabric端口的速率协商（例如Auto/16G/32G）。

2. 为何BMA未返回自协商字段？

   • 设计预期行为：根据文档《网卡开发指南》和《南向网卡驱动适配指南》，目前iBMA主要关注以下信息：
     • 厂商信息、型号、固件版本；
     • MAC地址、WWPN/WWNN；
     • 光模块状态（温度、功率）；
     • 链路状态和速率。
   • 自协商字段并未列入标准字段集，尤其对于Fibre Channel设备，自协商不是一个标准属性，因其链路建立机制不同于以太网。
   • 另外，《网卡开发指南》明确指出：“网口自协商状态”属于可选查询项，且仅适用于支持自协商的NIC网卡，FC卡属于特殊类型网卡，默认不提供该字段。

3. 是否符合预期？
   是的，BMA不返回自协商字段是符合当前设计预期的。

   原因如下：

   • FC协议本身不定义“自协商”这一概念，其速率协商是通过E-Port或F-Port的FLOGI/PLOGI过程完成；
   • 当前BMC系统中对网络端口的抽象以以太网为主，Fibre Channel是作为扩展支持；
   • 若需获取类似信息，应关注PhysicalPort.LinkSpeed字段（如32Gbps）以及PortType（如Point-To-Point）。

4. 改进建议

   • 如有业务需求需展示FC卡的“协商模式”或“速率能力”，建议：
     1. 在BMA侧扩展采集逻辑，获取HBA卡的Link Speed Capability（支持速率）；
     2. 在BMC侧通过Redfish扩展属性或UI自定义字段呈现为“速率模式”而非“自协商”；
     3. 调整UI语义，避免将“自协商”误用于FC场景。

---

总结

问题	是否存在问题	成因	是否符合预期	建议
光模块信息不一致	是	iBMA采集逻辑或协议解析异常，CustomReadInfo可能返回无效值	否	核查BDF配置、收集One-Click Log、反馈至社区跟踪修复进度
自协商字段缺失	否	FC卡本身不适用“自协商”概念，BMA未设计返回该字段	是	不建议强制添加，可考虑引入“速率模式”替代表述

---

附加建议

1. 提交Issue进行跟踪

   • 可在openUBMC平台提交Issue，标题为：“【Bug】iBMA上报FC卡光模块信息异常（温度负值）”
   • 描述中引用社区链接、附上One-Click Log和busctl读取的D-Bus路径数据。

2. 使用D-Bus直接验证
   您可以通过以下命令查看实际D-Bus接口数据：

   busctl introspect bmc.kepler.sms /redfish/v1/Systems/1/Storage/1/FC/<BDF>/Sff/Diagnostic
   

   对比TempCurrentCelsius, RxPower*等值是否一致。

3. 联系贡献者协助

   • 社区中Huangminghao曾多次处理类似RAID卡与BMA通信问题，可邀请其参与分析。

如后续有更多日志或调试信息，欢迎进一步补充，以便深入定位。

[huangliang]

补充一个截图：FC卡自协商信息显示 BMC和OS不一致

[cake]

问题一：

博通和ibma工具版本：

开启BMA的debug日志后，收集文件：(需要修改文件后缀为tag.gz后解压)

ibma_log.txt (45.7 KB)

[fantao]

问题2已修复，问题1需要iBMA的同学解答

[cake]

问题1我们已经和产品pae沟通提需求了

问题2你们是在哪个版本做修复的呢

[fantao]

社区最新network_adapter代码已修复