背景概述 Atlas 900 A3 SuperPod出现 Host 侧通过 npu-smi 命令查询 NPU 状态时，特定卡（如 npu6）无回显，且伴随 Device OS 侧日志刷屏 pipe write fail 的现象。该问题导致 Host 侧无法获取温度、使用率及健康状态等关键指标。问题现象 ●硬件层：带外 BMC 日志无硬件告警，sensor_info 显示正常；fdm_output 和 fdm_log 无异常；HDK 25.2.1 版本无多比特 ECC 错误；net_card_info 显示连接正常，port_history_log 无闪断记录。 ●系统层：OS 近期未发生重启；history.log、kernel.log 中未发现对应时间段的 Panic、Hardware Error、Call Trace 或 OOM 记录。问题分析 1、虽然 npu-smi 查询超时，但命令本身能够执行且 Host 与 Device 之间仍能进行基础的心跳或日志交互，这表明 HDC 通道并未完全挂死。超时现象更多是由于数据读写阻塞或资源竞争导致的。 2、通过深入分析 Device OS 侧的 debug/device-os/device-os_xxxxxxxx.log，发现关键错误日志：[dm_*hdc.c:99][dmp] [__hdc_write_to_pipe 99] __hdc_write_to_pipe: write fail.errno=11 该错误码 errno=11 通常对应 EAGAIN（Resource temporarily unavailable），暗示写入操作因资源暂时不可用而失败。 3、结合 HDC 通信机制（Host 写 -> Pipe -> Device 读），分析如下： ●Pipe 资源池机制：Host 与 Device 之间的通信依赖于有限数量的 Pipe 资源。 ●资源占用与释放：正常情况下，Host 写入数据后，Device OS 需及时从 Pipe 侧读取并处理，随后释放 Pipe 资源供后续使用。 ●异常场景：由于 Device OS 调度异常，导致其无法从 Pipe 侧正常读取信息。这使得 Pipe 侧资源无法被及时释放，长期被某个 Device OS 实例持续占用。 ●连锁反应：当 Pipe 资源池耗尽后，Host 侧尝试写入新数据时，因无可用 Pipe 资源而失败（即write fail）。由于 Host 侧写入阻塞，npu-smi等依赖 HDC 通道的管理命令无法获取响应，从而表现为“查不到卡”或“查询超时”。通信模型示意：Host OS ---[写]---> Pipe <---[读]--- Device OS ^ | (Device OS 未读取，资源未释放) 问题根因 device os调度问题，device-os无法从pipe侧读取信息；一直不释放pipe侧资源，导致host侧无法写入数据解决措施短期方案：带内reboot重启恢复长期方案：HDK 25.5.0及以后版本解决