长时间 AC 掉电，偶现 PCIe 卡丝印未生成，造成带外掉卡

交流互助区
1

问题描述

SP686C 双 RAID 环境，做长时间 AC 掉电，60 次出现一次两张 RAID 卡都未识别的情况

观察生成的丝印文件，只剩下 OCP 和 NVMe，PCIe 卡的丝印消失了

img_v3_0213b_294b5545-6ab2-49fe-be45-46efb912244g
img_v3_0213b_294b5545-6ab2-49fe-be45-46efb912244g843×958 33.2 KB

查看日志，pcie_device 的组件启动偏慢

2026-07-01 07:05:54 IPMI,N/A@HOST,BIOS,Set BIOS version to 00.20.01.05 —— 这里 BIOS 就活了
2026-07-01 07:06:01.699105 pcie_device NOTICE: micro_component.lua(167): Startup status has changed,  ==> Starting, uptime:132s, cost 0ms —— 这里 pcie_device 才开始启动
2026-07-01 07:15:50.242479 pcie_device NOTICE: biz_topo.lua(902): [BizTopo] Name=PcieAddrInfo_1_01010109, ContainerSlot=2, ContainerUnitType=IEU, ContainerUID=00000001040302044498 [repeated 32 times in 2s from 2026-07-01 07:06:16.848209 to 2026-07-01 07:06:18.375398][flush] —— 可以看到 07:06:16 到 07:06:18 之间还在做 biz topo

—— 这里 BIOS 组件在生成丝印了，但很明显丝印里已经丢卡了，预期的 PCIe 卡在 Slot3 和 Slot6，已经丢了；可以看到生成丝印的时间电，pcie_device 还在做 biz topo
2026-07-01 07:06:16.922990 bios NOTICE: bios_service.lua(1006): get_pcie_silk_config: PCIeAddrInfo count=30, system id(1)
2026-07-01 07:06:16.923543 bios NOTICE: bios_service.lua(953): PCIeCard PCIeAddrInfo: segment=0, port_id=24, socket_id=0, slot=8
2026-07-01 07:06:16.924020 bios NOTICE: bios_service.lua(953): PCIeCard PCIeAddrInfo: segment=0, port_id=26, socket_id=0, slot=9
2026-07-01 07:06:16.924503 bios NOTICE: bios_service.lua(953): PCIeCard PCIeAddrInfo: segment=0, port_id=20, socket_id=0, slot=10
2026-07-01 07:06:16.925105 bios NOTICE: bios_service.lua(953): PCIeCard PCIeAddrInfo: segment=0, port_id=4, socket_id=1, slot=2
2026-07-01 07:06:16.926154 bios NOTICE: bios_service.lua(953): PCIeCard PCIeAddrInfo: segment=0, port_id=4, socket_id=0, slot=1
2026-07-01 07:06:16.926915 bios NOTICE: bios_service.lua(953): PCIeCard PCIeAddrInfo: segment=0, port_id=34, socket_id=1, slot=47
2026-07-01 07:06:16.927965 bios NOTICE: bios_service.lua(953): PCIeCard PCIeAddrInfo: segment=0, port_id=32, socket_id=1, slot=46
2026-07-01 07:06:16.928474 bios NOTICE: bios_service.lua(953): PCIeCard PCIeAddrInfo: segment=0, port_id=22, socket_id=0, slot=11
2026-07-01 07:06:17.299656 bios NOTICE: bios_service.lua(1397): [bios] system 1 read file(42) success
2026-07-01 07:06:18.132209 bios NOTICE: bios_service.lua(1397): [bios] system 1 read file(47) success

观察框架日志，没有大规模组件启动失败/重启，但 pcie_device 所在的 RAS 进程疑似存在 endless loop，怀疑是这里拖慢了启动速度

2026-07-01 07:05:37.688909 maca ERROR: init.lua(184): [ddns]StartupCheck failed, error: org.freedesktop.DBus.Error.UnknownObject: Unknown object path /bmc/kepler/ddns/MicroComponent, check count: 2
2026-07-01 07:05:39.173578 [:00000012] interface: LAUNCH snlua route_mapper/worker_service/main
2026-07-01 07:05:39.554887 maca ERROR: init.lua(184): [lsw]StartupCheck failed, error: org.freedesktop.DBus.Error.UnknownObject: Unknown object path /bmc/kepler/lsw/MicroComponent, check count: 2
2026-07-01 07:05:40.175883 maca ERROR: init.lua(184): [pcie_device]StartupCheck failed, error: org.freedesktop.DBus.Error.UnknownObject: Unknown object path /bmc/kepler/pcie_device/MicroComponent, check count: 2
2026-07-01 07:05:43.861517 persistence NOTICE: persistence_permanent_intf.lua(138): persist permanent delete successfully, tname:t_account_backup, key:Id:2
2026-07-01 07:05:44.196374 [:00000000] ras: A message from [ :00000010 ] to [ :00000010 ] maybe in an endless loop (version = 269)
2026-07-01 07:05:44.197267 [:00000000] ras: Printing Lua stack trace for service :00000010
2026-07-01 07:05:44.197555 [:00000010] ras: recv a signal 2
2026-07-01 07:05:44.208597 persistence NOTICE: persistence_permanent_intf.lua(166): persist permanent save successfully, tname:t_account_backup, length:241
2026-07-01 07:05:47.011422 persistence WARNING: persistence_task_schedule.lua(264): A storm occurs in table t_memory_ras
2026-07-01 07:05:47.626601 hwdiscovery WARNING: harbor_client.lua(367): shm reply failed, path: /bmc/kepler/ObjectGroup/010101, interface: bmc.kepler.ObjectGroup, member: GetBinaryObjects, ret: message_queue push back: data size too large
2026-07-01 07:05:49.832971 [:00000010] ras: === Lua Stack Trace (endless loop detected) ===
2026-07-01 07:05:49.833310 [:00000010] ras: === End of Lua Stack Trace ===

观察发生 endless loop 的 skynet 服务，是 metric_analyzer，除此之外没有发现明显异常

2026-07-01 07:05:05.911305 [:00000010] ras: LAUNCH snlua metric_analyzer/service/main

pcie掉卡.zip (6.2 MB)

环境信息

LTS SP1 搭配 530 闭源

2

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

结论与定位方向

根本原因：AC 掉电重启后，由于 pcie_device 组件所在的 ras 进程启动缓慢（可能因内部 endless loop 导致），导致其未能在 BIOS 请求丝印信息前完成 PCIe 拓扑的构建和地址信息同步，最终 BIOS 生成的丝印文件不完整，PCIe 卡无法被 BMC 正确识别和管理。

这与知识图谱中记录的 pcie_device 存在初始化阶段异常的描述，以及文档块 #1 (topic 4722) 中提到的 pcie_device 组件 StartupCheck 失败、组件启动异常导致丝印信息未生成 等案例高度吻合。文档块 #1 中也提到该问题在开源社区 LTS 版本中已得到优化。

后续建议：

  • 深入分析 endless loop 根因：重点排查 metric_analyzer 服务在特定条件下陷入无限循环的逻辑，这可能是导致 pcie_device 在 AC 启动时变慢的罪魁祸首。
  • 参考组件启动时序优化：可以考虑在 fructrl 组件执行通电开机策略前，增加等待 bios 和 pcie_device 组件确认启动完成的逻辑，从机制上规避此问题（此建议也曾在 topic 4722 的回复中被提出）。
点击此处查看详细分析解答

好的，根据您提供的详细问题描述以及上下文中的知识图谱（KG）和文档块（DC），我对该问题进行综合分析如下。

问题根因分析

该问题的核心是 由于 pcie_device 组件启动过慢，导致 BIOS 在生成 PCIe 卡丝印文件时无法获取完整的 PCIeAddrInfo，从而造成丝印文件缺失，引发带外掉卡现象。

具体分析如下：

  1. 时序冲突是关键：从您提供的日志可以清晰地看出，这是一个典型的 时序问题。

    • BIOS 启动速度更快：日志 2026-07-01 07:05:54 显示 BIOS 已经激活。
    • pcie_device 启动严重滞后：2026-07-01 07:06:01.699，pcie_device 组件才刚刚开始启动（状态变为 Starting）。
    • 丝印生成在 pcie_device 就绪前：2026-07-01 07:06:16，BIOS 组件（bios_service.lua）已经开始读取 PCIeAddrInfo 以生成丝印文件。此时，pcie_device 仍在进行拓扑构建（biz_topo），尚未准备好完整的地址信息。
    • 结果：BIOS 在丝印生成时间点读取到的 PCIeAddrInfo 数量不全（日志显示 count=30），导致预期安装在 Slot3 和 Slot6 的 PCIe 卡信息丢失。

  2. pcie_device 启动慢的可能原因：

    • RAS 进程中的 endless loop：您观察到的框架日志中，RAS 进程在 07:05:44 检测到了一个 endless loop（无限循环）。根据知识图谱，pcie_device 组件正是在 ras 进程下运行的（pcie_device 是 ras 进程的一部分）。这个 endless loop 发生在 metric_analyzer 服务中，极有可能 拖累了整个 ras 进程的启动速度，从而导致 pcie_device 无法及时完成初始化，错过了与 BIOS 交互的最佳时机。
    • 无大规模组件失败：您提到框架日志中没有大量组件启动失败，这也间接说明 pcie_device 启动慢并非是因为依赖于其他失败组件，而更像是其自身所在进程出现了运行异常（如本例中的 endless loop）。

  3. sync_pcie_addr_info 函数可能失效：知识图谱中提及 sync_pcie_addr_info 函数负责同步 PCIe 地址信息，且当相关字段为零时会失败。如果 pcie_device 启动不完整或拓扑信息未能及时同步，该函数可能无法正常工作，导致 pcie_addr_info 为空或不完整。

结论与定位方向

根本原因：AC 掉电重启后，由于 pcie_device 组件所在的 ras 进程启动缓慢（可能因内部 endless loop 导致），导致其未能在 BIOS 请求丝印信息前完成 PCIe 拓扑的构建和地址信息同步，最终 BIOS 生成的丝印文件不完整，PCIe 卡无法被 BMC 正确识别和管理。

这与知识图谱中记录的 pcie_device 存在初始化阶段异常的描述，以及文档块 #1 (topic 4722) 中提到的 pcie_device 组件 StartupCheck 失败、组件启动异常导致丝印信息未生成 等案例高度吻合。文档块 #1 中也提到该问题在开源社区 LTS 版本中已得到优化。

后续建议：

  • 深入分析 endless loop 根因：重点排查 metric_analyzer 服务在特定条件下陷入无限循环的逻辑，这可能是导致 pcie_device 在 AC 启动时变慢的罪魁祸首。
  • 参考组件启动时序优化：可以考虑在 fructrl 组件执行通电开机策略前，增加等待 bios 和 pcie_device 组件确认启动完成的逻辑，从机制上规避此问题（此建议也曾在 topic 4722 的回复中被提出）。
3

从日志里来看，bios来获取丝印的时机是07:06:16，pcie_device的启动（Startup status has changed）日志时间为06:50:42，不太像是启动时间问题。

但从app日志来看，hwdiscovery下Connector_A2a_010101.sr和Connector_B3a_010101.sr中的内容为空。

建议排查：

  1. sr文件配置是否正确，能正常解析
  2. 读取csr的链路是否通畅，能正常上板卡和加载csr
  3. 排查是否改动了pcie代码导致分发变慢

如果确实加载慢，可以通过参考以下代码，在保证pcieaddrinfo的rootBDF正常的情况下，使用以下方式手动搜索下挂的pcie卡

支持通过rootBDF加载PCIe设备-pcie_device-AtomGit

AtomGit - 全球开发者的开源社区,开源代码托管平台