适配9500HBA卡反复AC测试导致BMC framework卡死

[iss_yinxiaoning (软通华方_尹晓宁)]

// 此模板仅供参考，如果不适用可以修改

问题描述

在适配9500 HBA库代码后进行反复AC测试，导致BMC framework卡死

使用AI分析结果：

环境信息

• 软件版本： OpenUBMC2509

• 硬件配置：9500 HBA卡

重现步骤

1. 整机AC测试

2. 登录BMC页面

3. 页面无法登录，此时telnet和ssh可用

实际结果

2026-03-03 17:52:35.708589 framework ERROR: l_sig_handler.c(350): ========== FATAL SIGNAL CAUGHT ========== PackageBuildTime: 20260303063950 PID: 6363, PPID: 1 Program: framework Signal: 11 (SIGSEGV) - Segmentation violation Signal code: 1 (SEGV_MAPERR - Address not mapped to object) Sending PID: 0 Fault address: 0x0 ========== END OF CRASH REPORT ==========

2026-03-03 17:52:35.710161 framework ERROR: l_sig_handler.c(310): === Stack Backtrace ===

2026-03-03 17:52:35.710440 framework ERROR: l_sig_handler.c(310): core-info-skynet-11-framework-20260303063950

2026-03-03 17:52:35.711630 framework ERROR: l_sig_handler.c(310): === Source Code Backtrace ===

2026-03-03 17:52:35.712578 framework ERROR: l_sig_handler.c(310): [0] /usr/lib64/libraidblibit.so(FillMrPdAddressArgs+0x254) [0xffff5a3495dc]

2026-03-03 17:52:35.713006 framework ERROR: l_sig_handler.c(310): [1] /usr/lib64/libraidblibit.so(MapSimpleFWEvents+0x4d0) [0xffff5a34a008]

2026-03-03 17:52:35.713830 framework ERROR: l_sig_handler.c(310): [2] /usr/lib64/libraidblibit.so(MapSimpleFWEventsWithMutex+0x54) [0xffff5a34ab40]

2026-03-03 17:52:35.714202 framework ERROR: l_sig_handler.c(310): [3] /usr/lib64/libraidblibit.so(CAenProcessor_GetEventsCallback+0xa20) [0xffff5a331de0]

2026-03-03 17:52:35.714997 framework ERROR: l_sig_handler.c(310): [4] /usr/lib64/libraidblibit.so(EventThreadProc+0x14) [0xffff5a3166e8]

2026-03-03 17:52:35.715937 framework ERROR: l_sig_handler.c(310): [5] /lib64/libc.so.6(+0x824b4) [0xffff917384b4]

2026-03-03 17:52:35.716333 framework ERROR: l_sig_handler.c(310): [6] /lib64/libc.so.6(+0xf0f5c) [0xffff917a6f5c]

2026-03-03 17:52:35.718074 framework ERROR: l_sig_handler.c(310): === Source Code Analysis ===

2026-03-03 17:52:35.718446 framework ERROR: l_sig_handler.c(310): To get exact source lines, run these commands:

2026-03-03 17:52:35.719424 framework ERROR: l_sig_handler.c(310): Frame 0: addr2line -e /usr/lib64/libraidblibit.so -f -C FillMrPdAddressArgs+0x254

2026-03-03 17:52:35.719760 framework ERROR: l_sig_handler.c(310): Frame 1: addr2line -e /usr/lib64/libraidblibit.so -f -C MapSimpleFWEvents+0x4d0

[ubmc_assistant (openUBMC_Assistant)]

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

结论

本问题的根本原因是：
libraidblibit.so 驱动库未对输入参数做空指针检查，在9500 HBA卡未初始化完成时即被调用，导致 FillMrPdAddressArgs 函数访问空地址，引发 SIGSEGV 段错误，最终使BMC核心进程 framework 崩溃。

推荐行动项

优先级	措施
高	在 FillMrPdAddressArgs 等函数中添加空指针校验
高	将RAID监控服务从主进程剥离，防止单点崩溃影响全局
中	增加AC启动后对RAID卡就绪状态的检测逻辑
低	提供完整 .so 文件符号表，便于后续快速定位崩溃位置

建议提交缺陷单至驱动维护团队，并引用日志堆栈信息辅助修复。

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

9500 HBA卡空指针导致BMC异常挂死问题分析

问题概述

在服务器AC（上电-断电循环）测试过程中，系统因9500 RAID/HBA卡引发的空指针访问错误导致BMC框架进程异常崩溃（SIGSEGV信号），造成BMC启动失败，表现为：

• BMC页面无法登录
• telnet与ssh仍可连接，说明部分底层服务仍在运行
• framework进程因段错误（Segmentation violation）而崩溃
• 故障地址为0x0，确认为空指针解引用问题

---

故障现象与日志分析

从提供的日志信息中可提取关键线索：

========== FATAL SIGNAL CAUGHT ==========
Signal: 11 (SIGSEGV) - Segmentation violation
Signal code: 1 (SEGV_MAPERR - Address not mapped to object)
Fault address: 0x0

堆栈回溯分析

关键的调用栈如下（从底层向顶层）：

1. EventThreadProc → RAID卡事件处理线程入口
2. CAenProcessor_GetEventsCallback → RAID卡固件事件回调函数
3. MapSimpleFWEventsWithMutex → 带锁的事件映射处理
4. MapSimpleFWEvents → 事件解析主函数
5. FillMrPdAddressArgs + 0x254 → 空指针发生的具体位置

最终故障发生在函数 FillMrPdAddressArgs 中对空指针的访问。

Fault Address: 0x0 明确表明程序试图访问一个未初始化或已被释放的指针。

---

根因定位

1. 直接原因

libraidblibit.so 库中的 FillMrPdAddressArgs 函数存在未校验入参指针有效性的问题，在9500 HBA卡初始化不完整或未就绪时，传入了空指针，最终触发非法内存访问，导致BMC主进程 framework 崩溃。

2. 触发条件

• 在 AC Power Cycle（上下电）测试 中，BMC启动时尝试初始化RAID/HBA卡驱动。
• 9500 HBA卡尚未完成硬件或固件初始化，但BMC已尝试与其通信。
• 驱动层 libraidblibit.so 在获取设备状态或事件回调时，未能正确处理空状态对象，直接使用了NULL指针。

---

涉及系统组件

组件	说明
RAID卡 (9500系列)	出现问题的硬件设备，型号为博通9500系列HBA/RAID控制器卡
BMC (Baseboard Management Controller)	管理服务器硬件监控的独立控制器
OpenUBMC2509	当前运行的BMC固件版本
libraidblibit.so	RAID卡底层驱动库，负责与RAID控制器通信
framework 进程	BMC核心管理进程，承载多个服务模块，崩溃将导致BMC功能瘫痪

---

解决方案建议

1. 驱动层修复：增加空指针检查

应在 FillMrPdAddressArgs 等关键函数中加入防御性判断：

if (!valid_controller || !event_data || !output_arg) {
    LOG_ERROR("Invalid NULL pointer in FillMrPdAddressArgs");
    return -1; // 或适当错误码
}

建议由驱动开发者对 libraidblibit.so 进行代码审查与加固。

2. 延迟RAID卡服务启动，加入硬件就绪检测

在AC重启场景下，应等待RAID卡完全初始化后，再启动对其的监控服务。

可参考以下策略：

• 查询PCIe设备状态（BDF状态码）
• 使用 ipmitool 或 MCTP 探测设备响应
• 引入超时重试机制，避免阻塞主进程

3. 隔离RAID服务为独立进程

建议将RAID相关服务从 framework 主进程中剥离，运行在独立的守护进程中，即使发生崩溃也不会导致整个BMC系统不可用。

此为高可用性设计的推荐架构（micro-service 架构）。

4. 异常捕获与容错机制

在调用第三方驱动库（如 libraidblibit.so）时，可通过以下方式降低风险：

• 使用 dlopen() 动态加载并监控
• 结合 setjmp/longjmp 或信号屏蔽进行容错
• 记录完整上下文日志供后续分析

---

参考证据链

1. 知识图谱实体支持：

   • RAID卡 是PCIe设备，负责存储管理（描述：硬件组件用于管理多个磁盘驱动器）
   • OpenUBMC2509 是当前运行的BMC软件版本，在多个上下文中被确认为现网部署版本
   • BMC Interface 显示RAID卡数量为0时，表示检测失败

2. 日志堆栈指向：

   • 崩溃位于 libraidblibit.so 内部函数
   • 调用路径与RAID卡事件监听线程一致

3. 相似问题案例（参考 link https://discuss.openubmc.cn/t/topic/2414）：

   • 博通HBA卡在OpenUBMC上的适配已知存在问题
   • 社区讨论指出需优化驱动初始化时序与异常处理

---

临时规避措施

在问题未修复前，可采取以下措施临时规避：

方法	操作
禁用RAID事件监控线程	修改配置文件或启动脚本，关闭 RAID Event Polling 相关服务
增加AC延迟	在BMC启动脚本中加入延迟（例如 sleep 30），等待HBA卡就绪
更新或降级RAID卡固件	检查9500卡是否有已知兼容性固件版本
使用华为BMC对比测试	如文档提及“华为BMC能正常识别”，可作为功能对标参考

---

结论

本问题的根本原因是：
libraidblibit.so 驱动库未对输入参数做空指针检查，在9500 HBA卡未初始化完成时即被调用，导致 FillMrPdAddressArgs 函数访问空地址，引发 SIGSEGV 段错误，最终使BMC核心进程 framework 崩溃。

推荐行动项

优先级	措施
高	在 FillMrPdAddressArgs 等函数中添加空指针校验
高	将RAID监控服务从主进程剥离，防止单点崩溃影响全局
中	增加AC启动后对RAID卡就绪状态的检测逻辑
低	提供完整 .so 文件符号表，便于后续快速定位崩溃位置

建议提交缺陷单至驱动维护团队，并引用日志堆栈信息辅助修复。

[yelmh_kno07 (huangminghao)]

FillMrPdAddressArgs
代码里没搜到这个函数，用的是同一个storelibit库吗

[iss_yinxiaoning (软通华方_尹晓宁)]

使用的是7.29版本的storelib库代码，加上了其他一些代码合入，目前解决空指针后未出现卡死问题

[huangzhiyu]

“目前解决空指针后未出现卡死问题”，请问是已经解决了吗？没有的话可以解下环境上的coredump文件看看具体是在哪里coredump