答案内容由AI生成，仅供参考：
总结
本次问题属于 BMC 异常重启（原因码 0x10），直接诱因是 storage 组件连续离线并触发 maca 看门狗保护性复位，同时 hardware 组件出现空值调用错误。根源可能在于：
- Storage 组件初始化或通信存在时序缺陷；
- 硬件访问失败导致对象状态异常；
- 系统重启策略未合理处理组件启动阶段的不稳定状态。
建议优先升级到 26.03 或更高版本（参考 Document Chunks 8 中 330 基线的修复），并对照 framework.log 和 hardware 日志定位具体崩溃点；若问题持续，可向 OpenUBMC 社区提交一键收集日志以获得进一步支持。
点击此处查看详细分析解答
根据您提供的问题描述和日志信息，结合知识库中的知识图谱与文档内容，现对 OpenUBMC 2512 版本强制重启 BMC（复位原因码 0x10） 的问题进行分析与回答。
问题概要与原因码含义
您报告的日志显示 BMC 强制重启，复位原因码为 0x10（十进制 16）。在 OpenUBMC 系统中，事件码 0x1A00006F 会关联不同的复位原因码，其中：
- 0x2：通常与 UID 按钮长按复位、Web 正常重启或内核 panic 相关（参见 [知识图谱-事件
The OpenUBMC Is Reset With The Cause Code Of 0x2] 及论坛回复）。 - 0x10：表示 BMC 因组件异常或服务故障而重启，常见于服务进程崩溃、看门狗超时或系统初始化失败等场景（参见 [知识图谱-事件
The OpenUBMC Is Reset With The Cause Code Of 0x10]）。
论坛成员 linyao 在相关问题中提到：“code 是 0x10 可以看下是否有组件异常重启，检查一下 framework.log”（参考 Document Chunks 1）。此外，社区在 AC 测试复现类似问题，日志显示 skynet 进程不断崩溃并产生 core dump，最终导致看门狗超时触发硬件重启，上报原因码 0x10（参考 Document Chunks 3）。
您日志中的关键线索
您提供的日志包含两条关键信息：
maca ERROR: base.lua(249): [storage] continuously offline 5 times within 10 minutes, rebooting...
hardware: attempt to call a nil value
- storage 组件连续离线：
storage组件在 10 分钟内连续 5 次被识别为离线，触发 maca 框架的保护性重启机制。
这与知识库中的 BMC Abnormal Restart（因服务失败导致系统不稳定而重启）以及 init service failed（关键初始化服务启动失败）概念一致。 attempt to call a nil value：表明在硬件访问过程中出现了空值调用，这可能是硬件状态读取失败、通信中断或对象未正确初始化的表现。
此类错误常与 BMC.Error.Uncnlow（I2C 读取超时或硬件内部错误）有关，需要硬件层面排查（论坛用户 lisongwei 也强调过硬件协调与调试的必要性）。
推荐排查方向
结合知识库中的案例和现有分析，建议按以下步骤深入定位：
1. 检查 framework.log 与组件日志
- 查看 framework.log 中与
storage组件相关的详细错误，确定离线原因（如通信超时、对象创建失败、数据持久化问题）。 - 检查
hardware组件日志（例如general_hardware或storage组件日志），定位出现 nil 值的具体函数和上下文。
在参考文档 Document Chunks 10（NVMe 盘信息丢失问题）中，类似的nil value错误出现是因为 NVMe 对象创建失败，可能与初始化时序有关。
2. 验证硬件与固件交互
- 确认 NCSI 线缆、OCP 卡、电源等硬件连接是否稳定（参考 Document Chunks 8 四电源环境重启 BMC 问题）。
- 检查是否存在 I2C 总线故障或设备未就绪导致的空指针访问（参考知识图谱中 BMC.Error.Uncnlow 的分析）。
3. 关注社区已修复的同类问题
- Document Chunks 8 中提到，四电源环境下概率性电源冗余丢失告警已在 330 版本 修复，涉及模块间启动时序调整。
您当前使用 2512 版本，建议升级到包含相关修复的版本。 - Document Chunks 5（BBU 告警复位问题）提供了 CSR 配置属性
InvalidReadingIgnore和InvalidReading的使用方法，类似机制可能适用于解决告警误触发或异常复位。
4. 分析概率性与批次性因素
- 您提供的数据显示异常概率约为 20%~38%，这可能与 硬件批次差异 或 启动时序竞争 有关。
社区用户 昆仑太科_安阳阳 也曾报告过重启 BMC 解决临时状态问题的案例（重启可刷新状态），但若根本原因未解决，重启仍会反复发生。
参考链接与资源
- 知识库事件：
The OpenUBMC Is Reset With The Cause Code Of 0x10BMC Abnormal Restartinit service failed
- 论坛相关讨论：
- 问题求助：BMC上电升级BIOS无法使用强制重启（参考 Document Chunks 2）
- 事件码 0x1A00006F 对应 0x2 与 0x10 含义（参考 Document Chunks 1）
- 社区已发布的修复：
- BBU告警消除后产生问题 PR（参考 Search Result 5）
- AC重启后内存丝印问题 PR（参考 Search Result 7，其中提到等待 90s 让所有服务就绪的策略）
总结
本次问题属于 BMC 异常重启（原因码 0x10），直接诱因是 storage 组件连续离线并触发 maca 看门狗保护性复位，同时 hardware 组件出现空值调用错误。根源可能在于：
- Storage 组件初始化或通信存在时序缺陷；
- 硬件访问失败导致对象状态异常；
- 系统重启策略未合理处理组件启动阶段的不稳定状态。
建议优先升级到 26.03 或更高版本（参考 Document Chunks 8 中 330 基线的修复），并对照 framework.log 和 hardware 日志定位具体崩溃点；若问题持续，可向 OpenUBMC 社区提交一键收集日志以获得进一步支持。