PMC RAID卡设置热备盘后会导致组件重启

Hardware SIG
1

PMC RAID卡设置热备盘后会导致组件重启

PMC RAID卡设置热备盘后BMC无法查看到热备盘，跟踪日志发现获取不到热备盘的信息，并且会导致多个组件重启，相关日志如下：


2026-07-08 14:32:01.021862 hardware NOTICE: sc_ld.c(304): pmc_get_ld_info: ctrl_id:11209728, target_id:0, label:vd0, strip_size:262144, capacity:12000105070592, raid_level:2, status:0

2026-07-08 14:32:01.022050 hardware NOTICE: sc_ld.c(336): pmc_get_ld_info: ctrl_id:11209728, target_id:0, spare_count:0

2026-07-08 14:32:04.512437 hardware NOTICE: app_config.lua(182): init shared memory, harbor_name=harbor.bmc.kepler.hardware

2026-07-08 14:32:04.864916 unknown_service ERROR: init.lua(65): launch_control_00_ff.json does not exist.

2026-07-08 14:32:05.626702 hardware NOTICE: init.lua(231): process[hardware] loaded launch control file successfully

2026-07-08 14:32:08.367784 unknown_service NOTICE: harbor.lua(32): start message queue harbor.bmc.kepler.hardware receive loop, id = 1

2026-07-08 14:32:08.370785 hardware WARNING: l_shared_memory.cpp(483): Requestor SHM message transfer delay is 7300 ms (threshold: 500 ms), service_name=bmc.kepler.chassis, path=/bmc/kepler/Accessor/Accessor_LeftLedTube_0101, interface=bmc.kepler.Object.Properties, method_name=SetWithContext

2026-07-08 14:32:08.371633 hardware WARNING: l_shared_memory.cpp(483): Requestor SHM message transfer delay is 7299 ms (threshold: 500 ms), service_name=bmc.kepler.chassis, path=/bmc/kepler/Accessor/Accessor_MidLedTube_0101, interface=bmc.kepler.Object.Properties, method_name=SetWithContext

2026-07-08 14:32:08.372663 hardware WARNING: l_shared_memory.cpp(483): Requestor SHM message transfer delay is 7298 ms (threshold: 500 ms), service_name=bmc.kepler.chassis, path=/bmc/kepler/Accessor/Accessor_RightLedTube_0101, interface=bmc.kepler.Object.Properties, method_name=SetWithContext

2026-07-08 14:32:08.372842 hardware WARNING: l_shared_memory.cpp(483): Receiver SHM message transfer delay is 7128 ms (threshold: 500 ms), service_name=bmc.kepler.network_adapter, path=/bmc/kepler/network_adapter/MicroComponent, interface=bmc.kepler.MicroComponent, method_name=HealthCheck

2026-07-08 14:32:08.373168 hardware WARNING: l_shared_memory.cpp(483): Receiver SHM message transfer delay is 2331 ms (threshold: 500 ms), service_name=bmc.kepler.storage, path=/bmc/kepler/storage/MicroComponent, interface=bmc.kepler.MicroComponent, method_name=HealthCheck

2026-07-08 14:32:08.373486 hardware WARNING: l_shared_memory.cpp(483): Receiver SHM message transfer delay is 1488 ms (threshold: 500 ms), service_name=bmc.kepler.general_hardware, path=/bmc/kepler/general_hardware/MicroComponent, interface=org.freedesktop.DBus.Peer, method_name=Ping

2026-07-08 14:32:08.597661 unknown_service NOTICE: harbor.lua(32): start message queue harbor.bmc.kepler.hardware receive loop, id = 2

2026-07-08 14:32:08.792255 unknown_service NOTICE: node_id_identify.lua(308): node_id_identify ctor start

2026-07-08 14:32:08.794477 unknown_service NOTICE: harbor.lua(32): start message queue harbor.bmc.kepler.hardware receive loop, id = 3

2026-07-08 14:32:08.867574 unknown_service NOTICE: mctp_app.lua(48): mctp init: systemIds: {1}

2026-07-08 14:32:08.877733 unknown_service NOTICE: init.lua(89): [System1]mctp_endpoints: create endpoint, phy_addr=0, eid=0, msg_type=0, medium_type=15

2026-07-08 14:32:10.106369 storage NOTICE: micro_component.lua(157): Startup status has changed, ==> Starting, uptime:949s, cost 0ms

2026-07-08 14:32:10.291484 storage NOTICE: persist_client_lib.lua(60): persist client init completed, time taken: 100 ms

2026-07-08 14:32:10.381122 general_hardware NOTICE: micro_component.lua(157): Startup status has changed, ==> Starting, uptime:949s, cost 0ms

2026-07-08 14:32:10.412177 unknown_service NOTICE: ncsi_set_worker.lua(19): ncsi set worker start!

2026-07-08 14:32:10.473826 chassis NOTICE: chassis_app.lua(186): end fork init

2026-07-08 14:32:10.486162 chassis NOTICE: object_manage.lua(682): start to fetch hwdiscovery objects

2026-07-08 14:32:10.552313 chassis NOTICE: object_manage.lua(671): delay start, delay: 0ms

2026-07-08 14:32:10.572253 chassis NOTICE: object_manage.lua(720): fetch hwdiscovery objects completely, took 0 ms, uptime: 949 s

2026-07-08 14:32:10.572692 chassis NOTICE: object_manage.lua(682): start to fetch devmon objects

2026-07-08 14:32:10.577166 chassis NOTICE: object_manage.lua(720): fetch devmon objects completely, took 0 ms, uptime: 949 s

2026-07-08 14:32:10.580968 chassis NOTICE: object_manage.lua(316): start to add objects, path: /bmc/kepler/ObjectGroup/00, life cycle id: 1, count: 1, uptime: 949 s

2026-07-08 14:32:10.669596 chassis NOTICE: object_manage.lua(336): add objects callback, path: /bmc/kepler/ObjectGroup/00, life cycle id: 1, count: 1, took 90ms, uptime: 949 s

2026-07-08 14:32:10.670577 chassis NOTICE: object_manage.lua(346): add objects completely, path: /bmc/kepler/ObjectGroup/00, life cycle id: 1, took 0ms, uptime: 949 s

2026-07-08 14:32:10.675592 chassis NOTICE: object_manage.lua(316): start to add objects, path: /bmc/kepler/ObjectGroup/0101, life cycle id: 1, count: 10, uptime: 949 s

2026-07-08 14:32:10.704888 general_hardware NOTICE: persist_client_lib.lua(60): persist client init completed, time taken: 210 ms

2026-07-08 14:32:10.766371 storage NOTICE: persist_client_lib.lua(60): persist client init completed, time taken: 300 ms

2026-07-08 14:32:10.769018 storage NOTICE: micro_component.lua(157): Startup status has changed, Starting ==> InitCompleted, uptime:949s, cost 660ms

2026-07-08 14:32:10.776177 storage NOTICE: storage_app.lua(194): storage-init start

2026-07-08 14:32:10.779441 storage NOTICE: service_app_base.lua(368): start storage service

请问从日志中能看出什么问题吗？ 有什么其他定位手段？

详细日志：
app.log.txt (1.3 MB)

2

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

结论建议

当前日志的核心线索是：设置热备盘后硬件组件因健康检查超时而重启，导致存储组件重新初始化，热备盘信息丢失。建议优先通过 MCTP 通信检查和 BMC 插卡更换来定位，同时验证热备盘设置的接口调用是否正常。若问题持续，可参考 RAID 卡通信异常的标准排查流程（如检查 BIOS 端口启用、RAID 卡驱动状态、I2C 链路等，见文档中的典型场景）。

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

根据您提供的日志及相关背景信息，分析如下：

日志分析

从日志中可以看出，在 14:32:01 正常执行了 pmc_get_ld_info（获取逻辑盘信息），随后在 14:32:08 出现了大量 SHM 消息传输延迟 警告（超过 500ms 阈值），涉及 bmc.kepler.chassis、bmc.kepler.network_adapter、bmc.kepler.storage 等组件。紧接着，hardware 组件 于 14:32:04 开始重启（重新初始化共享内存），随后 storage 组件 也在 14:32:10 重启（状态从 Starting 变为 InitCompleted）。这表明设置热备盘的操作触发了 硬件管理组件（hardware） 的健康检查超时，导致硬件组件重启，进而连带 存储组件（storage） 和其他组件被重新拉起。

值得注意的是，日志中出现了：

unknown_service ERROR: init.lua(65): launch_control_00_ff.json does not exist.

这表明在组件重启时，部分服务配置文件缺失，可能是导致启动异常的原因之一。

可能的原因

根据上下文知识，PMC RAID 卡通过 MCTP 方式与 BMC 通信（参考检索结果 1）。设置热备盘时，存储组件需要与 RAID 卡交互，如果 MCTP 通信异常（例如 BMC 插卡自身问题、EID 分配失败等），会导致硬盘映射失败或信息无法获取。在 Topic 6634（SP686C 获取不到 RAID 信息）的案例中，最终确认问题 跟着 BMC 插卡走，换插卡后问题消失。所以 BMC 插卡通信异常 是嫌疑方向。

此外，日志中的 SHM 延迟警告表明硬件组件向 chassis、storage 等组件发送消息时积压严重，可能由于 设置热备盘时的 MCTP 请求阻塞，导致硬件组件的健康检查超时，进而触发组件重启。重启后，热备盘的映射关系可能丢失，因此无法查看到热备盘。

定位建议

以下手段可进一步判断问题根因（均基于上下文提及的已知方法）：

  1. 检查 MCTP 通信状态

    • 查看 app.log 中是否有 Get BMC Mctp Info failed 或类似打印（参考 Topic 6634）。这些日志通常在存储组件中打印。
    • 使用 mdbctl 或 busctl 检查 RAID 卡的 MCTP 端点（endpoint）是否正常，确认 EID 是否分配。

  2. 分析热备操作的详细日志

    • 在完整日志中搜索 SetHotspareType 或 SetHotspare 相关日志，确认是否有 get ref_controller_typeid failed（错误码 8353）等错误（参考 Topic 6782）。
    • 检查热备设置前后，存储组件内部是否有异常退出或 Failed to SetHotspareType 的 ERROR 日志。

  3. 排查 BMC 插卡硬件

    • 如果 MCTP 通信持续异常，尝试 更换 BMC 插卡 进行对比测试（参考 Topic 6634 的解决方案）。同时检查 BMC 插卡与 RAID 卡之间的物理连接。

  4. 关注组件重启触发逻辑

    • 查看 hardware 组件的健康检查机制。日志显示 HealthCheck 对 storage 组件的延迟高达 2331ms，可能触发了硬件组件的复位。可进一步查阅 Event Common Issues Guide 了解事件处理与告警消除逻辑。

  5. 确认 RAID 卡驱动与固件版本

    • 检查 RAID 卡固件版本是否与 BMC 版本兼容。在 BMC 界面查看 RAID 卡信息（如型号 SP686C-M-16i 等），确认是否支持热备操作（部分 RAID 卡可能需要特定固件支持）。

  6. 收集完整的一键式收集日志

    • 获取包含 app.log、card_info、maintenance 日志的完整抓包，便于分析时间戳精确的事件顺序。同时检查 SEL 日志中是否有 RAID 卡相关的告警（如通信失败、电源异常等）。

结论建议

当前日志的核心线索是：设置热备盘后硬件组件因健康检查超时而重启，导致存储组件重新初始化，热备盘信息丢失。建议优先通过 MCTP 通信检查和 BMC 插卡更换来定位，同时验证热备盘设置的接口调用是否正常。若问题持续，可参考 RAID 卡通信异常的标准排查流程（如检查 BIOS 端口启用、RAID 卡驱动状态、I2C 链路等，见文档中的典型场景）。

3

查看coredump信息如下：

Core was generated by `hardware /opt/bmc/apps/hica/subsys/hardware/config.cfg'.
Program terminated with signal SIGABRT, Aborted.
#0  0x0000ffff9ca0e200 in ?? () from /lib64/libc.so.6
[Current thread is 1 (LWP 6999)]
(gdb) bt
#0  0x0000ffff9ca0e200 in ?? () from /lib64/libc.so.6
#1  0x0000ffff9c9c29ec in raise () from /lib64/libc.so.6
#2  0x0000ffff9c9af4b0 in abort () from /lib64/libc.so.6
#3  0x0000ffff9ca020c8 in ?? () from /lib64/libc.so.6
#4  0x0000ffff9ca88768 in __fortify_fail () from /lib64/libc.so.6
#5  0x0000ffff9ca88730 in __stack_chk_fail () from /lib64/libc.so.6
#6  0x0000ffff8411adb4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

看起来是一个栈溢出问题。

重新封装PMC库可以解决。