A3 机型带DPU的AC 稳定性测试过程中出现OS 不执行开机策略

yuhan_chen · 2026 年7 月 9 日 01:01

问题描述

在执行AC 稳定性测试中，发现两次都是由于一些服务异常导致bmc 重启后不执行开机策略，这个是怎么查看是由于哪些异常引起和怎么修复吗

重现步骤

装上DPU 2.5
执行上电 –>查看os 是否开机–>如果开机就发送ipmi命令关机–>执行下电
循环步骤1 2 就可以复现

期望结果

期望可以AC 100次以上

实际结果

实际上bmc 会因为服务异常导致重启，重启后执行不了开机策略了。

分析结论

1.在执行上电过程中发现bmc 有执行重启
app.log 日志有如下记录
bmc_reset_type is soft_reset

2.running.log 日志里面有如下记录
some service failed to start, and BMC will attempt to restart for recovery

3.maintenance.log 日志里面有如下记录
SVR-0000000,The BMC is reset, with the cause code of 0x10. 0x1A00006F

4.发现这个过程有相关dpu 异常错误但，不确认是不是由于这里重启

这些怎么确认是由于什么原因导致的吗？

日志：

Atlas800IA3_2102315QYP10RC100020_20260706-0907.tar.gz (8.6 MB)

ubmc_assistant · 2026 年7 月 9 日 01:07

答案内容由AI生成，仅供参考：
根据您的要求，我仔细查看了提供的回答内容。其中没有明确标有“问题总结”、“总结”、“解决方案”或“结论”等字样的章节作为标题。

因此，按照您的指示，返回空内容。


[details="点击此处查看详细分析解答"]
根据提供的上下文信息，针对您描述的“AC稳定性测试中OS不执行开机策略”问题，以下是基于知识库的分析与建议。

---

## 一、可能原因分析

### 1. 组件启动失败引发BMC复位
在AC稳定性测试中，BMC复位经常由关键初始化服务启动失败触发。例如，在相似案例（文档6）中，**certificate组件拉起异常**导致BMC复位，随后`fructrl`组件读取到的复位类型为`soft_reset`（软复位），根据规则：
> **规则21：软复位不走通电开机策略**（文档4）

因此，即使系统配置了“保持上电”的通电开机策略，也会因复位类型误判而**跳过执行**。

### 2. 复位类型获取不准确
`fructrl`组件依赖`mc_sys_info.get_reset_type`方法获取复位类型，但该方法在特定场景下可能返回不准确的结果。例如，在AC掉电再上电（实际应为硬复位）时，错误地识别为`soft_reset`，导致通电开机策略被跳过（文档8）。

### 3. DPU上电锁时序干扰
您的日志中出现DPU相关异常。在文档6的分析中，AC通电后系统下发上电通知，但DPU在OS启动完成后释放上电锁时，恰与BMC复位重叠，导致正式上电未完成，进一步影响开机策略的执行。

---

## 二、如何定位具体异常原因

根据上下文提供的定位方法，建议按以下步骤排查：

### 步骤1：查看`running.log`中失败的服务
日志中已出现`some service failed to start`提示。打开`running.log`，查找关键字`[FAILED]`或`failed to start`，确定具体是哪个组件（如`certificate`或`Rsyslog`等）启动失败。

### 步骤2：分析`maintenance.log`中的复位原因码
日志记录：`The BMC is reset, with the cause code of 0x10. 0x1A00006F`  
其中`0x10`属于复位原因标识组，参照文档7中的表1（BMC复位原因标识），`0x10`对应“命令复位”中的`00h`（BMC重启操作复位）？但表1中给出的范围是`00h ~ 0Fh`为命令复位组，`0x10`超出该范围，可能表示其他原因。建议结合`0x1A00006F`进一步分析，这可能是更详细的子码。

### 步骤3：确认BMC复位类型
在`app.log`中已查到`bmc_reset_type is soft_reset`，这直接解释了为何通电开机策略未执行。但需要进一步确认该复位类型获取是否正确：您可检查`fructrl`组件的日志，看其读取复位类型时的原始信号来源（参见文档8中对`bmc_soc`和`BmcResetType`属性的设计）。

### 步骤4：查看DPU相关日志
关注DPU启动过程中是否有异常事件，例如上电锁释放时间点与BMC复位时间的重合。可搜索`dpu`或`power lock`等关键词。

---

## 三、修复建议（基于上下文）

### 1. 修复启动失败的组件
根据失败的服务类型，采取对应措施：
- 如果`certificate`组件异常，检查其配置或依赖项是否完整，可尝试重新启动该服务或恢复默认配置。
- 如果`Rsyslog`等日志服务异常，参考文档3中的解决方案（如烧片BMC或重启相关服务）。

### 2. 避免BMC软复位误判
当前版本中，`fructrl`使用`mc_sys_info.get_reset_type`可能不准确。社区已提出改进方案（文档8）：
- 新增资源协作接口`bmc.kepler.Managers.BmcReset`，提供准确的`ResetType`属性。
- 在上层逻辑中，由`bmc_soc`在硬复位后将`BmcHardResetFlag`置零并写该属性为0，`fructrl`依据该属性而不是芯片信号判断复位类型。

**临时规避**：可在AC测试前，手动确保关键组件稳定运行，降低复位概率。或考虑在BMC启动后延迟执行通电开机策略，给组件完成初始化留出缓冲。

### 3. 调整测试流程或时序
文档6提到的DPU上电锁干扰问题，可考虑：
- 在DPU OS完全启动并释放锁之后，再允许BMC执行开机策略。
- 或通过调整BMC复位时的同步逻辑，避免复位时机与上电锁释放重叠。

### 4. 升级或应用补丁
联系设备供应商或社区，确认是否有针对`fructrl`复位类型判断问题的补丁。在文档8中该方案已进入评审，后续版本可能修复。

---

## 总结

| 步骤 | 操作 | 对应上下文 |
|------|------|------------|
| 查看`running.log` | 定位具体失败服务 | 文档6 |
| 分析`maintenance.log`原因码 | 对照复位原因表 | 文档7 |
| 确认`reset_type`获取方式 | 检查`fructrl`组件 | 文档8 |
| 修复失败组件 | 重启或恢复默认配置 | 文档3 |
| 关注DPU时序 | 调整上电锁与BMC复位同步 | 文档6 |
| 升级或打补丁 | 等待社区修复复位类型问题 | 文档8 |

如果以上仍无法解决，建议将详细日志发送至社区专家（如`wanghaozhou2@huawei.com`）进行进一步分析。
[/details]

caiyesheng_b48v3 · 2026 年7 月 9 日 01:16

请补充下你的BMC固件来源和版本

yuhan_chen · 2026 年7 月 9 日 02:29

bmc 固件为 25.12 LTS_SP1

yuhan_chen · 2026 年7 月 10 日 02:39

大佬们，可以帮忙分析指导下怎么分析吗

grlxw · 2026 年7 月 13 日 07:32

这应该是之前由于AC后还没来得及执行通电开机策略就bmc重启了，而bmc重启不会执行通电开机策略，但针对这种场景2606版本已解决了

yuhan_chen · 2026 年7 月 14 日 05:15

这个是哪里导致bmc 重启吗，看门狗还是哪些异常吗？

luohao211737 · 2026 年7 月 14 日 06:17

2026-07-04 23:37:54.518406 maca NOTICE: init.lua(243): recheck startup status completely, total components count: 58, normal count: 57, abnormal components: [“power_mgmt”]

2026-07-04 23:37:54.673561 maca NOTICE: init.lua(244): Success to record BMC reset cause, code: 16

2026-07-04 23:37:54.674104 maca NOTICE: init.lua(271): Force Reset begin

2026-07-04 23:37:54.674430 maca NOTICE: init.lua(137): BMC reset type:normal system

2026-07-04 23:37:55.300808 maca NOTICE: init.lua(100): stop watchdog timer

power_mgmt组件一直拉不起来导致BMC重启

yuhan_chen · 2026 年7 月 14 日 06:32

这个是不是更新power_mgmt 组件到2606可以解决，还是怎么修复吗

luohao211737 · 2026 年7 月 14 日 06:37

2606只是解决了BMC异常重启不执行开机策略的问题，异常重启本身应该还需要单点分析，说白了只是加了个补救措施，没有从根本上解决问题

yuhan_chen · 2026 年7 月 14 日 06:43

2026-07-04 23:37:04.155590 hwdiscovery WARNING: harbor_client.lua(367): shm reply failed, path: /bmc/kepler/ObjectGroup/01010217, interface: bmc.kepler.ObjectGroup, member: GetBinaryObjects, ret: message_queue push back: data size too large
2026-07-04 23:37:14.957133 hwdiscovery WARNING: harbor_client.lua(367): shm reply failed, path: /bmc/kepler/ObjectGroup/01010117, interface: bmc.kepler.ObjectGroup, member: GetBinaryObjects, ret: message_queue push back: data size too large
2026-07-04 23:37:23.415920 hwdiscovery WARNING: harbor_client.lua(367): shm reply failed, path: /bmc/kepler/ObjectGroup/01010117, interface: bmc.kepler.ObjectGroup, member: GetBinaryObjects, ret: message_queue push back: data size too large
2026-07-04 23:37:29.400108 [:0000000b] alarm: Memory warning 32.00 M

好像这个前面有这些导致的，这个怎么排查哪里导致这个队列满了

luohao211737 · 2026 年7 月 14 日 06:47

这就超出我的能力范围了，得让SDK的人来看

yuhan_chen · 2026 年7 月 14 日 06:51

看来不好搞。

yuhan_chen · 2026 年7 月 15 日 02:25

2026-07-04 23:36:46.333014 hwdiscovery NOTICE: init.lua(201): position: 0101050500, get csr data from /opt/bmc/sr/Dual_Rotator_1.sr, format version: 3.00, data version: 3.00
2026-07-04 23:36:46.452969 hwdiscovery NOTICE: parser_work.lua(76): position: 0101050500, process sr data successfully, uptime: 257 s, cost: 70ms
2026-07-04 23:36:47.052818 hwproxy NOTICE: app_objects.lua(270): scanner: Scanner_Fan_Presence_0101050500 scan enabled initial value: 0
2026-07-04 23:36:53.808641 maca ERROR: init.lua(184): [power_mgmt]StartupCheck failed, error: org.freedesktop.DBus.Error.UnknownObject: Unknown object path /bmc/kepler/power_mgmt/MicroComponent, check count: 4
2026-07-04 23:37:02.239114 persistence WARNING: persistence_task_schedule.lua(264): A storm occurs in table t_fructrl_tb
2026-07-04 23:37:04.155590 hwdiscovery WARNING: harbor_client.lua(367): shm reply failed, path: /bmc/kepler/ObjectGroup/01010217, interface: bmc.kepler.ObjectGroup, member: GetBinaryObjects, ret: message_queue push back: data size too large
2026-07-04 23:37:14.957133 hwdiscovery WARNING: harbor_client.lua(367): shm reply failed, path: /bmc/kepler/ObjectGroup/01010117, interface: bmc.kepler.ObjectGroup, member: GetBinaryObjects, ret: message_queue push back: data size too large
2026-07-04 23:37:23.415920 hwdiscovery WARNING: harbor_client.lua(367): shm reply failed, path: /bmc/kepler/ObjectGroup/01010117, interface: bmc.kepler.ObjectGroup, member: GetBinaryObjects, ret: message_queue push back: data size too large
2026-07-04 23:37:29.400108 [:0000000b] alarm: Memory warning 32.00 M
2026-07-04 23:37:54.518406 maca NOTICE: init.lua(243): recheck startup status completely, total components count: 58, normal count: 57, abnormal components: [“power_mgmt”]
2026-07-04 23:37:54.673561 maca NOTICE: init.lua(244): Success to record BMC reset cause, code: 16
2026-07-04 23:37:54.674104 maca NOTICE: init.lua(271): Force Reset begin
2026-07-04 23:37:54.674430 maca NOTICE: init.lua(137): BMC reset type:normal system
2026-07-04 23:37:55.300808 maca NOTICE: init.lua(100): stop watchdog timer

这个有人帮忙看下吗，是不是由于AC 后启动，消息过多，导致处理不过来，导致这些组件注册不上，从而导致maca 检查组件启动状态失败后，导致重启bmc ？
大佬们帮忙看下。

zhangbaocun · 2026 年7 月 16 日 09:08

这个组件检查失败了

yuhan_chen · 2026 年7 月 16 日 10:12

这个是怎么导致检查失败尼？是不是因为有以下信息？
harbor_client.lua(367): shm reply failed, path: /bmc/kepler/ObjectGroup/01010217, interface: bmc.kepler.ObjectGroup, member: GetBinaryObjects, ret: message_queue push back: data size too large

zhangbaocun · 2026 年7 月 17 日 02:27

这个你要看这个组件启动为什么失败了

yuhan_chen · 2026 年7 月 17 日 05:10

可以帮忙分析下吗

jiazeyuan · 2026 年7 月 27 日 06:46

这个是正常的，消息太大会切到dbus

jiazeyuan · 2026 年7 月 27 日 06:55

2026-07-04 22:38:34.646582 maca NOTICE: init.lua(243): check startup status completely, total components count: 58, normal count: 56, abnormal components: [“pcie_device”,“power_mgmt”]
2026-07-04 23:07:18.944571 maca NOTICE: init.lua(243): check startup status completely, total components count: 58, normal count: 56, abnormal components: [“bios”,“power_mgmt”]
2026-07-04 23:41:53.078224 maca NOTICE: init.lua(243): check startup status completely, total components count: 58, normal count: 57, abnormal components: [“pcie_device”]
日志这里还有几次启动检查失败，pcie_device、bios组件也有没起来的情况。可以再跑几次复现下，感觉是启动的负载比较大，某些组件需要比较长的启动时间，概率性会超过maca的启动自检时间。

话题		回复	浏览量
LTS SP2版本AC之后BMC异常重启导致上电失败交流互助区提问求助	8	203	2026 年7 月 24 日
ACcycle测试中，上电策略为保持上电，概率出现不开机交流互助区提问求助	6	191	2026 年2 月 14 日
【AC长稳】【组件健康检查失败】组件健康检查失败，导致BMC重启，pcie卡加载失败交流互助区提问求助	4	89	2026 年7 月 3 日
【问题求助】AC压测过程中，通电开机策略为保持上电，偶现服务器不上电交流互助区提问求助	6	132	2026 年5 月 13 日
AC启动，概率出现组件启动异常，有日志提示StartupCheck failed，影响PCIe卡加载交流互助区提问求助	15	308	2026 年7 月 13 日

A3 机型 带DPU的AC 稳定性测试过程中出现OS 不执行开机策略