component_drivers组件“支持插件机制”修改会影响smbus功能的使用

交流互助区
1

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

问题描述

本地component_drivers组件合入“支持插件机制”这笔修改后，测试发现smbus endpoint创建失败，devmon topology也没有添加

1780564810900_5687B4C0-54F1-4d35-89A9-BEEA10DB95E9
1780564810900_5687B4C0-54F1-4d35-89A9-BEEA10DB95E91104×549 42.5 KB

环境信息

  • 基于鲲鹏920服务器，网迅25Ge网卡（over pcie），网迅10Ge网卡（over smbus），网迅1Ge网卡（over smbus）

重现步骤

  1. [第一步]

  2. [第二步]

  3. [第三步]

期望结果

三张网卡的endpoint都成功创建，并且带外ncsi正常交互

实际结果

只有25Ge网卡的pcie endpoint成功创建，10Ge网卡和1Ge网卡都创建失败了。查看app.log报错如下

lQLPKG2FNf6K5C_NAovNAzawOMOZRBZlvqEJ9gMKMiQbAA_822_651
lQLPKG2FNf6K5C_NAovNAzawOMOZRBZlvqEJ9gMKMiQbAA_822_651822×651 26 KB

尝试过的解决方案

revert这笔修改后重新出包，测试结果一切正常，三张网卡的endpoint都成功创建，并且带外ncsi交互正常。

分析结论

[详细总结您对此问题的分析结论]

2

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

3. 结论总结

“支持插件机制”的修改引入了新的插件加载、注册或通信框架，但未对原有的 SMBus 协议处理流程进行完整、兼容的适配。这导致 SMBus 相关的 MCTP 请求在执行过程中出现逻辑错误或通信失败，最终使得 SMBus Endpoint 无法被创建和注册到系统中。

该修改破坏了 component_drivers → devmon → mctpd 之间关于 SMBus 协议的调用链和 DBus 通信协议。回退此修改后，旧的、未经插件化改造的 SMBus 处理流程得以恢复，因此问题消失。

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

问题分析结论

根据您提供的信息，并结合知识库中关于 component_drivers 组件、MCTP over SMBus 以及相关日志的分析，得出如下结论：

1. 问题根因定位

本次“支持插件机制”的代码修改，对 component_drivers 组件中与 SMBus 协议交互的关键路径产生了影响，从而破坏了 SMBus MCTP Endpoint 的完整创建流程。

具体来说，问题发生在插件化框架适配过程中，可能导致以下场景：

  • SMBus 协议处理插件未能正确注册或加载：知识库提到，SMBus 通信依赖于特定的协议插件（如 smbus、smbus_postbox 等）。新的插件机制可能未正确地将原有的 SMBus 处理逻辑包装成兼容的插件形式，导致 SMBus OEM 请求无法被正确解析和执行。
  • 插件请求执行失败：日志中出现的 lua_engine.cpp(1198): plugin request completed, plugin: smbus, cmd: process smbus oem req, success: false 明确指示了 SMBus 插件请求执行失败。这表明在插件化架构下，component_drivers 向 devmon 发起的 SMBus OEM 请求未能成功完成。
  • DBus 协议栈处理异常：日志中的 dbus_proto.cpp(459): dbus_proto inbound pop threw: invalid error name: method_call 说明，在插件请求响应后，DBus 消息解析出现错误，这可能是因为新的插件机制改变了数据传输的格式或流程，导致 DBus 无法正确反序列化响应消息。

2. 失败流程分析

事件发展链条如下：

  1. Endpoint 创建触发：BMC 启动后，devmon 尝试为 10Ge 和 1Ge 网卡创建 SMBus MCTP Endpoint。
  2. MCTP 请求被拦截：devmon 通过 mctpd 主服务向硬件发送消息，但根据知识库，此过程可能需要调用底层的 SMBus 协议插件。
  3. SMBus 插件执行失败：由于新的“支持插件机制”修改，SMBus 插件处理 process smbus oem req 命令失败（success: false）。
  4. DBus 消息解析错误：插件执行失败后，其错误响应可能没有遵循新的 DBus 通信协议规范，导致后续的 DBus 消息解析器抛出 invalid error name: method_call 错误。
  5. Endpoint 创建最终失败：mctpd 或 devmon 未能收到有效的 MCTP 响应，因此无法完成 Endpoint 创建。日志中反复出现的 Get endpoint object failed 和 create_endpoint failed 证实了这一点。
  6. PCIe 路径不受影响：25Ge 网卡使用 PCIe VDM 协议，其处理路径完全独立于 SMBus 协议栈，因此本次修改未对其造成影响。

3. 结论总结

“支持插件机制”的修改引入了新的插件加载、注册或通信框架，但未对原有的 SMBus 协议处理流程进行完整、兼容的适配。这导致 SMBus 相关的 MCTP 请求在执行过程中出现逻辑错误或通信失败，最终使得 SMBus Endpoint 无法被创建和注册到系统中。

该修改破坏了 component_drivers → devmon → mctpd 之间关于 SMBus 协议的调用链和 DBus 通信协议。回退此修改后，旧的、未经插件化改造的 SMBus 处理流程得以恢复，因此问题消失。

建议排查方向

  1. 审查“支持插件机制”的代码逻辑：重点检查 component_drivers 组件中关于 SMBus 协议插件的定义、注册、加载和生命周期管理代码，确保原有的 SMBus 处理函数被正确封装为插件。
  2. 检查 SMBus 插件接口定义：确认新的插件接口 (protocol) 是否完全兼容老版本 SMBus OEM 请求的参数和返回格式。
  3. 验证 DBus 协议交互：检查 devmon 的 dbus_proto.cpp 中，是否对新引入的插件化机制带来的消息格式或错误处理方式进行了必要的适配。
3

新提了一个pr, 你们可以用这个pr出包来跑下, 我们这边修改时没有你们这样的完整环境, 测试时没能覆盖全部场景. 如果使用这个pr复现了的话, 还请帮忙把app.log或者截图贴一下, 我这边分析下.

4

不好意思，这个版本component_drivers依赖的libmcpp和devmon组件版本是多少，我本地依赖1.2.92版本libmcpp和1.2.37版本devmon出包运行devmon服务有点问题

5

我这边使用的是libmcpp版本是1.2.116本地编译的, devmon版本是1.2.43

建议使用devmon的main版本, 然后使用-o unidev=True参数出包 (如果不行, 可以使用1.2.43版本`7286493691bb9e787656120db9834cd785bae555`, 将meson_options.txt中three_layer_arch配置为true再次出包)

出整包时，在manifest中的launch_control.json文件中删除hwproxy和hwdiscovery组件启动配置， 并使用-t target_personal参数出包

7

如果复现的话, 麻烦把log贴下, 我来定位下..

8

不好意思，昨天压缩包贴到回复里了，但现在还在审批，要不您发一下你邮箱，我邮件发您。

9

邮箱是changjunyang @ byosoft.com.cn

10

好的，邮件发您了，注意查收。

11

好的

12

您好，想问下您指的删除组件启动配置，是指删除截图中这两个吗？

我这边删除这两个后，使用“bingo build -t target_personal”出包，服务器telnet连接不上，web也是；也尝试了只使用bingo build出hpm包，现象也是一样的，telnet/ssh/web都连不上

image
image1156×597 31.4 KB

13

您好，复现后的日志通过邮件发您了，注意查收。