IMU 成功枚举到 MCTP EP，但是 BMC 侧 route table 中无对应成员

kunlun_xiongzirui · 2026 年9 月 20 日 04:01

问题描述

环境搭载一块 PM9D3A NVMe 硬盘

IMU 成功枚举到 NVMe 盘的 MCTP EP，但是 BMC 侧 route table 中无对应成员

环境信息

社区 26.6 基线

问题求助点

是否有方式能够定界问题是在 BMC 侧还是 IMU 侧？

打开 mctpd 的 info 日志后，观察到 get routing table 始终只有两个成员（预期 3 个），是否可以说明 IMU 只给 BMC 上报了两个 ep，而非预期的三个，从而将问题定界在 IMU 侧？

IMU 的 routing table 上报，是否有额外依赖？（比如要求正确的丝印文件？），还是说，只要枚举到了，理论上就都应该上报？

ubmc_assistant · 2026 年9 月 20 日 04:02

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

总结

定界步骤	判断依据
1. 确认 IMU 枚举状态	已确认 IMU 枚举到 PM9D3A
2. 核对 BMC 路由表	mctpd `get routing table` 仅两个成员，缺失 PM9D3A
3. 判断定界方向	若 IMU 已枚举但未上报 → 问题在 IMU 侧或 IMU→BMC 链路
4. 检查链路与协议	排查 PCIe 链路完整性、IMU 上电状态、BMC 侧协议错误日志（如 crc/校验失败）

结论：您观察到的“mctpd 路由表仅两个成员”现象，可以初步定界为 IMU 未上报第三个 EP 的路由信息，但还需进一步确认 IMU 的上报机制是否受硬件链路或协议错误影响，不能仅凭枚举成功就断定 IMU 应当上报。建议抓取 IMU 日志与 BMC 侧协议层 debug 日志，结合硬件链路状态综合判断。

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

根据您提供的问题描述和知识库中的信息，我将从定界方法、日志判断依据和 IMU 上报依赖三个方面进行分析。

一、BMC 侧与 IMU 侧的定界方式

在知识库的《mctp 路由表缺失问题分析》文档中，明确给出了针对“路由中无预期 phyaddr”的定界方法：

路由中无预期 phyaddr | 可能需联合硬件 | IMU 未收到该设备 discovery

结合《问题定界指南》（文档块 1）中的流程，建议按以下步骤操作：

检查 IMU 侧日志：确认 IMU 是否成功枚举到 NVMe 盘的 MCTP EP。您已经确认 IMU 枚举成功（问题描述中已说明），因此需要进一步核对 IMU 是否向 BMC 发送了对应的路由信息。
检查 BMC 侧 mctpd 状态：
- 执行 busctl --user tree bmc.kepler.mctpd，检查 Binding、Routing、Endpoint 是否齐全。
- 抓取 Power ON、set owner_eid、set bmc_eid、add routing entry、create endpoint 日志（文档块 1 第 5.2 节）。
核对路由表内容：确认 mctpd 中 get routing table 返回的两个成员是否对应正确的设备（例如 OCP 网卡和另一块硬盘），并确认缺失的成员是否正是 PM9D3A NVMe 盘。

若 BMC 侧路由表始终只有两个成员，而 IMU 日志中明确显示已枚举到第三个 EP，则结合“BMC 的 Routing Information 是主动从 IMU 获取的”（知识图谱关系），可以初步定界为 IMU 未将该 EP 的路由信息上报给 BMC，或 IMU 与 BMC 之间的通信链路存在异常。

二、关于“get routing table 只有两个成员”的判断

知识图谱中明确记录：

与 bmc.kepler.mctpd 的关系：The bmc.kepler.mctpd daemon receives routing information from the IMU to build the MCTP routing table.

这说明 mctpd 的路由表完全依赖 IMU 上报的数据。因此：

如果 mctpd 的 get routing table 始终只有两个成员，而 IMU 已成功枚举到第三个 EP，那么 IMU 很可能只向 BMC 上报了两个 EP 的路由信息，第三个 EP 的路由数据未上报。
此现象可以支持将问题定界在 IMU 侧（IMU 未上报）或 IMU→BMC 通信链路（上报数据丢失/未到达）。

但同时也需注意《问题定界指南》中的提示：如果 Request 超时或协议层校验失败，响应会被静默丢弃（文档块 1 第 4.2 节 debug 关键字包括 unmatch crc / check sum / incorrect payload size / unexpected fragment size / vdm header error）。因此，若 BMC 侧日志中出现上述错误，也可能是传输层问题导致 IMU 的上报未能被 BMC 正确接收。

三、IMU 路由表上报的依赖条件

知识库中关于 IMU 的描述指出：

Imu must be powered on for MCTP communication to function; its state can be checked via logs or web interface.

即 IMU 必须上电且正常工作，MCTP 通信才能进行，路由信息上报也依赖于 IMU 的正常运行状态。

另外，在《mctp 路由表缺失问题分析》（搜索文档 3）中有实际案例：

环境搭载 MCX623436MN-CDAB 网卡，IMU 日志显示已找到对应 EP，但 BMC 侧路由表缺失。
最终定位为 硬件 PCIe1 链路空悬，导致 IMU 与 BMC 建链失败，路由信息无法传递。

因此，IMU 的枚举成功不一定等于路由上报成功，存在以下依赖：

IMU 上电状态：IMU 必须处于上电运行状态。
硬件链路完整性：IMU 与 BMC 之间的 PCIe/SMBus 链路必须正常建立。若链路空悬、接触不良或配置错误，即使 IMU 枚举到设备，也无法将路由信息传递到 BMC。
通信协议正确性：路由上报过程中若出现 CRC、校验、帧大小等错误，BMC 会静默丢弃报文（文档块 1）。

因此，“只要枚举到了就应该上报”的假设并不完全成立——枚举成功只代表 IMU 识别到了设备，但路由上报还依赖上述链路和协议条件。若您已确认 IMU 枚举到 PM9D3A，而 BMC 未收到路由，建议优先排查 IMU→BMC 的物理链路（如 PCIe 链路接线、IMU 固件状态）以及通信日志中的协议错误。

总结

定界步骤	判断依据
1. 确认 IMU 枚举状态	已确认 IMU 枚举到 PM9D3A
2. 核对 BMC 路由表	mctpd `get routing table` 仅两个成员，缺失 PM9D3A
3. 判断定界方向	若 IMU 已枚举但未上报 → 问题在 IMU 侧或 IMU→BMC 链路
4. 检查链路与协议	排查 PCIe 链路完整性、IMU 上电状态、BMC 侧协议错误日志（如 crc/校验失败）