// 此模板仅供参考，如果不适用可以修改
问题描述
环境插上了8张A300I A2 64G卡，反复重启os测试，发现概率出现某张NPU卡信息获取失败
环境信息
openUBMC 25.12 LTS-sp1
重现步骤
反复重启OS
期望结果
信息可以正常获取
实际结果
信息概率获取失败
尝试过的解决方案
[列出您已经尝试过的解决方案及结果]
带上该修改仍然存在问题
答案内容由AI生成，仅供参考：
结论
本问题是由A2卡使用NPU Object作为信息源的设计缺陷，叠加频繁OS重启导致驱动未及时加载，最终引起BMC侧compute组件无法获取有效数据所致。
建议采取以下综合措施：
- 短期：开启debug日志，定位具体失败卡位；
- 中期：统一使用
NPUCard Object为数据源，并将所有异常值纳入告警逻辑； - 长期：升级
compute组件并推动社区版本修复。
更多参考信息可查阅：
点击此处查看详细分析解答
NPU卡温度及功率信息获取失败问题分析与解决
问题概述
在搭载8张Atlas 300I A2 64G NPU卡的环境中进行OS重启长稳测试时，概率性出现某张NPU卡（如NPU5）的温度和功率信息获取失败的情况，表现为相关传感器读数显示“no reading”，状态为“ns”（Not Specified）。与此同时，其他NPU卡的信息读取正常。
该问题属于间歇性、概率性故障，影响系统监控可靠性与稳定性评估。
核心问题定位
根据提供的上下文信息，结合知识图谱与文档数据，此问题的根本原因在于：
compute组件依赖MCTP/SMBus协议与NPU卡通信，在OS频繁重启过程中，因驱动加载时机不同步或通信链路瞬态异常，导致BMC侧的compute组件无法及时获取到NPU卡的有效数据，从而引发信息读取失败。
关键技术点分析
| 项目 | 说明 |
|---|---|
| 故障组件 | compute Component（闭源模块） |
| 通信协议 | MCTP/SMBus（通过std_smbus.lua实现） |
| 数据来源 | NPU卡上的MCU通过SMBus提供温度与功耗数据 |
| 关键日志特征 | 日志中出现 failed to retrieve response protocol: std_smbus 错误 |
| 异常值表现 | 温度为 0 或 32768，功率为 0，状态为 ns 或 OK 不一致 |
根本原因分析
1. NPU信息获取机制差异（A2 vs Duo/Pro）
不同型号NPU卡在信息获取路径上存在设计差异：
// Atlas 300I A2 使用 NPU Object 获取数据
NPU对象逻辑：
- 未装驱动 / OS未启动时 → 温度读值为 **0**
- 驱动加载但通信失败 → 温度读值为 **32768**
// Atlas 300I Duo/Pro 使用 NPUCard Object 获取数据
NPUCard对象逻辑：
- 未装驱动 / OS未启动时 → 温度读值为 **32768**
- 驱动加载失败时 → 明确触发异常调速策略
问题点：A2卡使用
NPU Object作为数据源，在驱动未完全加载或OS重启瞬间返回0，不会触发异常调速或告警，造成“假正常”状态，掩盖了真实的数据获取失败。
2. OS频繁重启导致驱动初始化不同步
- A2卡依赖OS中
a2驱动完全加载后，才能通过BMA与MCU交互。 - 在反复AC或OS重启测试中，BMC的
compute组件比OS先启动，尝试从NPU卡读取温度/功率。 - 此时若OS尚未加载驱动，则NPU卡MCU未响应，SMBus通信失败，返回无效值（
0或32768）。 - 日志中可观察到类似错误：
compute DEBUG: std_smbus.lua(315): failed to retrieve response protocol: std_smbus, msg: Request(2) invalid response from the chip: FF FF FF ...
3. compute组件重试机制不足或超时设置不合理
compute组件在SMBus请求失败后会进行有限次重试，若仍失败则标记为“无读数”。- 在长稳测试中，多次OS重启会累积通信失败概率，导致部分卡持续处于“读取失败”状态。
- 故障恢复需依赖AC掉电重启整机或刷写BMC镜像，说明底层状态未被正确清理。
支持证据引用
❖ 知识图谱实体关联
compute Component：负责通过MCTP/SMBus与A2卡通信并收集温度和功耗信息。NPU Object：A2卡的数据源对象，当OS未加载驱动时返回0，无法触发异常调速。32768：表示BMC未能从卡侧获取温度数据，通常由驱动未安装或通信失败引起。ipmitool sensor：可用于验证传感器读数是否异常（如输出负数或32768）。
❖ 文档内容佐证
来自论坛讨论（topic_id: 4173）：
“当OS下300I A2驱动不对时，BMC无法获取NPU温度，此时应该触发异常调速来避免卡过温，但是实际并没有…300I A2卡温度读值是0，无法触发异常调速。”
“32768为bmc从卡侧获取温度失败，32767为bmc从卡侧获取到了温度，但是卡侧没有读取到温度，则为32767”
来自日志分析（topic_id: 4288）：
“app.log中重复打印错误日志：
pcall failed(...The property Health of the object NPU_1_01010502 is a synchronous property and cannot be set)”
表明NPU对象在更新属性时存在同步冲突，进一步影响状态更新可靠性。
解决方案建议
短期规避措施
| 措施 | 操作说明 |
|---|---|
| 启用debug日志 | 开启compute和libmgmt_protocol组件的DEBUG日志，便于复现时定位 |
| 静置环境观察 | 在故障发生后静置5分钟以上，观察信息是否自动恢复 |
| 带内验证数据 | 登录OS执行以下命令验证NPU状态：npu-smi info -t temp -i $npu_idnpu-smi info -t board -i $npu_id |
中期修复方向
| 方向 | 建议 |
|---|---|
| 统一数据源策略 | 将A2卡的温度监控从NPU Object迁移至NPUCard Object，统一与Duo/Pro卡一致，确保异常值（32768）可触发调速策略 |
| 优化异常值处理逻辑 | 修改调速策略，对0、32767、32768等所有非正常范围值均视为异常，强制进入异常调速模式（如风扇全速） |
| 增加防抖与降级机制 | 在CSR配置中引入防抖机制（如contbin_HxLx），防止因短暂通信失败导致持续告警 |
| 更新compute组件版本 | 升级至支持A2卡稳定通信的compute Component版本，修复SMBus交互稳定性问题 |
长期架构改进
- 推动社区PR合入：参考GitCode PR #611 中关于NPU卡适配的修复方案。
- 标准化异常判断逻辑：所有NPU卡应将如下值视为异常：
- 温度：
0,255,32767,32768 - 功耗：
0,16384
- 温度：
- 完善监控指标等级：依据《NPU卡适配指南》，实现L1~L3级监控能力，包括故障码、健康状态、芯片级告警等。
补充说明：异常数值含义汇总
| 数值 | 含义 | 是否应触发告警 |
|---|---|---|
0 |
OS未加载驱动或未启动，NPU Object返回默认值 | 应触发 |
255 |
无效或未初始化读值（如Core0TemperatureCelsius为255） | 应触发 |
16384 |
功耗获取失败 | 应触发 |
32767 |
BMC从卡侧获取到温度，但卡侧未读到有效值 | 应触发 |
32768 |
BMC无法从卡侧获取任何温度数据（SMBus通信失败） | 强制触发 |
结论
本问题是由A2卡使用NPU Object作为信息源的设计缺陷，叠加频繁OS重启导致驱动未及时加载，最终引起BMC侧compute组件无法获取有效数据所致。
建议采取以下综合措施：
- 短期：开启debug日志，定位具体失败卡位；
- 中期：统一使用
NPUCard Object为数据源，并将所有异常值纳入告警逻辑； - 长期：升级
compute组件并推动社区版本修复。
20260323-0931.z01.txt (9 MB)
20260323-0931.zip (3.7 MB)
分卷压缩的日志文件，把第一个文件的后缀txt去掉，解压zip文件即可
这个查询的结果是？
这一部分处理逻辑在闭源组件已经进行优化了，目前还未发布
这个优化能解决这种问题不？若要发布是在哪个版本发布？是2512发一个补丁版本，还是说在主干迭代发布，26年的630版本？
主干、lts版本均有进行相应优化
你这边也没办法确定，这个修改一定能解决这个问题吧？那就只有等合入这个问题之后再跑复现了 
目前为止测试是没有再次复现的，如果对这部分修改有疑虑，可以自行长稳测试，查看是否还有问题，具体的版本发布节奏可以找对应人员询问
请问什么时候发布，我这边也遇到了A2卡概率性获取不到温度的问题。