【求助】跑AC自动化出现执行lsobj PCIEcard命令报错的现象。概率6/50

交流互助区
1

问题描述

在【kunlun2280V2 920BS】机型执行AC过程中，出现执行 lsobj PCIeCard 命令报错的现象，当前统计复现概率约为 6/50。

从日志和测试现象看，问题主要发生在 BMC 启动后运行阶段，期间存在 hardware 子系统相关组件异常重启、重拉的情况，导致部分管理对象查询能力短时异常，进而触发 lsobj PCIeCard 执行失败。

由于无法上传文件，我把AI分析的framework.log的日志帖了出来

image
image781×625 14.8 KB

期望结果

执行 lsobj PCIeCard 命令无报错

实际结果

执行 lsobj PCIeCard 命令报错的现象，当前统计复现概率约为 6/50

尝试过的解决方案

1、在BMC与系统时间调整一致后，报错现象仍然存在

分析结论

1、结合当前掌握的信息，初步判断本问题本质上是BMC内部hardware等子系统在启动/运行过程中出现异常重启或重拉，导致对象管理服务不可用，从而引发 lsobj PCIeCard 命令失败。至于组件重拉的根本触发原因，仍需坂田侧进一步深入定位。

2

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

总结

您遇到的lsobj PCIeCard报错是BMC内部组件（特别是pcie_device、bios等）启动异常的直接表现。这个问题本质上与您引用的“StartupCheck failed”问题一致。定位方向应聚焦于为何这些组件在AC启动时反复出现“ServiceUnknown”错误。硬件层面的排查（如Topic 4722中提到的NAND Flash问题）和软件层面（如组件的.service文件、代码逻辑缺陷）都需要考虑。

您的分析结论——“本问题本质上是BMC内部hardware等子系统在启动/运行过程中出现异常重启或重拉，导致对象管理服务不可用”是准确的。建议按照上述定位步骤进一步深挖，重点是组件重拉的“原因”，而非“现象”本身。

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

好的，根据您提供的上下文信息，我对您描述的“在AC自动化过程中执行lsobj PCIeCard命令报错”的问题进行了分析。

问题根因分析

根据文档和知识库中的信息，您遇到的问题并非lsobj命令本身缺陷，而是其前置依赖条件不满足所导致的。核心原因在于 BMC 内部组件（特别是 hardware 子系统相关的组件）在启动或运行过程中出现异常，导致其注册的 D-Bus 服务不可用，从而使lsobj命令无法查询到预期的PCIeCard对象。

具体分析如下：

  1. lsobj命令依赖组件服务：lsobj命令用于查询D-Bus对象树。在openUBMC系统中，PCIeCard对象由pcie_device、bios等组件负责管理和注册。如果这些组件启动失败或运行异常，它们就无法在D-Bus上提供服务，lsobj命令自然无法找到对应的对象，从而报错。

  2. 组件启动失败是已知问题：您的问题与知识库中多个已知问题高度吻合。

    • Topic 4722 描述了“AC启动，概率出现组件启动异常…影响PCIe卡加载”。文档片段中显示了大量StartupCheck failed的错误日志，如[compute]StartupCheck failed、[bios]StartupCheck failed、[pcie_device]StartupCheck failed等。这些日志明确指出组件因服务名未知（ServiceUnknown）而启动失败。
    • Topic 6518 同样描述了“组件健康检查失败，导致BMC重启，pcie卡加载失败”。这印证了组件失败可能触发BMC重启，但重启后问题可能仍然存在。

  3. 问题触发机制：在AC启动或长时间稳定性测试中，以下时序问题可能导致lsobj PCIeCard报错：

    • 组件启动慢或死锁：BMC启动后，pcie_device、bios等组件未能及时完成初始化并注册服务。
    • 组件重启“错过”信息上报：如您自己的分析结论和Topic 4722所述，组件在启动时重启，可能错过了BIOS上报的PCIe卡信息，导致PCIe卡对象最终未能创建。
    • 组件健康检查失败：startup_check机制会定期检查组件的健康状况。如果连续检查失败（默认3次），会触发组件重启甚至BMC重启，从而导致服务短暂不可用。

定位与修复建议

结合知识库中的信息，建议按以下步骤进行定位和修复：

  1. 查看关键日志：除了framework.log，重点分析app.log。这是定位组件内部错误最直接的日志。文档中提到“可以在启动异常的app里面的main.lua的require部分用pcall包起来，看看具体组件启动失败的报错”。

  2. 检查组件.service文件：日志错误org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.xxx was not provided by any .service files表明，系统找不到对应的服务文件。请检查pcie_device、bios等异常组件是否缺少了.service文件。知识库中提到my_app组件就曾因缺少.service文件导致启动失败。

  3. 排查组件重拉根本原因：组件重拉是结果，不是原因。需要进一步分析：

    • 是否存在硬件问题？Topic 4722中提到“当前排查可能和nandflash颗粒有关”。
    • 是否存在软件bug？例如在bios或pcie_device组件的代码中，是否有导致死锁或内存越界的逻辑。
    • 是否存在配置错误？如组件的main.lua文件中require了错误的或不存在的模块。

  4. 确认startup_check阈值配置：检查BMC的mc_control.json配置文件（通常在manifest仓库中），确认startup_check下的threshold参数。知识库中提到默认值为3，即连续3次检查失败后会启动自愈机制。如果阈值设置过小，可能会导致组件因暂时性问题被频繁重启。

  5. 检查MACA健康状态检查机制：根据知识库中的“微组件管理介绍”，组件在10分钟内连续掉线5次会复位BMC。排查您的日志中是否有组件频繁掉线的情况。

  6. 复现与隔离：由于问题是概率性的，需要在复现时：

    • 收集完整的日志（framework.log, app.log, ipmi.log等）。
    • 尝试将问题隔离到单个组件。例如，如果pcie_device组件频繁失败，可以尝试回滚该组件的版本，看是否能解决问题。

总结

您遇到的lsobj PCIeCard报错是BMC内部组件（特别是pcie_device、bios等）启动异常的直接表现。这个问题本质上与您引用的“StartupCheck failed”问题一致。定位方向应聚焦于为何这些组件在AC启动时反复出现“ServiceUnknown”错误。硬件层面的排查（如Topic 4722中提到的NAND Flash问题）和软件层面（如组件的.service文件、代码逻辑缺陷）都需要考虑。

您的分析结论——“本问题本质上是BMC内部hardware等子系统在启动/运行过程中出现异常重启或重拉，导致对象管理服务不可用”是准确的。建议按照上述定位步骤进一步深挖，重点是组件重拉的“原因”，而非“现象”本身。

1 个赞
3

问题补充：

当前测试脚本是 OS ping通之后5分钟查询PCIeCard对象，由于组件重启引起BMC重启脚本执行时PCIeCard对象还未加载。需要求助分析组件重启的原因。

4

麻烦提供一键收集日志，看一下为什么会出现组件没有起来的情况

5

挂死就是运行中访问了不存在的属性support_mctp

社区版本是没有这个字段的

我看日志中的Storage组件版本是1.81.11.002@kl.ibmc.br_develop_6.0.0_ibmc_dev_branch

麻烦你们这边看一下是不是 代码写错了（可能是拼写错误?）

社区版本中只有check_support_mctp

6

storage/src/lualib/nvme/nvme_object.lua-代码预览-storage:基于 Lua 的存储组件管理项目 - AtomGit | GitCode 我们是之前单点反合了社区这个修改引入了。这个报错我们也看到了，如果是这个原因引起必然应该必然会引起BMC重启，然而实际上我们观察并不是必然重启

7

很简单啊 对比下没复位的 看下有没有这个日志嘛

日志里每次复位都是报了这个

都是初始化阶段

那就看访问这个错误变量的逻辑是什么了

无非就是特定场景访问这个变量才会出问题

也可以先修改后再试下看还会不会出