一次 VRD 升级后，后续多次出现 VRD 生效记录，且某次 VRD 生效卡住出现无法上电的情况

交流互助区
1

问题描述

1、回退N-3（BMC 5.05.12.25）版本，再升级最新版本（BMC 26.01.52.65）的测试过程中，批量升级了BMC/CPLD/CSR/MCU等固件，没有回退/升级VRD固件，但在版本升级后会出现VRD待生效提示，必现

2、在一次回退和升级测试中，始终卡在VRD生效状态，OS无法上电，大约1小时40分钟后提示生效成功，环境恢复正常

img_v3_0213p_6f3d321a-fda6-4f41-83ca-20b7c6a14ebg
img_v3_0213p_6f3d321a-fda6-4f41-83ca-20b7c6a14ebg1917×917 115 KB

时间线

7 月 16 号升级了 VRD，之后再也没有升级过 VRD 升级包


2026-07-16 02:34:46 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_00 start
2026-07-16 02:34:46 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_00 from version 38 to version 39 successfully
2026-07-16 02:35:19 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_06 start
2026-07-16 02:35:19 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_06 from version 38 to version 39 successfully
2026-07-16 02:35:49 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_07 start
2026-07-16 02:35:49 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_07 from version 38 to version 39 successfully
2026-07-16 02:36:22 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_05 start
2026-07-16 02:36:22 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_05 from version 38 to version 39 successfully
2026-07-16 02:36:57 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_01 start
2026-07-16 02:36:57 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_01 from version 38 to version 39 successfully
2026-07-16 02:37:29 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_02 start
2026-07-16 02:37:29 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_02 from version 38 to version 39 successfully
2026-07-16 02:38:07 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_03 start
2026-07-16 02:38:07 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_03 from version 38 to version 39 successfully
2026-07-16 02:38:42 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_04 start
2026-07-16 02:38:42 INFO : SVR-0000000,Upgrade VRD chip VRD_01_00_04 from version 38 to version 39 successfully
2026-07-16 02:38:42 INFO : SVR-0000000,Upgrade Vrd from version 38.38.38.38.38.38.38.38 to version 39.39.39.39.39.39.39.39 successfully
2026-07-16 02:38:59 INFO : SVR-0000000,Upgrade (Vrd) with (KunLun-2280V2-BCU(BC83AMDA)-VRD_39.hpm) from version(38.38.38.38.38.38.38.38) successfully

理论上，VRD 应该下电时就生效一次，但从日志看，近几天 VRD 发生了好几次生效，总是莫名奇妙蹦跶一下（看起来没有什么出现规律，中间经历了 N 次 BMC 重启、PowerCycle 和 ACCycle，该生效早生效了）
operation.log.1


2026-07-16 06:09:03 N/A,N/A@localhost,firmware_mgmt,Active (VRD) to successfully
2026-07-17 08:06:26 N/A,N/A@localhost,firmware_mgmt,Active (VRD) to successfully
2026-07-17 09:39:24 N/A,N/A@localhost,firmware_mgmt,Active (VRD) to successfully

在版本回退/升级测试中，没有升级 VRD 固件，仅更新 BMC/BIOS/CPLD/MCU 等，却又蹦出了 VRD 生效，而且生效过程卡住了接近 2 小时，期间 OS 无法上电

日志一：在版本升级过程中，明明没有升级 VRD，却出现了 VRD 待生效，且卡住（是卡住的现场日志）

KunLun2280V2_2102315MSA10R8100018_20260720-0631.tar.gz (9.3 MB)

日志二：两小时后，超时后操作日志记录生效成功（wait_except_cpld_to_ready_status 等待超时了）

KunLun2280V2_2102315MSA10R8100018_20260720-0735.tar.gz (8.9 MB)

环境信息

26.01.52.65 版本

2

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

总结与建议

结合上下文，问题链条可以描述如下：

  1. 7月16日的VRD升级是“缓存升级”，固件并未真正生效。
  2. 后续每次系统下电，都会尝试对缓存的固件进行“Active”操作，导致日志中反复出现生效记录。
  3. 在一次涉及MCU重启的版本升级中，MCU的初始化动作触发了VRD的“Active”流程。
  4. 该“Active”流程在等待CPLD就绪时超时，导致VRD生效卡住。
  5. 由于“上电锁”机制生效，系统在VRD生效完成前禁止上电，因此出现“OS无法上电”的现象。
  6. 在2小时超时后，系统可能强制跳过了该流程或清除了异常状态，从而日志中记录为“生效成功”。

建议的排查方向：

  • 检查MCU与VRD的通信状态：确认是否存在已知的MCU固件Bug，或者MCU与VRD之间的SMBus/SMC协议通信不稳定。
  • 检查CPLD版本与状态：确认CPLD固件版本是否与当前BIOS/BMC等固件版本兼容。日志中“等待CPLD就绪”超时是直接原因，需要定位CPLD为何未能及时就绪。
  • 确认VRD缓存标志是否被异常清除：是否有机制确保缓存队列在执行一次后就被清空，避免反复生效。
点击此处查看详细分析解答

根据您提供的日志和描述，并结合知识库中的信息，以下是对该问题的详细分析和解释。

问题分析

您遇到的情况核心矛盾在于：

  1. 未主动升级，却持续生效：在7月16日完成VRD升级后，后续几天（7月17日、18日等）日志中持续出现“Active (VRD) to successfully”的记录，尽管并未再次进行VRD升级。
  2. 意外生效导致卡住：在一次未包含VRD的版本升级过程中，系统触发了VRD的生效流程，且该流程卡住了近2小时，导致OS无法上电。

根据知识库中的信息，可以解释这些现象背后的原因：

1. 为何会出现非预期的“Active (VRD)”记录？

VRD升级的生效机制是“延迟激活”或“缓存生效”的。

  • 知识库依据：文档明确指出，VRD升级必须在下电状态下才能真正生效。在系统上电时，升级文件会被缓存起来，等待系统下电时再执行Active（生效）阶段。
  • 现象解释：您在7月16日完成的升级是一个“缓存的升级”。这意味着这些固件更新并未在升级那一刻立即生效，而是被临时存储。在后续的每一次系统下电（例如：正常关机、重启、断电等）过程中，系统都会检查并执行这个缓存队列。因此，7月16日之后记录中的多次“Active (VRD)”，很可能就是系统在每次下电时，对之前缓存的那个“_39.hpm”升级包重复执行生效操作。

2. 为何未升级VRD，也会触发它的生效？

  • 知识库依据：文档介绍了 Sub_component 机制：MCU（Microcontroller Unit）负责管理其下的子组件，如VRD。这意味着VRD的升级和生效流程并非完全独立，它受MCU管理。
  • 现象解释：在您描述的“仅更新BMC/BIOS/CPLD/MCU等”的场景中，当MCU被升级或重启时，它会重新初始化并检查其管理的所有子组件的状态。此时，MCU可能会错误地判断VRD有等待生效的固件（可能是残留的缓存标志），从而触发VRD的Active流程。

3. 为何生效会卡住近2小时并导致OS无法上电？

  • 知识库依据：知识库描述了VRD生效的一个关键前提——上电锁机制。该机制是为了防止在VRD固件更新期间系统意外上电，导致CPU供电异常或损坏。
  • 现象解释：
    • 卡住原因：日志中记录的错误是“wait_except_cpld_to_ready_status 等待超时了”。这表明系统在等待CPLD（Complex Programmable Logic Device）进入“就绪”状态时超时。CPLD在系统启动过程中扮演关键角色，负责上电时序、复位信号等。如果CPLD状态不正常，或者与VRD的通信出现问题，VRD的Active流程就会卡在等待环节。
    • 无法上电：当VRD被触发进入生效流程时，系统会激活“上电锁”。在“上电锁”未被释放（即VRD生效流程未完成）之前，系统会阻止任何上电操作，以保护硬件。因此，OS无法上电的现象是符合既定设计逻辑的，是系统为保护CPU和主板免受错误电压影响而采取的安全措施。

总结与建议

结合上下文，问题链条可以描述如下：

  1. 7月16日的VRD升级是“缓存升级”，固件并未真正生效。
  2. 后续每次系统下电，都会尝试对缓存的固件进行“Active”操作，导致日志中反复出现生效记录。
  3. 在一次涉及MCU重启的版本升级中，MCU的初始化动作触发了VRD的“Active”流程。
  4. 该“Active”流程在等待CPLD就绪时超时，导致VRD生效卡住。
  5. 由于“上电锁”机制生效，系统在VRD生效完成前禁止上电，因此出现“OS无法上电”的现象。
  6. 在2小时超时后，系统可能强制跳过了该流程或清除了异常状态，从而日志中记录为“生效成功”。

建议的排查方向：

  • 检查MCU与VRD的通信状态：确认是否存在已知的MCU固件Bug，或者MCU与VRD之间的SMBus/SMC协议通信不稳定。
  • 检查CPLD版本与状态：确认CPLD固件版本是否与当前BIOS/BMC等固件版本兼容。日志中“等待CPLD就绪”超时是直接原因，需要定位CPLD为何未能及时就绪。
  • 确认VRD缓存标志是否被异常清除：是否有机制确保缓存队列在执行一次后就被清空，避免反复生效。
3

KunLun2280V2_2102315MSA10R8100018_20260721-1316.tar.gz (8.8 MB)

单独降级 BMC 到 5.5.12.25 的日志

4

老版本（5.5.x）：升级时创目录（/data/backup/vrd/up_cfg），升级完删目录（确认了能删掉，但只有成功才删，如果目录下本身没有文件，也不会删除）
新版本（26.x / openubmc）：升级时创目录，升级后不删目录

老版本：若目录存在，则往数据库添加待生效固件

因此在新版本升级 VRD 后，目录不会删除，再从新版本回退到老版本，由于目录存在，就会往数据库增加待生效 VRD 固件；
再从老版本升级到新版本，待生效固件的数据库就会被带到新版本上，于是会在新版本上重复尝试生效 VRD，但因为目录下没有包，又无法生效成功，于是 firmware 模块不断下发尝试，在与其它固件一起生效的场景，可能因为某些竞争和依赖关系导致死锁卡住；