NPU Atlas 300i A2 64G 在AC测试时带外传感器概率获取不到温度

交流互助区
1

问题描述

Atlas 300i A2 64G 在AC测试时带外概率获取不到温度传感器，NPU界面无法显示序列号，固件版本等信息

环境信息

  • 软件版本：[OpenUBMC2509高可用]

  • 重现步骤

  • 服务器AC重启后，BMC初始化完成后，NPU加载的传感器概率无法获取到温度值，处理器界面无法获取到序列号，固件版本等信息，功耗信息获取正常

期望结果

服务器AC重启后，NPU传感器正常显示温度信息，处理器界面正常显示卡基础信息

实际结果

NPU温度传感器未获取到温度信息

检查compute日志未发现smbus访问错误

2026-01-14 10:26:10.353216 compute DEBUG: NPUCard.lua(509): NPUCard 2 update ChipHealthStatus state:0

2026-01-14 10:26:10.353968 compute DEBUG: NPUCard.lua(510): update fault state:0

2026-01-14 10:26:10.354684 compute DEBUG: app_preloader.lua(95): create co[thread: 0x11a80a1d2968]

2026-01-14 10:26:10.355538 compute DEBUG: app_preloader.lua(58): co[thread: 0x11a80a1d2968] exit

2026-01-14 10:26:10.356386 compute DEBUG: std_smbus.lua(156): receiving data: 0F 00 00 04 00 02 00 00 00 02 00 00 00 F7 02 69

2026-01-14 10:26:10.357563 compute DEBUG: app_preloader.lua(95): create co[thread: 0x11a80a1d2968]

2026-01-14 10:26:10.358617 compute DEBUG: app_preloader.lua(58): co[thread: 0x11a80a1d2968] exit

2026-01-14 10:26:10.359567 compute DEBUG: std_smbus.lua(156): receiving data: 0D 00 00 21 00 00 00 00 00 00 00 00 00 69 00 00 00 00

2026-01-14 10:26:10.360859 compute DEBUG: app_preloader.lua(95): create co[thread: 0x11a80a1d2968]

2026-01-14 10:26:10.361677 compute DEBUG: app_preloader.lua(58): co[thread: 0x11a80a1d2968] exit

2026-01-14 10:26:10.362865 compute DEBUG: std_smbus.lua(156): receiving data: 21 00 00 1D 00 3D 00 00 00 14 00 00 00 06 4C 4D 37 35 41 5F 54 45 23 00 4C 4D 37 35 42 5F 54 45 24 76

2026-01-14 10:26:10.363934 compute DEBUG: app_preloader.lua(95): create co[thread: 0x11a80a1d2968]

2026-01-14 10:26:10.364575 compute DEBUG: app_preloader.lua(58): co[thread: 0x11a80a1d2968] exit

2026-01-14 10:26:10.365391 compute DEBUG: std_smbus.lua(156): receiving data: 21 00 00 00 00 55 00 00 00 14 00 00 00 00 08 00 09 00 0A 00 0B 00 0C 00 0F 00 10 00 11 00 15 00 18 2A

2026-01-14 10:26:10.366405 compute DEBUG: app_preloader.lua(95): create co[thread: 0x11a80a1d2968]

2026-01-14 10:26:10.367072 compute DEBUG: app_preloader.lua(58): co[thread: 0x11a80a1d2968] exit

2026-01-14 10:26:10.367875 compute DEBUG: std_smbus.lua(156): receiving data: 21 00 00 02 00 02 00 00 00 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C2

2026-01-14 10:26:10.368760 compute DEBUG: NPUCard.lua(546): update error codes

2026-01-14 10:26:10.370075 compute DEBUG: NPUCard.lua(509): NPUCard 9 update ChipHealthStatus state:0

2026-01-14 10:26:10.370769 compute DEBUG: NPUCard.lua(510): update fault state:0

2026-01-14 10:26:10.371562 compute DEBUG: app_preloader.lua(95): create co[thread: 0x11a80a1d2968]

2026-01-14 10:26:10.372591 compute DEBUG: app_preloader.lua(58): co[thread: 0x11a80a1d2968] exit

2026-01-14 10:26:10.373522 compute DEBUG: std_smbus.lua(156): receiving data: 0F 00 00 04 00 02 00 00 00 02 00 00 00 F6 02 7C

2026-01-14 10:26:10.374669 compute DEBUG: app_preloader.lua(95): create co[thread: 0x11a80a1d2968]

app.log中重复打印错误日志为：

2026-01-14 06:32:37.488104 compute ERROR: app_preloader.lua(212): ./opt/bmc/apps/compute/lualib/compute_app.lua:662: app(compute/service/main) count(1219) pcall failed(kepler.class.SetSyncPropertyError: The property Health of the object NPU_1_01010502 is a synchronous property and cannot be set)

尝试过的解决方案

在NPU适配时已增加Chip的写延迟设置，增加写延迟后仍复现出故障现象

GPU适配
2

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

Atlas 300I A2 64G 在AC测试时带外传感器概率性获取不到温度问题分析与解决方案

:pushpin: 问题概述

在使用 Atlas 300I A2 64G NPU卡进行AC重启测试时，出现带外传感器概率性无法读取温度数据的问题。同时，NPU卡的序列号、固件版本等基础信息无法正常显示，但功耗信息仍可正常获取。此问题发生在 OpenUBMC 25.09 高可用版本环境中，且重复出现，影响系统监控完整性与可靠性。

:magnifying_glass_tilted_left: 现象详细描述

项目 实际结果
温度传感器读取 概率性失败，部分NPU温度未显示或为0°C
序列号、固件版本等信息 NPU界面无法显示
功耗读取 正常，数据显示准确
compute日志 未发现SMBus通信错误，仅有标准响应数据
app.log异常日志 存在同步属性设置失败错误：The property Health of the object NPU_1_01010502 is a synchronous property and cannot be set

:puzzle_piece: 根本原因分析（基于上下文信息推断）

结合知识图谱、文档切片以及类似历史问题，该问题由多个潜在因素复合导致：

1. NPU对象与NPUCard对象的数据来源不一致

  • Atlas 300I A2卡的温度、健康状态等信息来源于 NPU对象（如 NPU_1），而 Atlas 300I Duo/Pro 等其他型号则通常依赖 NPUCard对象。
  • 根据文档【7】和【5】：
    • 当驱动未加载时，NPU对象的温度默认值为 0，不会触发异常调速或告警。
    • 而 NPUCard对象 会在读取失败时返回 32768 或 32767（表示传感器异常），从而触发监控系统的容错机制。
  • 因此，在AC上电初期、驱动尚未加载完成前，NPU对象返回0°C是“合法”的软性缺省值，但监控系统误认为这是有效数据，导致显示异常或判断滞后。

:white_check_mark: 推论：AC重启后，BMC快速尝试从NPU对象读取温度，但此时OS侧驱动尚未初始化完成，NPU对象无法提供真实温度，返回0，造成“温度丢失”。

2. 信息采集时序竞争（Race Condition）

  • AC重启后，BMC启动速度快于OS及NPU驱动加载。
  • Compute组件在 NPU驱动未完全初始化前 即开始通过带外（SMBus）或混合方式访问 NPU 对象的属性（如 Temperature、SerialNumber、FirmwareVersion）。
  • 若此时NPU设备内部MCU还未完成初始化或未向BMC暴露完整数据接口，则会导致短暂读取失败或返回空/默认值。

尽管log中无SMBus错误（说明通信链路正常），但返回的数据可能为空或无效。

例：日志中部分响应如 0D 00 00 21 ... 表明收到了低层响应，但高层逻辑并未正确解析出有效值。

3. Health 等同步属性设置冲突

在 app.log 中频繁出现如下错误：

ERROR: app_preloader.lua(212): ... kepler.class.SetSyncPropertyError: The property Health of the object NPU_1_01010502 is a synchronous property and cannot be set

说明：

  • Health 属性被标记为 同步属性（synchronous property），即必须通过特定流程（如调用服务接口）更新，不能直接写入。
  • Compute组件试图直接修改该属性值，违反了对象模型约束，引发异常。
  • 虽不直接导致温度读取失败，但表明 对象生命周期管理存在缺陷，可能影响整体状态同步。

4. CSR配置中缺少关键恢复或重试策略

  • 尽管用户已尝试增加“写延迟”以缓解初始化问题，但仅靠硬件延迟无法解决软件层对未就绪设备的过度激进轮询。
  • 缺少以下策略配置：
    • 读取失败后的退避重试机制（Debounce / Retry with backoff）
    • 状态依赖判断（仅当NPU驱动上报Ready后再发起完整采集）
    • Fallback机制（当带内不可用时，强制依赖带外MCU信息）

:white_check_mark: 已验证解决方案与建议

:white_check_mark: 解决方案一：升级并确认适配 OpenUBMC 25.09 闭源组件

  • 根据【文档1】回复：

    “当时我用的openUBMC 25.06基线，升级到25.09基线就可以了，25.09基线的闭源组件compute有适配”

  • 结论：
    • 仅导入CSR文件不足以支持A2卡监控。
    • 必须确保 compute组件已更新至支持Atlas 300I A2的新版本，否则其内部 npu_service.lua、NPUCard.lua 无法正确定义NPU对象的采集路径。

:backhand_index_pointing_right: 建议：确认当前环境中 compute 组件是否为官方适配版本（如 25.09.1+），可联系华为技术支持获取配套固件包。

:white_check_mark: 解决方案二：调整采集策略 —— 优先使用 NPUCard 带外信息

  • 建议修改配置，使温度、序列号、固件版本等关键信息从 带外MCU接口的NPUCard对象 获取，而非依赖需OS驱动支持的NPU对象。
  • 依据【搜索结果1】NPU卡适配指南 明确定义了如下属性应从 带外管理协议 获取：
属性 来源
PowerWatts :white_check_mark: 带外协议
Core0TemperatureCelsius :white_check_mark: 带外协议
Core1TemperatureCelsius :white_check_mark: 带外协议
SerialNumber :white_check_mark: 带外协议
FirmwareVersion :white_check_mark: 带外协议

:backhand_index_pointing_right: 建议操作：

  • 检查CSR文件中 NPUCard_1 是否配置了 RefChip 指向正确的MCU对象（如 Chip_Dmini_xxxx）。
  • 验证 StorageType 是否设为 MCU，确保信息来源非依赖OS驱动。

:white_check_mark: 解决方案三：添加初始化等待逻辑与退避机制

在 compute 组件的 NPUCard.lua 或 npu_service.lua 中增加如下策略：

-- 示例伪代码：延迟采集或检测驱动状态
if not is_npu_driver_ready(npu_id) then
    log.warn("NPU driver not ready, skip temperature fetch for ", npu_id)
    retry_after(5000) -- 5秒后重试
else
    read_temperature_via_out_of_band()
end

:backhand_index_pointing_right: 或采用 MedianDebounce_Temperature 一类的防抖策略（见KG中 Temperature 实体描述），避免短暂0值污染监控系统。

:white_check_mark: 解决方案四：修复 Health 属性设置错误

  • 禁止直接设置 NPU_xxx.Health 属性。
  • 应通过调用标准接口（如 UpdateHealthState()）来更新健康状态。
  • 修改相关脚本（如 app_preloader.lua）中的 SetProperty 调用，改为事件通知方式。

:white_check_mark: 解决方案五：确认CoolingRequirement配置完整性

参考【文档5】历史调速失败问题：

“社区代码提供的csr文件没有配置CoolingArea，添加后可以正常调速”

说明：

  • 即使功能看似仅涉及“信息读取”，CoolingRequirement、CoolingArea、Sensor Mapping 等配置若缺失，可能导致整个调温链路初始化异常。
  • 检查以下项是否存在且正确关联：
    • CoolingRequirement_xxx.SensorName → NPUx AICORE Temp
    • CoolingRequirement_xxx.MonitoringValue → 正确绑定至传感器
    • TemperatureType = 9（对应 NPUAiCore，见 KG 中 TemperatureType 定义）

:hammer_and_wrench: 推荐排查步骤清单

步骤 操作 目的
1 确认 compute 组件版本为 OpenUBMC 25.09 官方适配版 :check_mark: 支持A2卡通信协议
2 检查CSR文件中 NPUCard_1 是否存在且配置 Model="Atlas_300I_A2"、RefChip 正确 :check_mark: 绑定带外数据源
3 查看 /bmc/kepler/.../NPUCard_1 是否返回 Core0TemperatureCelsius、SerialNumber 等字段 :check_mark: 验证带外数据可达
4 检查 NPU_1 对象的 Temperature 值是否为 0 或缺失 :cross_mark: 判断是否因驱动未加载
5 在AC重启后观察：npu_service.lua 是否在驱动加载前过早采集 :warning: 定位时序问题
6 添加日志输出：is_npu_driver_loaded() 的检测结果 :compass: 追踪依赖关系
7 修改配置：将传感器数据源从 NPU_xxx.Temp 改为 NPUCard_xxx.Core0TemperatureCelsius :white_check_mark: 绕过驱动依赖

:books: 附加说明

温度异常值含义对照表（来源：【7】）

数值 含义 说明
0 驱动未加载或未返回 A2卡特有，不触发告警，易造成误判
32767 设备返回温度失败 NPU芯片侧未读到温度
32768 BMC 通信失败 与MCU/SMBus交互失败

:red_exclamation_mark: Atlas 300I A2 卡使用 0 作为未就绪标志，与其他NPU卡不同，需在策略层面特殊处理。

:white_check_mark: 总结

问题原因 是否可解决 措施
compute组件未适配A2卡 :white_check_mark: 升级至官方25.09闭源版本
信息源依赖NPU对象（需驱动） :white_check_mark: 改用NPUCard对象（带外MCU）
AC重启后采集过早 :white_check_mark: 添加延迟、健康检查、退避机制
Health属性非法写入 :white_check_mark: 修复脚本，禁用直接SetProperty
CSR缺CoolingArea等结构 :white_check_mark: 完善CoolingRequirement配置

:telephone_receiver: 后续建议

  1. 联系华为技术支持 提供 compute 组件适配包。
  2. 参照《NPU卡适配指南》 完整配置 NPUCard 对象属性。
  3. 在测试流程中加入驱动状态探测环节，避免“看得到设备却读不到数据”的伪故障。
  4. 推动将Atlas 300I A2纳入Devmon统一管理框架（见KG中 NPU 描述），实现更健壮的生命周期控制。

:memo: 最终目标：实现无论AC重启与否，所有NPU信息均能从带外可靠获取，摆脱对OS驱动的强依赖。

相关链接：

  1. NPU温度、功率等信息获取失败
  2. Atlas 300I A2卡的功耗读取不准
  3. Atlas 300I Duo NPU卡温度、功率读取失败
  4. 930版本Atlas 300I A2卡调速失败
  5. NPU卡适配指南 | 文档中心 | openUBMC
3

获取到温度，序列号，固件版本等信息，应该是需要os下a2驱动完全加载起来。如果是跑ac测试，一直不断上下电的话，是会出现你说的这种情况。

4

AC后是持续获取不到相关信息吗？还是反复AC过程中会出现相关情况？有没有尝试静置环境一段时间之后观察信息是否正常获取。

5

测试在检测到传感器异常后停止了，从昨晚近11点到今日10点开始定位，一直没有恢复

6

是持续性的，app.log中一直重复打印相同错误日志，在上文中有提到。

故障恢复是AC，刷写BMC包（只尝试过这两种方式恢复）后故障消失

7

麻烦下次复现时，进行如下操作
1、打开compute、libmgmt_protocol 组件的debug日志打印
静置环境5分钟后一键收集日志
2、进入带内，查看对应信息带内是否正常展示
查询温度命令为

npu-smi info -t temp -i $npu_id

获取序列号和固件版本命令为

npu-smi info -t board -i $npu_id
【compute组件】【NPU】A2 64G在os重启长稳测试中概率获取不到温度
8

AtomGit | GitCode - 全球开发者的开源社区,开源代码托管平台 可以按照这个方式解决验证下

9

你这修改不能解决这个问题吧，他的问题根因是compute组件获取npu卡温度信息失败了，你这个修改只是对特殊值进行了一下处理，但是获取不到还是获取不到呀