LPe32002-AP网卡mctp初始化异常终止问题

liujie_11 · 2025 年12 月 30 日 13:18

基于openubmc 2509版本

测试时发现LPe32002-AP网卡温度未获取：

跟踪代码发现在create_mctp_endpoint时突然终止：
我加的打印如下：

执行结果如下：

在mctpd日志中发现一条报错：这里似乎把该卡的msg_types识别成了0？

且该对象查看报错：

mctp_lib.get_endpoint_and_transport属于闭源sdk，不能继续跟踪，应该是该闭源sdk中出现了死循环或者不可捕捉错误，希望帮忙确认一下原因。

ubmc_assistant · 2025 年12 月 30 日 13:25

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

LPe32002-AP 网卡 MCTP 初始化异常终止问题分析（基于 openUBMC 25.09 版本）

问题概述

在使用 openUBMC 25.09 版本测试时，发现 LPe32002-AP 网卡的温度传感器读数为 0，表明带外通信未能正常获取设备信息。进一步跟踪代码发现，create_mctp_endpoint 流程在调用 mctp_lib.get_endpoint_and_transport 后 未打印后续日志（如“5”或“6”），说明该函数调用后流程被异常终止或阻塞。

由于 mctp_lib.get_endpoint_and_transport 属于 闭源 SDK 组件，无法直接查看其内部实现逻辑，但可结合现有知识库信息和系统行为，对问题进行综合排查与定位。

关键代码分析与执行路径

根据用户提供的日志和代码片段，执行流程如下：

function c_network_adapter:create_mctp_endpoint_for_others(msg_type)
    log:notice("... %$$$ 1")
    while count < max_retry do
        log:notice("... %$$$ 2")
        if self.DevBus ~= 0 ... then
            log:notice("... %$$$ 3")
            local phy_addr = mctp_lib.bdf_to_phy_addr(...)
            log:notice("... %$$$ 4") -- ✅ 已打印
            local ok, endpoint, transport = pcall(mctp_lib.get_endpoint_and_transport, ...)
            log:notice("... %$$$ 5") -- ❌ 未打印 → 说明 pcall 内部发生不可捕获异常或陷入死循环
            if not ok then ... end
            log:notice("... %$$$ 6") -- ❌ 未打印
        end
    end
end

关键观察点：

pcall 本应捕获 Lua 层面的错误并返回 ok=false，但 既没有返回异常，也没有继续执行后续代码。
意味着：
1. 闭源函数未正常返回（如：无限等待、死锁、内部死循环）；
2. 或 底层阻塞在 I/O 操作（如 PCIe 配置空间访问超时、MCTP 探测超时）；
3. 或 触发了非 Lua 异常（如 C 层段错误导致进程崩溃）。

在 openUBMC 系统中，若 Lua 调用的 C 闭源库发生严重异常（如段错误），可能导致 Lua VM 崩溃而无任何日志输出。

`mctp_lib.get_endpoint_and_transport` 的作用机制

尽管该函数为闭源，但可通过上下文推断其核心逻辑：

组件	说明
`mctp_lib`	提供 MCTP 协议栈支持，用于创建传输层（Transport）和端点对象（Endpoint），实现 BMC 与 PCIe 设备之间的管理通信。
`get_endpoint_and_transport(bus, module_name, phy_addr, msg_type)`	根据物理地址（`phy_addr`）和消息类型（`msg_type`）向 MCTP 栈请求建立通信通道。

典型逻辑流程应如下：

通过 phy_addr（由 BDF 转换而来）定位 PCIe 设备；
向设备发送 MCTP 发现请求（如 Get Endpoint ID）；
等待设备响应；
若成功，创建 Transport 和 Endpoint 对象，注册到 D-Bus；
返回对象引用。

当前行为异常解释：

函数调用后无返回 → 极可能卡在第 2~3 步，即 MCTP 探针未收到设备响应，且 闭源库未设置合理超时机制，导致长时间阻塞甚至死锁。

根本原因分析

结合文档、知识图谱及用户现象，推断可能原因如下：

1. MCTP over PCIe 链路未建立或设备未响应

LPe32002-AP 是否真正支持 MCTP？
- 搜索结果显示：LPE31002-AP 在 SR 文件中配置了 SupportedMctp=true，说明其支持 MCTP。
- 推测 LPe32002-AP 同样支持，但需确认其 SR 文件中是否正确定义了：
```
"SupportedMctp": true,
"SupportedMctpOverPcie": true
```
- 缺失 SR 配置会导致 mctp_lib 无法识别为 MCTP 设备，从而在探测阶段无限等待。

2. PCIe 物理链路或枚举异常

日志显示 BDF 为 23:0.0，bdf_to_phy_addr(23,0,0) 得到 phy_addr=22。
若 PCIe 枚举不完整或链路不稳定，mctp_lib 将无法访问设备配置空间，导致探测失败。
建议检查：
- dmesg 是否有 PCIe link down 或 bus timeout 报错；
- 是否在设备完全初始化前过早调用 MCTP 创建。

3. `mctp_lib.get_endpoint_and_transport` 缺乏超时机制（已知风险）

多个文档指出：
- openUBMC 的 mctp_lib 和 MCTP 相关组件为闭源，调试困难；
- 在 openUBMC 25.06 时存在“inject 手动注入 endpoint”问题，更新至 25.09 后修复 → 表明早期版本存在 endpoint 上树失败的问题。

来自文档 #6《南向网卡驱动适配指南》：

“方式一（NCSI over MCTP over PCIe + SMBus）”：框架会根据 SR 配置使用 SMBus 传输创建 MCTP。

若未正确配置传输介质，mctp_lib 可能误走 SMBus 路径，而 LPe 卡仅支持 PCIe MCTP → 导致探测失败。

4. 闭源库内部段错误导致无日志崩溃

虽然使用了 pcall，但如果 mctp_lib 是 C/C++ 实现的动态库，未处理的段错误（Segmentation Fault）会直接终止进程，不会被 Lua 捕获。
此时将无后续日志输出，现象与当前完全一致。

解决方案与排查建议

1. 核查 SR 文件配置

确保 LPe32002-AP 的 .sr 文件中包含以下字段：

"SupportedMctp": true,
"SupportedMctpOverPcie": true,
"Model": "LPe32002-AP"

并验证是否正确引用到 hardware_config 目录，且 network_adapter 能识别该型号。

2. 检查 MCTP 绑定与 endpoint 是否创建成功

登录 BMC 后执行：

# 查看 MCTP Binding 信息
busctl --user introspect bmc.kepler.mctpd /bmc/kepler/Systems/1/Mctp/MctpBinding

# 查看 BmcEid 和 BmcPhyAddr 是否设置
busctl --user get-property bmc.kepler.mctpd /bmc/kepler/Systems/1/Mctp/MctpBinding BmcEid
busctl --user get-property bmc.kepler.mctpd /bmc/kepler/Systems/1/Mctp/MctpBinding BmcPhyAddr

预期值：BmcEid ≠ 0, BmcPhyAddr ≠ 0
若为 0，则 MCTP 协议栈未初始化或失败。

3. 使用 `tracemctp` 工具抓包分析

利用 tracemctp 工具监听 MCTP over PCIe 流量：

# 启动追踪
tracemctp start

# 重启 network_adapter 或插拔网卡
systemctl restart network_adapter

# 查看是否有以下报文交互
tracemctp dump

期望看到：

MCTP_MSG_TYPE_DISCOVERY_REQ
MCTP_MSG_TYPE_DISCOVERY_RSP

若无响应： 说明设备未启用 MCTP 或 PCIe 通信异常。

4. 添加超时保护机制（应用层规避）

由于闭源库可能无超时机制，建议在 Lua 层增加守护逻辑：

local function create_with_timeout(bus, mod_name, phy_addr, msg_type, timeout_sec)
    local result = { success = false, endpoint = nil, transport = nil }
    local co = coroutine.create(function()
        local ok, ep, tp = pcall(mctp_lib.get_endpoint_and_transport, bus, mod_name, phy_addr, msg_type)
        result.success = ok and ep and tp
        result.endpoint = ep
        result.transport = tp
    end)

    -- 启动协程，并用定时器监控
    local timer = setTimeout(timeout_sec * 1000, function()
        if coroutine.status(co) == "suspended" then
            log:warning("mctp endpoint creation timed out, killing coroutine")
            result.success = false
        end
    end)

    local _, res = coroutine.resume(co)
    clearTimeout(timer)
    return result.success, result.endpoint, result.transport
end

即使闭源函数卡住，也能通过超时中断流程，防止系统挂死。

5. 升级至最新 patch 版本或联系 SDK 支持

文档 #5《openUBMC 25.09 版本发布说明》提到：

支持 Ncsi Over Mctp/I2C/SMBUS 协议获取网卡信息
但仍需确认是否已修复 MCTP endpoint 卡死类问题。

建议：

向 openUBMC 社区或闭源 SDK 提供商提交该 issue，要求确认 mctp_lib.get_endpoint_and_transport 是否存在 超时缺失 或 段错误隐患；

请求提供 带日志版本的 mctp_lib，便于定位问题。

结论

核心结论：
LPe32002-AP 网卡 MCTP 初始化失败，根本原因极可能是 mctp_lib.get_endpoint_and_transport 在探测设备时因链路异常或闭源库缺陷而无限阻塞或崩溃。

总结与建议

项目	结论
是否支持 MCTP	极大概率支持（参考 LPE31002）
是否 SR 配置正确	需人工核查 `.sr` 文件
是否 PCIe 链路正常	需检查 dmesg 与 BDF 枚举
是否 mctp_lib 卡死	极高概率（无返回、无错误）
是否需要超时机制	强烈建议在 Lua 层增加
是否为已知问题	类似问题曾在 25.06 存在，25.09 宣称修复

话题		回复	浏览量
openubmc是否支持mctp over smbus进行带外管理？交流互助区提问求助	24	463	2025 年10 月 16 日
板卡兼容性列表中的 lpe31002-ap 网卡支持mctp带外信息获取吗？ Hardware SIG 提问求助	4	91	2025 年10 月 14 日
25.12版本SF200HT网卡温度获取不到交流互助区提问求助	6	53	2026 年2 月 10 日
米尔开发板ncsi over mctp测试交流互助区提问求助	11	286	2025 年10 月 16 日
mctpd打印MCTP over SMBus通信报文交流互助区提问求助	1	125	2025 年10 月 21 日