OS下iBMA与BMC侧SMS是如何建立连接的

bmc_core SIG
1

基于2509的openUBMC版本

BMC侧没有获取到iBMA信息：

image
image1955×708 27.4 KB

image
image554×413 8.04 KB

OS下iBMA服务运行正常：
image
image806×488 128 KB

一键收集日志发现如下log：
image
image1612×504 18.8 KB

报错log里说ProtocolType是非法值0，但是实际上是1。

BMC这边持续一天都没有获取到iBMA的信息，重启OS和BMC都不行。
但是第二天再看发现可以获取到了。

对此有以下两个问题：
1.为什么会产生ProtocolType实际是1，但组件中获取到了0导致报错的问题？
2.为什么过一段时间后自行恢复了？

2

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

问题总结

总结：这个问题并非 host_agent 读取错误，而是 iBMA 与 BMC 之间的 D-Bus 属性同步机制出现了问题。iBMA 服务认为已成功设置通信模式，但 BMC 侧的 Sms 对象属性（ProtocolType）并未被正确更新为预期的值（1），导致 host_agent 持续读取到非法值 0 并重复报错。

总结：自行恢复的原因很可能是 iBMA 或 BMC 的 host_agent 组件内置了自动重试与状态机恢复逻辑。在首次属性同步失败后，系统会周期性地重试注册或属性更新操作，直到下一次尝试成功地将正确的 ProtocolType 值（1）同步到 BMC 侧的 D-Bus 对象上，从而清除了错误状态，使得 BMC 能够正常获取到 iBMA 的信息。这种现象也印证了知识库中关于“偶发性iBMA丢失”的描述，即通信状态的不稳定性是已知的潜在问题。

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

根据您提供的详细日志与上下文，我将基于知识库中的信息，对您提出的两个问题进行深入分析。

问题1：为什么会产生 ProtocolType 实际是1，但组件中获取到了0导致报错的问题？

根据上下文中的 Document Chunks 信息，这个问题可以归因于 iBMA 与 BMC 侧 host_agent 组件之间的通信与状态同步异常。

具体原因如下：

  1. 通信模式设置成功但状态未同步：虽然日志中有一条记录显示：

    7126: 2026-05-20 19:29:47.612114 host_agent NOTICE: sms.lua(620): The communication mode between BMA and BMC is set to veth successfully

    这条日志表明，在某个时刻，BMC 的 host_agent 组件成功将 iBMA（BMA）的通信模式设置为 veth。但是，这并不保证该配置值（ProtocolType）能够立即、正确地被 iBMA 侧读取或生效。

  2. host_agent 持续报错表明存在循环读取问题：从日志时间线可以看出，在“设置成功”的通知之后，host_agent 几乎每30秒就重复报出以下警告：

    host_agent WARNING: init.lua(97): nil->1 > reg_command.lua:196 > sms.lua:517: The value 0 for the property ProtocolType is not in the list of acceptable values.

    这个高频的周期性报错表明：

    • BMC 侧 (host_agent) 在持续地尝试读取或验证 iBMA 的 ProtocolType 属性。
    • 读取到的值始终为 0，这违反了系统接受值列表的规则（预期值应为 1，对应 veth 通信），因此触发了持续的警告。
    • 问题的根源在于，BMC 上的 iBMA 对象（通过 bmc.kepler.Systems.Sms.Veth 接口暴露）中的 ProtocolType 属性值没有正确更新。从您提供的 lsprop Sms_1_00 命令输出可以确认，该值确实为 0：
      bmc.kepler.Systems.Sms.Veth
    ...
    ProtocolType=0
      这解释了为什么 host_agent 会持续报错：它从 BMC 的 D-Bus 对象上读取到的 ProtocolType 属性值就是 0，而不是 iBMA 预期的 1。这表明 iBMA 端成功配置了 veth 模式，但该配置未能成功同步并持久化到 BMC 侧的 Sms D-Bus 对象上。

总结：这个问题并非 host_agent 读取错误，而是 iBMA 与 BMC 之间的 D-Bus 属性同步机制出现了问题。iBMA 服务认为已成功设置通信模式，但 BMC 侧的 Sms 对象属性（ProtocolType）并未被正确更新为预期的值（1），导致 host_agent 持续读取到非法值 0 并重复报错。

问题2：为什么过一段时间后自行恢复了？

根据知识库，这种现象与 iBMA 和 BMC 的通信与注册机制 强相关。其“自行恢复”的可能原因如下：

  1. iBMA 的自动重试与重新注册机制：知识库中提到，iBMA Registration Service 负责将 iBMA 注册到管理框架中。其状态被描述为“当前处于活动状态”。当首次注册或属性同步失败时，iBMA 或 BMC 侧的 host_agent 很可能具有自动重试逻辑。在持续重试的过程中，某个后续的同步请求可能成功地将正确的 ProtocolType 值（1）写入到了 BMC 侧的 D-Bus 对象，从而恢复了正常状态。这与日志中大量周期性报错的行为相符，说明系统在不断地进行恢复尝试。

  2. 系统组件的状态刷新：您提到“重启OS和BMC都不行”，这表明问题不是由简单的服务崩溃引起的，可能涉及更深层的状态锁死或缓存问题。过了一段时间后恢复，这可能是由于操作系统层、host_agent 服务内部或 BMC 固件中的某些定时任务、状态检查或缓存刷新机制在运行一段时间后，成功纠正了同步错误的状态。

  3. iBMA 与 BMC 通信的偶发性问题：知识库提到“BMC会偶发性出现iBMA丢失现象”，即使“系统下iBMA服务正常运行”。这说明 iBMA 进程本身是健康的，但它与 BMC 的通信链路可能因内部状态不一致或其他临时故障而不稳定。BMC 可能需要依赖 iBMA 通过 veth 接口发送一个新的、带有正确属性的注册或心跳包来更新其状态。长时间的运行可能最终促成了这个成功的通信。

总结：自行恢复的原因很可能是 iBMA 或 BMC 的 host_agent 组件内置了自动重试与状态机恢复逻辑。在首次属性同步失败后，系统会周期性地重试注册或属性更新操作，直到下一次尝试成功地将正确的 ProtocolType 值（1）同步到 BMC 侧的 D-Bus 对象上，从而清除了错误状态，使得 BMC 能够正常获取到 iBMA 的信息。这种现象也印证了知识库中关于“偶发性iBMA丢失”的描述，即通信状态的不稳定性是已知的潜在问题。

3

需要与BMA日志综合查看下。BMC和BMA建链会通过字符设备通信，BMA在未注册之前会一直尝试向BMA发送注册和通信请求。

BMA日志收集：
1）cd /opt/ibma OS后台进入到iBMA目录下 （以实际bma安装路径为准）
2）tar -zcf ibma_log.tar.gz log/ config/
收集ibma_log.tar.gz 压缩包

如果有完整BMA日志可以与BMC一键日志收集收集一起打包发到 zhangxiangyun1@h-partners.com

另外，可以同步确认下BMC获取到BMA前是否有做什么配置修改之类的。

4

目前出现过问题的环境已经不在了，下次再碰到会收集一下

能否先指导一下关键日志和追踪流程？

5

可以通过iBMA的common.log日志中搜索是否有Register相关的日志，查询是否是iBMC返回异常:

  1. 可以在带内持续观察 /sys/module/host_edma_drv/parameters/staticstics中的send_bytes和send_pkgs字段是否有持续增加，证明带内有通过edma发送数据，如有证明带内edma通道可以使用；
  2. 在bmc侧开启trace查看bmc是否有接收到edma信息，若无，则需要查看bmc侧edma通道是否正常。