E4 报错码速查：拿到一个码该干什么
课件编号：E4（排障层） 编制：观澜｜日期：2026-10-06 难度：入门偏中 时长：约 45 分钟 是否需要硬件：❌ 不需要 前置：第 E1 课（报错定位法） 本课目标：拿到任何一个昇腾错误码，先判断它属于哪一套码体系，再决定"自己能改"还是"只能收日志"
第一段 · 章前定位
E1 教的是方法：一条报错进来，怎么拆成 5 块、怎么判断它落在哪一层。
本课接着往下走一步。你手上已经拿到一个具体的码——507033、100001、207001、0x0091、EE1023……接下来该干什么？
这一步最容易犯的错，是拿一张表去套所有的码。昇腾的码表不止一张：AscendCL 一套、Runtime 一套、GE 图引擎一套、算子库 aclnn 又一套，安装器还是另一套。套错了表，就会把"应该反馈给技术支持的问题"当成"自己改改就行"，反过来也一样。
本课不教：不改你的代码、不做性能调优、不教日志怎么导出（那是 E2 的事）、不教案例库怎么用（那是 E3 的事）。本课只回答一个问题：这个码，下一步该干什么。
一句话：E1 把报错翻译成"哪一层"；E4 把那个码翻译成"下一步动作"。
第二段 · 学习目标
学完这一课，你应该能：
- ✅ 说出昇腾至少有 5 套并存的码体系，并认出每一套长什么样
- ✅ 拿到一个码，先判断它属于哪套，再去查对应的那张表
- ✅ 看懂一行日志里的 3 个码（
ErrCode/InnerCode/ 打屏码）各是什么，哪个才是根因 - ✅ 分清哪些码自己能改（1/2/3 类）、哪些只能收日志反馈（5 类）
- ✅ 会按码反查官方文档与故障案例库；查不到时知道该记下什么，而不是编一个解释
第三段 · 全景：错误码不是一套体系，是好几套并存
先立一个总认识：昇腾的码表是一组，不是一张。 下面这张表是本课的骨架：
| 体系 | 码长什么样（示例） | 谁产生的 | 官方出处 |
|---|---|---|---|
AscendCL 通用返回码 ACL_ERROR_* |
100000 / 200000 / 300000 / 500000 |
AscendCL 对外接口 | CANN 9.2.0-beta.2《aclError — 数据类型及其操作接口》表1 |
Runtime 返回码 ACL_ERROR_RT_* |
107000 / 207000 / 507000 |
Runtime 运行时（rt_error_codes.h） |
同上（表1 后半段） |
GE 图引擎返回码 ACL_ERROR_GE_* |
145000 / 245000 / 345000 / 545000 |
Graph Engine 图引擎 | 同上 |
算子库 aclnn 返回码 ACLNN_* |
161001 / 361001 / 561xxx |
单算子 aclnn 接口 | CANN 9.2.0-beta.2《aclnn返回码》 |
| 打屏资源码 / 内部码 | EE1023 / retCode=0x7020023 / errType=0x1 |
Runtime→Driver 硬件调度、plog | CANN《EE1023 资源不足问题》 |
| 安装器 / 驱动码 | 0x0091（十六进制） |
驱动与 CANN 安装器 | 官方无成文总表（见本节末） |
⭐ 关键结论：同一个物理故障，落在不同层，报出来的码不一样。
拿来举例——"设备起不来"这一件事：
- 在 Runtime 层是
507033（ACL_ERROR_RT_DEV_SETUP_ERROR，Device 启动失败） - 在 AscendCL 顶层可能是
500004（Driver 模块的错误） - 在一行 plog 里还会带一个十六进制内部码，形如
InnerCode=0x7020023
所以"拿到一个码"的第一步，不是查它什么意思，而是先问：这是哪一层报的码？ 这一步用的正是 E1 的方法。
官方对 AscendCL 返回码的定义规则（原文，共 5 条）
| 规则 | 官方原文 | 码段 | 你能自己解决吗 |
|---|---|---|---|
| 规则 1 | 开发人员的环境异常或者代码逻辑错误，可以通过优化环境或代码逻辑的方式解决 | 1XXXXX |
✅ 能 |
| 规则 2 | 资源不足（Stream、内存等）、编程时使用的接口或参数与当前硬件不匹配，可以通过在编程时合理使用资源的方式解决 | 2XXXXX |
✅ 能 |
| 规则 3 | 业务功能异常，比如队列满、队列空等 | 3XXXXX |
✅ 能 |
| 规则 4 | 软硬件内部异常，包括软件内部错误、Device 执行失败等，用户无法解决问题，需要将问题反馈给技术支持 | 5XXXXX |
❌ 收日志反馈 |
| 规则 5 | 无法识别的错误，当前都映射为 500000 |
500000 |
❌ 同上 |
⚠️ 但这 5 条只对 AscendCL 那一套成立。 安装器的
0x0091是十六进制、走它自己的体系；EE1023是打屏码；aclnn 的561xxx是另一套编号。 先判断码的场合，再套规则 —— 这条如果记不住，本课就白学了。
第四段 · 五套码各管什么 —— 以及【如果我来做】
每一套码负责什么 / 不认它会怎样
| 体系 | 它管什么 | 不认它会怎样 |
|---|---|---|
| AscendCL 通用 | 对外接口的"参数 / 环境 / 资源 / 内部"四大类 | 把 1XXXXX（自己环境问题）当成内部异常去反馈，白等一轮 |
| Runtime | 设备、Stream、Event、内存、任务执行 | 看到 507033 去改 Python 代码，方向全错 |
| GE 图引擎 | 图编译、模型加载与执行、张量 | 把 545001（内部加载模型失败）当模型文件问题去反复重转模型 |
| aclnn 算子库 | 单算子调用的参数与内部异常 | 把 561107（未检测到 ASCEND_OPP_PATH）当成算子本身的缺陷 |
| 打屏 / 内部码 | 硬件调度资源、Device 侧异常 | 只盯屏幕上的 EE1023，不去 plog 找那个真正指向根因的内部数字 |
| 安装器 / 驱动 | 装包、编内核模块、依赖缺失 | 拿 AscendCL 的 1/2/3/5 规则去套 0x0091，越套越糊涂 |
【如果我来做】—— 拿到一个码，我按这个顺序走
不按"码表顺序"排，按"手伸进去的顺序"排：
① 先看这一行的完整报错，不要只抠出那个数字。
一行里常常同时有三个码，例如官方日志原文里的这一行：
rtModelExecute:ErrCode=207005, desc=[driver error:resource alloc fail], InnerCode=0x7020023外层ErrCode告诉你"哪一类"，内层InnerCode才指向根因。 只抄207005去查，会查到"资源申请失败"这种笼统结论；带上0x7020023才能查到是 Stream 资源不足。
② 判断这个码属于哪一套体系（对照第三段的表）。
判据：
1/2/3/5开头、6 位十进制 → AscendCL 通用；107xxx / 207xxx / 507xxx→ Runtime；145xxx / 245xxx / 345xxx / 545xxx→ GE 图引擎；161xxx / 361xxx / 561xxx→ 算子库 aclnn；0x开头 → 安装器 / 驱动 / 内部码；EE开头 → 打屏码。
③ 套对应那张表，读出"含义"和"官方给的原因与解决方向"。
官方表里每个码后面都写了"可能原因及解决方法"。照它写的方向查，不要自己发明方向。
④ 判断能不能自己修。
✅
1/2/3类（环境、代码、资源、业务）→ 自己能改：回环境变量、调用顺序、资源申请； ❌5类（内部异常、Device 执行失败）→ 官方原话就是"用户无法解决问题，需要将问题反馈给技术支持"，别死磕。
⑤ 动手改之前，先把证据留下来。
记下三样：码 + 那条完整日志原文 + 出问题的时间点。（"怎么把日志导出来"是 E2 的事，但"先留证据"是本课就该养成的习惯。）
⑥ 查不到、对不上时，不要编解释。
如实记一句："码 X 在官方表里查不到，现象是 Y，环境是 Z"。这句话本身就是有效线索，比一个自己脑补的原因强得多。
第五段 · 怎么查：可照抄的命令
⚠️ 下面每条命令都按"含义 / 拆解 / 用法 / 期望 / 不过会怎样"写全，直接照着敲。
命令 echo $ASCEND_HOME_PATH
含义：打印 CANN 环境变量
ASCEND_HOME_PATH的当前值，确认 CANN 环境是否已在当前这个终端里生效。 拆解：echo把内容打印到屏幕；$= 取这个变量的值。这个变量由 CANN 的set_env.sh设置。 用法：切过终端、或用sudo另开窗口后，先敲这一条再查码；echo $ASCEND_HOME_PATH一行即可。 期望：输出一个路径（非空）。 不过会怎样：输出为空 → 环境没加载。此时报的100001（未初始化）、"找不到库"这类码，根因不在码本身，在环境没 source。
命令 grep -rn "ErrCode" $HOME/ascend/log/ | tail
含义：在 Host 应用类日志（官方默认根目录
${HOME}/ascend/log）下，把所有带ErrCode的行挑出来，只看最后几条。 拆解：grep筛关键词；-r递归子目录、-n显示行号；$HOME/ascend/log是官方默认的应用类日志路径；tail只看末尾；|是管道，把左边结果交给右边处理。 用法：想只看某一个码，把关键词换掉，例如grep -rn "507033" $HOME/ascend/log/。plog 的具体文件，官方写法是$HOME/ascend/log/[run|debug]/plog/plog-pid_*.log（即run/或debug/子目录下）。 期望：打印出形如... [api_c.cc:1713] rtModelExecute:ErrCode=207005, desc=[driver error:resource alloc fail], InnerCode=0x7020023的行 —— 外层 ErrCode 定类，InnerCode 指根因。 不过会怎样：什么都搜不到 → 日志没生成或日志级别不够；复现前先执行下面第 8 条把级别调成 DEBUG。
命令 npu-smi info -t memory
含义：查每张卡的显存（HBM）总量 / 已用 / 剩余 —— 排查
207001（内存申请失败）、207018（Device 侧内存耗尽）这类2XXXXX码时，先用它确认"卡上是不是真的没内存了"。 拆解：npu-smi是昇腾设备管理工具；info是子命令（查信息）；-t memory指定查"内存"这一项。 用法：npu-smi info -t memory（官方 FAQ 给出的写法）。要带卡号查询时的完整参数，以官方《npu-smi 用户指南》为准。 期望：输出里能看到HBM Total/HBM Used/HBM Free（官方 FAQ 给的输出形态）。 不过会怎样：命令不存在 → 驱动没装（回 A1 课件）；HBM Free很小 → 码的原因就是内存真被占满，先释放再复现。
命令 cat /usr/local/Ascend/version.info
含义：看 CANN 安装版本，用来判断
207000（功能不支持）、100012（反序列化模型失败）这类"版本对不上"的码。 拆解：cat打印文件内容（本意 concatenate，现今主要用来"看文件"）；/usr/local/Ascend/version.info是官方 FAQ 给出的版本文件路径。 用法：cat /usr/local/Ascend/version.info；同一份 FAQ 还给了ldd命令看程序实际加载的库（见下一条）。 期望：打印出版本号，能和你的报错文档/模型要求对上。 不过会怎样：报No such file or directory→ 路径随安装方式而不同（非 root 安装在${HOME}/Ascend下），或 CANN 没装。别拿"这个文件不存在"当"没装"的唯一判据，改用echo $ASCEND_HOME_PATH。
命令 ldd ./your_program | grep ascendcl
含义：看程序运行时实际加载的 AscendCL 库是哪一个 —— 排查"编译用一个版本、运行用另一个版本"导致的
207000、undefined reference等。 拆解：ldd列出可执行文件依赖的动态库；|管道把结果交给grep，筛出含ascendcl的行。 用法：把./your_program换成你自己的可执行文件（官方 FAQ 的原样写法是ldd your_program | grep ascendcl）。 期望：打印出libascendcl.so的具体路径，且应指向你期望的那个 CANN 版本目录。 不过会怎样：路径指向旧版本目录，或显示not found→ 就是版本不匹配的根因，回头查ASCEND_HOME_PATH/LD_LIBRARY_PATH。
命令 lsmod | grep ascend
含义：看内核里的昇腾驱动模块有没有加载 —— 排查
107001（无效 Device ID）时特别有用，官方 FAQ 明确写着"驱动未正确加载"也会返回这个码。 拆解：lsmod列出已加载的内核模块；grep ascend只看昇腾相关的行。 用法：lsmod | grep ascend（官方 FAQ 示例）。 期望：列出昇腾相关的内核模块行。 不过会怎样：什么都不输出 → 驱动没加载。此时107001的根因是驱动，不是你把 Device ID 填错了。
命令 cat /var/log/ascend_seclog/ascend_install.log
含义：看驱动 / CANN 安装过程的详细日志 —— 安装类报错（
Dkms install failed、Driver_ko_install failed、0x0091这类码）的正文答案基本都在这里。 拆解：cat打印文件；/var/log/ascend_seclog/ascend_install.log是官方安装文档与《附录C：安装故障处理》反复点名的安装日志路径。 用法：装驱动失败时，官方回显本身就提示 "details in : /var/log/ascend_seclog/ascend_install.log"，照着cat或grep它。 期望：能看到失败那一步的真实原因（例如缺lspci、ifconfig，或 dkms 编译失败）。 不过会怎样：文件不存在 → 这次失败根本没走到"写日志"阶段（例如安装包本身损坏），先用./xxx.run --check验包。
命令 export ASCEND_GLOBAL_LOG_LEVEL=0
含义：把日志级别调到 DEBUG，让 plog 输出最详细的信息 —— 当默认级别下"只有码、没有过程"时用它。 拆解：
export定义环境变量并传给之后启动的子进程；值0=DEBUG、1=INFO（默认）、2=WARNING、3=ERROR（官方《如何通过 plog 日志定位 Device 侧异常》给的级别说明）。 用法：先export ASCEND_GLOBAL_LOG_LEVEL=0，再来一条export ASCEND_SLOG_PRINT_TO_STDOUT=1让它同时打到屏幕；然后重跑程序复现。 期望：复现时屏幕/plog 出现更详细的行（如Task run failed、fault kernel_name）。 不过会怎样：日志量暴涨却没多出新线索 → 级别开太高会把有效信息淹没；定位到具体段落后记得调回去。
第六段 · 判据 / 验收
拿下面这张表自测。每一条都能"自己验"，不靠感觉。
| # | 你做到了 | 怎么自己验 |
|---|---|---|
| ① | 能背出至少 5 套码体系 | 合上课件，写下"体系名 + 一个示例码"，≥5 组算过 |
| ② | 拿到任意码能先归体系 | 随手给一个码（如 245001），能立刻说出"这是 GE 的" |
| ③ | 看懂一行三码 | 给你 ErrCode=207005 ... InnerCode=0x7020023，能指出根因是 0x7020023（Stream 资源） |
| ④ | 能判"自己修 / 反馈" | 给 100001 说"自己修"，给 507033 说"收日志反馈" |
| ⑤ | 会按码反查 | 能把码去具体化后，去官方《aclError》表和故障案例库各搜一次 |
验收证据：一条命令的输出 + 一条完整报错原文 + 时间点。三样齐了，才算"我查过这个码"。
第七段 · 出问题怎么查 —— 拿到码后的排查顺序
先看这一张表：按"你手里的码"去查，而不是按"层"去查。 现场的人是拿着码来找答案的。
| 你手里的码 | 属于哪套 | 先查什么（含命令） | 自己能修吗 |
|---|---|---|---|
100000 |
AscendCL | 接口入参是否为空/越界 | ✅ |
100001 |
AscendCL | echo $ASCEND_HOME_PATH + 代码里 aclInit 是否在其它接口之前 |
✅ |
100002 |
AscendCL | 是否重复 aclInit（官方说可忽略该错误继续业务） |
✅ |
100011 / 100012 / 100014 |
AscendCL | 模型文件是否存在、是否与当前版本匹配 → 官方方向是重新构建模型 | ✅ |
107000 |
Runtime | 接口入参 | ✅ |
107001 |
Runtime | 设备 ID 是否在 [0, deviceCount-1]；再 lsmod \| grep ascend 看驱动 |
✅（多为填错） |
200000 / 207001 / 207018 |
AscendCL / Runtime | npu-smi info -t memory 看 HBM Free；释放、复用、减小一次申请量 |
✅ |
207000 |
Runtime | cat /usr/local/Ascend/version.info + ldd ./prog \| grep ascendcl 版本是否一致 |
✅ |
300000 |
AscendCL | 存储是否写满 | ✅ |
500000 |
AscendCL | 无法识别的错误，官方即"联系技术支持" | ❌ 收日志 |
507000 / 507015 / 507033 |
Runtime | 别改代码，直接收日志：grep -rn "ErrCode" $HOME/ascend/log/ |
❌ 反馈 |
EE1023 |
打屏码 | 去 plog 找 retCode（见下方对照）→ 再看是不是资源没释放/并发过多 |
✅（多为资源） |
0x 开头（如 0x0091） |
安装器/驱动 | cat /var/log/ascend_seclog/ascend_install.log |
视情况 |
EE1023 的 plog retCode → 资源类型对照（官方《EE1023 资源不足问题》给的表）：
| plog 里的 retCode | 典型关键词 | 是哪种资源不足 |
|---|---|---|
0x7020023 |
Alloc Stream resource failed | Stream 资源 |
0x702001b |
Alloc Notify resource failed | Notify 资源 |
0x7020019 |
Alloc Event resource failed | Event 资源 |
0x7110019 |
async copy tasks reaches the maximum limit | 异步拷贝任务队列资源 |
⭐
EE1023这条最能说明本课的要点：屏幕只给你EE1023，根因数字在 plog 里。官方给的定位思路三步 —— ① 从 plog 的retCode确认资源类型；② 检查资源的创建与销毁是否配对（不用了就Destroy）；③ 用npu-smi info看是否被别的进程占用。 注意：EE1023在官方体系里不属于 1/2/3/5 分段，它是另一套"打屏码"。套错表就会去查 AscendCL 表，查不到。
第八段 · 常见报错清单（真实编号）
下表里的码与描述逐条来自官方文档；案例编号是昇腾官方故障案例库的真编号，可直接拼链接查看：
https://www.hiascend.com/document/caselibrary/detail/<案例编号>
| # | 报错 / 码 | 官方名称 | 官方给的原因与方向 | 自己修? |
|---|---|---|---|---|
| 1 | 100000 |
ACL_ERROR_INVALID_PARAM |
参数校验失败 → 检查接口入参值是否正确 | ✅ |
| 2 | 100001 |
ACL_ERROR_UNINITIALIZE |
未初始化 → 确认已调用 aclInit，且在其它 acl 接口之前 |
✅ |
| 3 | 100002 |
ACL_ERROR_REPEAT_INITIALIZE |
重复初始化/重复加载 → 检查是否重复调用（官方：可忽略继续） | ✅ |
| 4 | 100011 |
ACL_ERROR_INVALID_MODEL_ID |
无效的模型 ID → 检查模型是否正确加载 | ✅ |
| 5 | 100012 |
ACL_ERROR_DESERIALIZE_MODEL |
反序列化模型失败 → 模型可能与当前版本不匹配，重新构建模型 | ✅ |
| 6 | 100014 |
ACL_ERROR_READ_MODEL_FAILURE |
读取模型失败 → 检查模型文件是否存在/可访问 | ✅ |
| 7 | 107000 |
ACL_ERROR_RT_PARAM_INVALID |
参数校验失败 → 检查接口入参 | ✅ |
| 8 | 107001 |
ACL_ERROR_RT_INVALID_DEVICEID |
无效的 Device ID。两种原因：① ID 超出范围；② 驱动未加载也会报它 | ✅ / 驱动 |
| 9 | 207000 |
ACL_ERROR_RT_FEATURE_NOT_SUPPORT |
特性不支持 → 多为Runtime 与 CANN 版本不匹配 | ✅ |
| 10 | 207001 |
ACL_ERROR_RT_MEMORY_ALLOCATION |
内存申请失败 → 检查硬件环境内存剩余；策略建议 HUGE_FIRST |
✅ |
| 11 | 207018 |
ACL_ERROR_RT_DEVICE_OOM |
Device 侧内存耗尽 → 按 Device 内存规格合理规划 | ✅ |
| 12 | 500004 |
ACL_ERROR_DRV_FAILURE |
Driver 模块的错误 → 收日志反馈 | ❌ |
| 13 | 507000 |
ACL_ERROR_RT_INTERNAL_ERROR |
Runtime 模块内部错误 → 收日志反馈 | ❌ |
| 14 | 507015 |
ACL_ERROR_RT_AICORE_EXCEPTION |
AI Core 执行异常 → 收日志反馈（配 plog 看 fault kernel_name） |
❌ |
| 15 | 507033 |
ACL_ERROR_RT_DEV_SETUP_ERROR |
Device 启动失败 → 收日志反馈 | ❌ |
| 16 | 500000 |
ACL_ERROR_INTERNAL_ERROR |
未知内部错误 → 收日志反馈 | ❌ |
| 17 | 161001 |
ACLNN_ERR_PARAM_NULLPTR |
参数校验错误，参数中存在非法的 nullptr |
✅ |
| 18 | 561107 |
ACLNN_ERR_INNER_OPP_PATH_NOT_FOUND |
内部异常：没有检测到需要配置的环境变量 ASCEND_OPP_PATH |
✅ |
18 个码里，几条真实世界的"原样报错"
| 报错原文（去具体化后） | 特征词 | 官方案例编号 | 查看量 |
|---|---|---|---|
Acl open device 0 failed, errorCode is 507033 |
Acl open device |
topic_0000001633594041 |
10,585 |
EL0003，error code 507000 |
507000 |
case_95414 |
— |
[ERROR]ERR_NO:0x0091;ERR_DES:username not permission for root |
username not permission for root |
case_92819 |
— |
CentOS 7.6 内核升级后 npu-smi / 驱动安装失败 |
CentOS 7.6；npu-smi |
case_9286 |
1,983 |
虚拟机安全启动打开 → [ERROR]Driver_ko_install failed |
Driver_ko_install failed |
topic_0000002273354313 |
745 |
| 驱动安装中出现拷贝目录报错 | — | topic_0000002273193421 |
907 |
⭐ 看第 3 行那条
0x0091：它是十六进制、走安装器自己的体系，不属于 AscendCL 的 1/2/3/5 分段。这就是本课反复强调"先判断码的场合"的活例子。
第九段 · 小结与下一课
三句话带走
- 码表是一组，不是一张：AscendCL / Runtime / GE / aclnn / 打屏码 / 安装器，先认体系，再查表。
- 看整行，别只抠数字：
ErrCode定类，InnerCode（十六进制）指根因。 1/2/3开头自己改；5开头收日志 —— 官方原话：5 类是"用户无法解决，需反馈技术支持"。
钩子（E 层后续课）
| 课 | 要回答的问题 |
|---|---|
| E2 | 日志三处怎么分？msnpureport 怎么把 Device 侧日志导出来？ |
| E3 | 官方故障案例库到底怎么用？特征词怎么提？ |
| E5 | 不报错但结果不对（精度问题）怎么查？ |
课后自测（3 题）
- 你看到
ErrCode=207005, desc=[driver error:resource alloc fail], InnerCode=0x7020023。先说这三个数各是什么，再说根因是哪个。 - 同事发来
ACL_ERROR_UNINITIALIZE (100001)。它属于哪套体系？你能自己修吗？先查什么？ - 安装驱动时报
[ERROR]ERR_NO:0x0091。你打算拿 AscendCL 的 1/2/3/5 规则套它吗？为什么？该去哪里找答案？
附录 A · 本课引用的官方出处
| 内容 | 官方来源 |
|---|---|
| AscendCL 返回码 5 条定义规则（1/2/3/5XXXXX + 500000） | CANN 9.2.0-beta.2《aclError — 数据类型及其操作接口》 |
ACL_ERROR_* / ACL_ERROR_RT_* / ACL_ERROR_GE_* 全部具体码 |
同上（同一页表1） |
aclnn 返回码（161001 / 361001 / 561xxx）与 aclGetRecentErrMsg |
CANN 9.2.0-beta.2《aclnn返回码》 |
107001 两种原因、lsmod \| grep ascend、cat /usr/local/Ascend/version.info |
CANN《aclrtSetDevice调用失败》 |
aclInit 失败三种现象、107000 / 100002、json 层级 10 层 |
CANN《aclInit初始化失败常见原因排查》 |
207000 版本不匹配、ldd ... \| grep ascendcl |
CANN《Runtime版本与CANN版本不匹配导致的问题》 |
207001、npu-smi info -t memory、HUGE_FIRST 策略 |
CANN《aclrtMalloc内存申请失败常见原因》 |
异步错误延迟、aclrtSynchronizeStream、aclrtPeekAtLastError |
CANN《如何获取和解读Runtime异步错误码》 |
plog 路径、grep "fault kernel_name"、日志级别 0/1/2/3 |
CANN《如何通过plog日志定位Device侧异常》 |
EE1023 四类资源与 plog retCode 对照表 |
CANN《EE1023资源不足问题》 |
安装日志路径、Dkms install failed、缺 lspci/ifconfig |
CANN《附录C：安装故障处理》 |
--check 回显 Verifying archive integrity... |
昇腾《安装驱动》（NPU 驱动和固件安装指南） |
| 5 条真实报错案例编号与查看量 | 昇腾官方故障案例库 |
⚠️ 数据说明（官方未给出、或本课未写死的部分）：
- 安装器 / 驱动的十六进制码（如
0x0091）：官方没有成文的错误码总表。 只能靠报错原文 + 现象去故障案例库搜，并查/var/log/ascend_seclog/ascend_install.log。本课未编造任何安装器码表。 - 码段 → 层的对照本课部分沿用 E1 的归纳，属教学用归类，非官方表述，仅用于快速判断，不作为判据。
EE1023的 plogretCode对照表只列了官方该页给出的 4 条，不是全部。- 具体码（如
100013、207012、507905等）本课未逐一展开，请以官方《aclError》表1 为准。 - 本课的
grep/lsmod/ldd等都属通用 Linux 命令，非昇腾专用；昇腾专用的只有npu-smi、msnpureport等。
附录 B · 本课出现的命令详解
看图对照：本课的命令分三类 —— 看环境（
echo）、捞码（grep/cat）、判版本与驱动（ldd/lsmod/version.info）。
grep —— 排障第一工具
命令 grep -rn "507033" $HOME/ascend/log/
含义：在日志目录里，把含某个特征词的行全找出来。 拆解：
grep（搜索）＋-r（递归子目录）＋-n（显示行号）＋ 关键词 ＋ 目录。 用法：grep -rn "ErrCode" $HOME/ascend/log/（找所有带码的行）；grep -rn "fault kernel_name" $HOME/ascend/log/（找失败算子名，官方写法）。 期望：打印出所有匹配的行（含文件路径与行号）。 不过会怎样：什么都不输出 → 关键词不在日志里（换个词试）或日志没生成（先开 DEBUG 复现）。
tail —— 只看最后几条
命令 grep -rn "ErrCode" $HOME/ascend/log/ | tail
含义：配合前面的命令，只显示结果的最后若干行，避免刷屏。 拆解：
|（管道，把左边输出交给右边）＋tail（显示末尾，默认 10 行）。 用法：tail -n 20可以指定行数。 期望：只输出末尾的几行。 不过会怎样：输出为空 → 前面那条grep没匹配到任何内容，问题在前一步不在tail。
export —— 让设置传给子进程
命令 export ASCEND_SLOG_PRINT_TO_STDOUT=1
含义：把日志同时打到标准输出（屏幕），方便一边跑一边看。 拆解：
export定义环境变量并传给之后启动的子进程；不加export只在当前 shell 有值，程序读不到。 用法：常和export ASCEND_GLOBAL_LOG_LEVEL=0配对使用；只在当前窗口有效，重开窗口要再来一遍。 期望：程序运行时的日志会同时出现在屏幕上。 不过会怎样：屏幕没有额外输出 → 变量没在这一层生效（比如程序是另一个用户/noexport启动的）。
一条能一次看全的对比：source 与直接改文件
含义：
source set_env.sh是在当前窗口执行脚本，脚本里设的环境变量会留在当前终端——这是"装完为什么要 source"的根本原因。 拆解：source 脚本（在当前进程里执行） vsbash 脚本（另起一个进程执行，变量不会留下）。 用法：source /usr/local/Ascend/cann/set_env.sh（root）；非 root 在${HOME}/Ascend/cann/set_env.sh。 期望：source之后echo $ASCEND_HOME_PATH有值。 不过会怎样：source 完还是空 → 路径写错，或该版本的set_env.sh不在这个位置（以实际安装路径为准）。
下一站：E5 精度问题排查 —— 程序不报错、结果是错的，该怎么查。