---
title: 执行 npu-smi 命令返回 -8005 错误码的排查与解决-官方技术文章-昇腾社区
description: 在昇腾AI硬件平台的日常维护与调试过程中，用户通过带内接口调用 npu-smi info 等命令查询NPU状态时，偶发出现返回错误码 -8005 的现象。该错误码表示“DCMI模块初始化失败”，通常与驱动加载异常、内核环境不匹配或模块签名验证失败相关。本文基于实际问题场景，系统梳理了从日志分析到根因定位的完整排查路径，并提供可落地的解决方案，适用于中心训练、中心推理及智能边缘等典型部署环境。
keywords: 执行,命令返回,错误码的排查与解决,官方技术文章,昇腾社区,背景概述,问题现象,原因分析
url: https://www.hiascend.com/developer/techArticles/20260603-7?envFlag=1
section: (其他)
---

# 执行 npu-smi 命令返回 -8005 错误码的排查与解决-官方技术文章-昇腾社区

URL: https://www.hiascend.com/developer/techArticles/20260603-7?envFlag=1
描述: 在昇腾AI硬件平台的日常维护与调试过程中，用户通过带内接口调用 npu-smi info 等命令查询NPU状态时，偶发出现返回错误码 -8005 的现象。该错误码表示“DCMI模块初始化失败”，通常与驱动加载异常、内核环境不匹配或模块签名验证失败相关。本文基于实际问题场景，系统梳理了从日志分析到根因定位的完整排查路径，并提供可落地的解决方案，适用于中心训练、中心推理及智能边缘等典型部署环境。
关键词: 执行,命令返回,错误码的排查与解决,官方技术文章,昇腾社区,背景概述,问题现象,原因分析

官方技术文章 [了解详情](https://www.hiascend.com/zh/developer/techArticles)

执行 npu-smi 命令返回 -8005 错误码的排查与解决

执行 npu-smi 命令返回 -8005 错误码的排查与解决

人工智能应用使能套件

发表于: 2026/06/05

## 背景概述

在昇腾AI硬件平台的日常维护与调试过程中，用户通过接口调用`npu-smi info`等命令查询NPU状态时，偶发出现返回错误码`-8005`的现象。该错误码表示“DCMI模块初始化失败”，通常与驱动加载异常、内核环境不匹配或模块签名验证失败相关。本文基于实际问题场景，系统梳理了从日志分析到根因定位的完整排查路径，并提供可落地的解决方案，适用于中心训练、中心推理及智能边缘等典型部署环境。

## 问题现象

在执行带内命令（如`npu-smi info`、`dcmi`接口调用）时，返回错误码`-8005`，提示`dcmi module initialize failed`，导致无法获取NPU设备的运行状态信息。

## 原因分析

### 1. BMC 日志分析

在问题发生时间点，BMC系统无硬件告警记录，未发现物理层异常或设备离线情况。

FDM日志中亦无异常报错，排除了硬件故障或固件异常的可能性。

### 2. 带内日志与系统状态分析

2.1NPU PCIe链路状态正常

通过`lspci`或相关工具检查NPU PCIe建链状态，确认设备已正确识别，未出现掉卡或链路中断现象。

2.2驱动安装过程无异常

检查`/var/log/ascend_seclog/ascend_install.log`，确认驱动安装过程中未报错，安装时使用的内核版本为`5.15.152.bsk.7-arm64`，且DKMS功能已启用。

2.3系统内核版本变更记录

进一步分析`message`日志，发现系统在运行期间发生了内核升级：

- 19:58：系统启动，使用内核`5.15.152.bsk.7-arm64`

- 20:07：内核升级至`5.15.152.bsk.12-sign-arm64`

- 20:20：系统重启，以新内核`5.15.152.bsk.12-sign-arm64`启动

2.4签名验证机制触发异常

在新内核启动后，`message`日志中出现如下关键信息：

```hljs
Loading of unsigned module is rejected
```

表明当前内核启用了模块签名验证机制（`module.sig_enforce=1`），而HDK所依赖的`.ko`驱动模块未经过签名，导致加载失败，驱动未初始化，进而引发`dcmi module initialize failed`，最终返回`-8005`错误码。

## 问题根因

系统在运行过程中升级了内核至带签名验证功能的版本（`5.15.152.bsk.12-sign-arm64`），而该版本启用了模块签名强制校验机制。由于HDK安装包中提供的`.ko`驱动模块未携带有效签名，无法通过校验，导致驱动加载失败，进而使`npu-smi`等接口调用因模块初始化失败而返回`-8005`错误码。

## 解决措施

针对该问题，提供以下两种可行方案，用户可根据实际环境选择适用方式：

### 方案一：内核模块签名验证（推荐用于非安全敏感场景）

若系统无需严格的安全启动策略，建议使用无签名验证的内核版本（如`5.15.152.bsk.7-arm64`），或临时签名验证机制。

#### Ubuntu 系统操作步骤

1.检查安全启动状态：

```
mokutil --sb-state 
```

若输出为`Secure boot enabled`，说明当前启用了签名验证。

2.禁用安全启动：

通过 BIOS 设置界面，进入`Security`→`Secure Boot`，将其设置为`Disabled`。

或通过命令行（需支持）执行：

```
mokutil --disable-validation （需配合 MOK 管理流程完成）
```

#### EulerOS 系统操作步骤

1.检查内核启动参数：

```
cat /proc/cmdline 
```

若输出中包含 module.sig_enforce=1，说明启用了模块签名验证。

2.临时禁用（重启后失效）

启动时进入 GRUB 菜单，按`e`编辑启动项，删除包含`module.sig_enforce=1`的参数，保存退出。

3.永久禁用编辑 GRUB 配置文件：

```
sudo vim /etc/default/grub 
```

修改：

```
GRUB_CMDLINE_LINUX="module.sig_enforce=1" 改为：GRUB_CMDLINE_LINUX="" 
```

保存后执行：

```
sudo grub2-mkconfig -o /boot/grub2/grub.cfg # 或使用 update-grub（Ubuntu） 
```

重启系统后验证：

```
cat /proc/cmdline | grep module.sig_enforce 
```

若无输出，表示已成功禁用。

### 方案二：为驱动模块添加签名（适用于需保留安全启动的生产环境）

若必须使用带签名验证的内核，需对HDK依赖的`.ko`模块进行签名处理。

1.准备签名工具与密钥（需使用与系统一致的签名证书）。

2.使用`sign-file`工具对`.ko`文件进行签名：

```
./sign-file sha256 ./MOK.priv ./MOK.der /lib/modules/5.15.152.bsk.12-sign-arm64/updates/driver_name.ko
```

3.将签名后的`.ko`文件复制至对应目录：

```
sudo cp driver_name.ko /lib/modules/5.15.152.bsk.12-sign-arm64/updates/
```

4.重新加载驱动模块：

```
sudo modprobe driver_name
```

验证是否可正常调用`npu-smi info`命令。

⚠️ 注意：该方案需具备内核模块签名能力及密钥管理权限，建议由具备安全资质的团队执行。

## 总结

本案例中，`-8005`错误码的根本原因并非驱动本身缺陷，而是由于系统内核升级后引入了模块签名验证机制，导致未签名的驱动无法加载。通过分析日志、核对内核版本变更记录，可快速定位问题本质。

建议在部署与维护过程中：

- 保持内核版本与驱动安装环境一致；
- 在启用安全启动的场景下，确保驱动模块具备有效签名；
- 避免在生产环境中随意升级内核，或提前完成驱动兼容性验证。

本页内容