BMC 25.03版本在双riser双raid场景下必现自动重启问题

Infrastructure SIG
1

背景：

使用社区25.3版本在双RAID场景下必现BMC自动重启(重启间隔大概10分钟）的问题，后经定位后发现为storage组件在双riser双raid场景下，skynet注册服务ID冲突导致raid挂死进而引发后续的内存泄漏问题；

述求：请帮忙分析下上诉内存泄漏的问题是否能在代码静态检查中拦截？

相关的log及社区修复的MR如下：

修复双riser双raid场景,skynet注册服务Id冲突导致raid服务挂死问题-storage-AtomGit | GitCode

重启时BMC串口日志.txt (386.0 KB)

2

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

BMC 多 RAID 卡多盘环境下重启问题分析

根据提供的串口日志内容，BMC在多RAID卡、多硬盘的复杂存储环境下出现异常重启，根本原因已定位为 内存耗尽（Out of Memory, OOM）导致系统触发保护性杀进程机制，进而引发BMC重启。

:magnifying_glass_tilted_left: 问题根本原因分析

:pushpin: 关键日志证据

从串口日志中提取的核心信息如下：

[ 354.569685] Hardware name: Hisilicon Hi1711 ASIC (DT)
...
[ 354.652909] Mem-Info:
    active_anon:621 inactive_anon:377616
    mapped:13814 shmem:28203 pageTables:2677
    free:10734 free_pcp:62 free_cma:0
...
[ 355.003501] Out of memory: Killed process 2325 (skynet) total-vm:4124952kB, anon-rss:420496kB, ...

上述日志明确显示：

  • 系统检测到 内存资源严重不足
  • 内核 oom_kill_process 被触发
  • skynet 进程（BMC系统中的核心服务调度框架）被强制终止
  • 此类关键系统进程终止后，通常会导致 BMC 整体不可用并触发自动重启

:puzzle_piece: 为什么在多RAID卡多盘场景下更容易发生？

结合知识库信息与实际系统行为，可归纳以下几点：

1. RAID卡管理组件资源消耗大

  • 多RAID卡环境意味着 BMC 需要同时监控多个控制器、物理磁盘（PD）、逻辑磁盘（LD）和背板状态。
  • 每个设备都需要创建对应的传感器（Sensor）、事件日志条目（SEL）、状态监控线程等，显著增加内存占用。
  • 若 RAID 管理模块存在内存泄漏或未优化的数据结构（如缓存过大），在设备数量增多时会迅速耗尽内存。

相关知识支持：GetControllerInfo、GetFPCMemoryRecords 等方法会返回包含大量 Details 结构体的数据数组，这些结构在内存中驻留可能导致峰值使用上升。

2. BMC 默认内存配置有限

  • BMC 运行在嵌入式环境中，物理内存通常为 512MB ~ 1GB，且需服务众多后台进程（如 Redfish、IPMI、web server、skynet 调度器等）。
  • skynet 是 openUBMC/iBMC 中的核心服务管理框架，承担模块间通信与调度任务。一旦其 RSS（常驻内存集）超过系统阈值，极易成为 OOM killer 的首要目标。

知识佐证：搜索结果中提到，“bmc_core 达到 512M 内存使用阈值，触发重启” —— 说明这是已知的系统风险边界。

3. 文件系统缓存竞争加剧

  • 日志显示 filemap_fault 和 pagecache_get_page 调用频繁，表明系统正在进行大量页面缓存操作。
  • 在 ext4 文件系统上运行时，若日志服务（如 Rsyslog）、dump 收集、配置持久化等同时写入磁盘，也会加剧内存压力。
  • free:10734 pages（约 43MB，按每页4KB计算）表明可用内存极低。

:warning: 影响范围与典型表现

现象 是否匹配
BMC 无预警重启 :white_check_mark: 匹配
Web 页面无法访问、SSH 登录中断 :white_check_mark: 常见后遗症
app.log 时间显示为 1970-01-01（系统时间未同步或文件系统未正常挂载） :white_check_mark: 与崩溃重启一致
skynet 或 bmc_core 异常退出 :white_check_mark: 日志直接证实

:white_check_mark: 解决方案与建议

1. 优化内存使用，防止 OOM

（1）降低 skynet 或相关模块内存占用

  • 审查 my_app、bmc_core、storage 等自定义或第三方组件是否存在内存泄漏。
  • 参考知识库：my_app 已知存在失败启动和重复重启问题，可能间接加重负载。

（2）限制非关键服务优先级

  • 对非核心服务（如日志归档、统计采集）启用 优雅降级机制，在内存紧张时暂停运行。
  • 启用 libmcpp 框架的资源监控功能，实时预警高内存使用进程。

2. 升级固件版本，修复已知 Bug

参考知识库中类似问题的解决方案：

案例 Q12（升级常见问题指南）：
“bmc_core 存在内存泄漏，达到 512M 内存阈值触发重启。”
规避措施：

rm /data/opt/bmc/upgrade/profile_en*
systemctl restart bmc_core

建议：

  • 确认当前 bmc_core、ipmi_core 版本是否为最新稳定版。
  • 升级至以下推荐版本以规避已知内存问题：
    • ipmi_core >= 1.10.37
    • firmware_mgm >= 1.10.44

3. 配置内核 OOM 行为与监控

（1）调整 OOM killer 策略

  • 为关键进程（如 skynet）设置较低的 oom_score_adj 值（例如 -500），避免被误杀。

（2）增加 swap 空间（谨慎使用）

  • 在 flash 空间允许的情况下，可配置小量 swap 分区作为应急缓冲（注意寿命损耗）。

（3）启用内存监控告警

  • 使用 SNMP、Redfish API 定期采集内存使用率，提前预警。

4. 检查 RAID 卡兼容性与驱动优化

  • 确保所有 RAID 卡固件版本与 BIOS、BMC 兼容。
  • 检查是否存在频繁的 phy error 或 SEL 告警（可通过 \\dump_info\\AppDump\\sensor_alarm\\eo_sel 分析），此类异常可能导致 BMC 不断重新探查设备，增加 CPU 与内存开销。
  • 参考知识库中“RAID卡管理解耦”特性设计，建议采用 标准化接口 + 动态加载 SDK 的方式，减少内存驻留模块数量。

:clipboard: 总结

项目 内容
问题类型 BMC 因内存耗尽导致 OOM Kill，进而重启
直接原因 skynet 进程因高内存占用被杀
根本诱因 多 RAID 卡、多硬盘场景下系统资源开销过大，内存管理不当
解决方案 1. 升级固件避免已知内存泄漏
2. 优化 bmc_core、my_app 等组件内存使用
3. 调整 OOM 策略保护关键进程
4. 加强资源监控与告警机制

:white_check_mark: 建议操作流程：

  1. 采集完整一键日志，重点分析 app.log、bmc_core.log 和 sel.log
  2. 检查 bmc_core 是否存在内存泄漏
  3. 删除升级残留文件并重启服务：
    rm /data/opt/bmc/upgrade/profile_en*
systemctl restart bmc_core
  4. 如问题仍存在，考虑升级至官方推荐版本或联系技术支持提供针对性补丁。

:pushpin: 参考资料链接：

  • openUBMC 社区讨论
  • 《升级常见问题指南》Q12
  • 《IPMI管理定位问题》Q5/Q8
  • 《持久化机制常见问题》datafs_reset 案例分析

相关链接：

  1. BMC界面出现内存、CPU为0，上下电操作功能无法点击
  2. 冷重启多次测试后，nvme盘的BMC信息磨​损率丢失
  3. 300I ATLAS DUO卡适配后，多张卡插入后只有一张显示内存容量
  4. 无法获取raid卡信息，报错1104，控制器初始化未完成
  5. 1.特性概述 | 文档中心 | openUBMC
3

@huangzhiyu 帮忙看下 有没有静态检查的能力