附录 8：实验异常解析

从异常现象找到故障层次

本附录用仓库中的真实故障讲解如何分析昇腾 310B 实验异常。案例多数在香橙派 AI Pro 20T（Ascend310B1）上观察到，也包含 8T（Ascend310B4）对照。异常可能发生在系统、Python 环境、ATC/TBE 编译、ACL 生命周期、模型图计算、视频编码或 USB/ALSA 外设层。某一块板上观察到失败，并不等于已经证明板卡硬件有缺陷。各实验的镜像、驱动、CANN、模型和外设并不完全相同；原始记录也未全部证明来自同一块物理板。

本教程把“原因”分成两层：直接故障环节是日志和对照能够定位的失败位置；底层触发原因是该环节为何失败，可能仍需实验区分。例如 rc=139 已能确认进程收到段错误，但不能单凭退出码断言是某个 NPU 算子。observed-fail 和 observed-pass 仅描述指定条件下的实测结果；unknown 表示触发原因尚未证实。“已隔离”表示有临时避让方法，不等于修复。

分析时按顺序问：设备和进程能否启动？ATC 是否生成 OM？ACL 能否加载、执行、清理？相同输入重复运行是否稳定？OM 是否与 ONNX 参考一致？实际任务质量是否合格？视频、音频和摄像头也要各自检查。上一层通过，只能说明上一层工作；不能代替下一层的结论。

案例	已确认的直接故障环节	尚未定位的底层触发原因
systemd 与 SSH	PID 1 段错误，服务管理冻结	镜像/文件系统、软件冲突或硬件状态中的哪一项触发崩溃
Violin ONNX 转 OM	ATC 在 TBE 预编译或 CannKB 初始化阶段失败	子进程为何退出，是否涉及环境、资源或版本配套
PolyU-B 掌纹评测	指标写出后进程 rc=139	崩溃的具体函数及触发条件
H.264/H.265 编码	VENC 建通道返回 507018	通道参数、功能配套或设备侧异常中哪一项导致返回码
板载音频播放	ALSA 内核锁路径硬锁，随后 OS_PANIC	哪个驱动/外设/并发事件导致锁无法释放
YOLOv10n、YOLO26n ONNX 转 OM	mixed FP16 OM 在 20T 上重复推理输出变化	ATC 图融合、缓冲区或执行时序中的实际机制

系统启动时 PID 1 崩溃

20T 的一轮系统日志出现 systemd[1]: Caught <SEGV> 和 Freezing execution；另一轮启动也出现同类信息。SSH 登录明显变慢，journald 向服务管理器发送消息失败，系统负载曾达到约 16.28。这是一组系统级异常，不能仅按 SSH 配置问题处理。该系统后来重新安装，重装前没有找到可重复验证的单一根因；不能把某一镜像的故障当成所有环境都存在的结论。

systemd 管理服务，journald 依赖它传递服务状态；PID 1 冻结后，SSH 登录慢和日志发送失败可能是同一系统故障的下游表现。已定位的是服务管理器崩溃，尚未定位的是它为何段错误。“SSH 慢”本身不是根因证据。

可检查的假设包括：当时的系统镜像或文件系统损坏、系统库与服务版本不匹配、异常负载造成的系统状态问题，以及板级内存/供电等硬件不稳定。这些都是候选解释，现存记录不能给它们排序。若仅某一镜像反复复现而清洁镜像稳定，软件/存储路径更可疑；若不同镜像、不同负载下仍伴随内核内存错误或掉电记录，应再检查硬件路径。镜像重装后的恢复不能单独证明“镜像损坏”，因为重装同时改变了多个条件。

再次出现时，应先通过串口保留 PID 1 状态、journalctl -b、dmesg、负载、进程和存储错误快照，然后在受控条件下逐项比较镜像、系统包及硬件状态。系统管理器冻结后采集的模型性能数据不能作为稳定基线。详细记录见 samples/case3/docs/11-troubleshooting.md 的“SSH 登录慢和 systemd 崩溃”。

Violin ONNX 转 OM 时 ATC 编译失败

Violin ONNX 转换实验使用 Ascend310B1、驱动 25.2.0、CANN 目录 8.0.0（组件 7.6.0.1.220）和 Anaconda base Python 3.9.2。一次默认 FP16 转换成功，生成的 OM 也能在 20T 上推理；另一组 force_fp32、mixed_float16 转换以退出码 255 失败，另两种精度模式以 139 退出。重启复测时，默认 FP16 与 mixed FP16 在 TBE/CannKB 初始化阶段报 E90000、unexpected EOF，其中一次达到 180 秒测试时限。

两组失败发生在不同阶段：精度扩展测试已进入 TBE 算子预编译；重启复测的 unexpected EOF 出现在 CannKB/配置初始化阶段，尚未进入具体算子。这说明该环境组合的 ATC 编译路径失败，但 ACL 加载已编译 OM 的路径仍可工作。unexpected EOF 说明通信另一端提前结束，不能单独指出为何结束。默认 FP16 的成功也否定了“B1 永远无法转换模型”的说法。

待区分的解释有三组：编译子进程因资源、进程或文件系统问题退出；Python/动态库/CANN 组件装载组合不一致；TBE/CannKB 服务状态异常。进入预编译阶段的失败还可能涉及特定编译模式或图，但初始化阶段的失败不能直接据此归咎于某个 ONNX 算子。另一块 B4 在相同驱动/CANN 标称版本下完成过 Violin 转换，说明版本号相同本身不足以解释 B1 失败；两板镜像和运行状态仍需核对。

教学上的最小区分实验是固定同一 ONNX、ATC 命令和输入 shape，分别保存 ATC 主进程与子进程的退出信息、第一条错误前的日志、资源占用和 Python/动态库来源；先判断失败停在初始化还是预编译，再比较 B1、B4。当前统一 ascend 环境中的其他模型已有 ATC 成功记录，因此本项保留为旧软件组合的历史故障。轮次、日志位置及 B4 对照见 samples/case3/docs/11-troubleshooting.md 的“20T 本机 ATC 转换失败”。

掌纹评测退出码 139

PolyU-B 100 人交叉域实验中，Ascend310B1 上 CCNet 与四个 CompNet 变体在写出指标后以 rc=139 退出，内核同时记录 err_ret=-512；CompNet IITD 一项正常退出。这些 OM 的单次 ACL 加载、推理、资源清理测试通过。因此，“曾写出评测指标”和“完整评测进程稳定退出”是两道不同的门禁；崩溃前的 Rank-1、EER、AUC 不能直接作为稳定验收结果。

139 是进程因段错误退出的信号；它没有指出崩溃函数。指标先写出，提示问题可能发生在评测后半段或退出清理阶段，但写文件有缓冲，不能只凭文件存在就证明推理已全部结束。err_ret=-512 是同期内核线索，不足以证明它和用户进程段错误具有唯一因果关系。

可能原因包括：ACL 模型/数据集/上下文释放顺序错误、长时间运行后设备或主机资源累积、个别输入触发的原生库错误，或者驱动侧异常。单次 ACL smoke 通过只排除了“所有输入都无法完成一次推理”，无法排除长循环与清理问题；IITD 正常退出也说明不是所有模型路径都会崩溃。

区分方法是在相同模型和数据顺序下记录“最后成功的样本、最后一次 ACL 调用、进入清理、清理结束”四个边界，并分开运行短循环、完整循环和仅加载/释放循环。若稳定地在同一输入处失败，优先看输入与算子路径；若总在 acl.mdl.unload、acl.rt.reset_device 或进程退出附近失败，优先查资源生命周期；若随运行时长变化，重点查泄漏和设备状态。定位原生段错误还需要堆栈或 core dump，而不是只读取 Python 异常。恢复这项评测前，应保存退出码、内核日志与资源清理结果。原始汇总见 samples/case4/docs/05-candidate-weight-download-and-310b1-evaluation-20261008.md 的“PolyU-B 100 人交叉域结果”。

VENC 通道创建返回 507018

在 Ascend310B1、CANN 8.0.0、驱动 25.2.0、Python 3.9.25 的实验中，ACL 初始化、VPC Resize/CropResize、JPEG 编解码和纯 Python WebRTC 测试通过，但 H.264 与 H.265 的 venc_create_channel 均返回 507018。内核还记录 aicpu exception 和 err_ret=-512。该板缺少 /dev/video0，所以真实摄像头到浏览器的完整链路也处于阻断状态。

这里已确认的是该板当时的 VENC 通道创建失败。VPC 和 JPEG 通过，说明 ACL/DVPP 的部分功能可用，却不能证明 VENC 子路径可用。缺少摄像头节点是另一项前置条件缺失，不能拿它解释无摄像头也能运行的 VENC 基础探针返回码；也不能把这次失败外推为所有 310B 都不支持 WebRTC。

尚未区分的可能原因包括：通道属性与实际能力不匹配、VENC/AICPU 与当前驱动或固件的配套问题，或设备侧资源/状态异常。aicpu exception 增加了设备侧路径需要检查的理由，但若无同一调用的时间线与栈，不能断言它就是 507018 的唯一原因。不能仅凭这个数字猜测厂商错误码含义。

最小复测应使用不依赖摄像头、浏览器的固定 NV12 帧，只建立一个编码通道，记录 H.264 与 H.265 的全部属性、返回码和紧邻时间戳的设备日志。若两种编码都在建通道前失败，应优先核对共享的通道设置和运行环境；若仅一种失败，再检查对应 codec 能力。编码器成功后，再单独检查 /dev/video0、采集格式及浏览器媒体接收。证据边界见 samples/chapter6/docs/README.md 的“环境与证据状态”。

板载音频硬锁与整板重启

Orange Pi AI Pro 20T 在 Ubuntu 22.04.3、内核 5.10.0+、驱动 25.2.0、CANN 8.0.0 下多次重启。设备黑匣子记录 OS_PANIC；NMI watchdog 指向 CPU hard lockup，最早的 panic 调用栈位于 alsa-sink-ascen 的 ALSA 锁路径。部分同一启动周期还出现 xHCI 控制器无响应。周期性的 LPM 电源/电流读取错误在 8T 上也出现过，不能仅凭这些日志同时出现就断言它导致 20T 音频硬锁。

从调用栈可以把直接故障链写清楚：alsa-sink-ascen 线程进入 ALSA 锁路径，CPU hard lockup，watchdog 触发 OS_PANIC，整板重启。尚未定位的是为什么这把锁无法释放。可能涉及板载 ALSA 驱动与 PulseAudio/PipeWire 并发状态、内核音频实现、设备侧电源/USB 事件或硬件状态。同期 xHCI 无响应与 LPM 电源读取失败值得保留，但它们与 ALSA 硬锁的先后及因果关系没有被证明。8T 也出现周期性 LPM 事件，却未出现相同音频硬锁，因此 LPM 不能单独解释本次 20T 故障。

操作员在当前开机周期临时停止并屏蔽用户态 PulseAudio/PipeWire 服务后，完成约 12 分钟空载观察与五轮 32-token 文字 SSE 请求；累计约 18 分钟未再观察到硬锁或重启。这支持“阻断音频 sink 路径可暂时避免观察到的重启”，但不能证明 PulseAudio/PipeWire 本身有缺陷，更不能证明长期稳定。20T 语音功能应继续保持关闭，重启后临时屏蔽状态需要重新核对。

进一步定位需要供应商或受控维护窗口核对音频驱动栈、完整黑匣子时间线与板级电源/USB 事件，再设计一次有串口监测和回退条件的音频 A/B。正常服务测试不应主动解除隔离来重现整板崩溃。详见 samples/case9/docs/09-troubleshooting.md 的“20T 板载音频 sink 硬锁导致整板重启”。

YOLOv10n 与 YOLO26n ONNX 转 mixed FP16 OM 后在 20T 上推理不稳定

在 20T Ascend310B1 与 8T Ascend310B4 上，使用各模型在两板相同的 ONNX 源文件、CANN 8.0.0、固定合成输入以及各板转换的 OM 做交叉测试。YOLOv10n、YOLO26n 的 ONNX 都已成功转换为 mixed FP16 OM，且 OM 能在两板完成 ACL 加载、执行和清理。异常发生在转换后的 OM 推理结果，并非 ATC 转换失败。纳入比较的 17 个现存 OM 模型/精度组合都能在两板执行；其中 15 个组合的两种来源 OM 在两板及重复捕获中逐位相同。COCO NanoDet-Plus-M FP32 因两板均缺少现存 OM，属于 untested。

重复推理的输出波动只出现在 YOLOv10n 与 YOLO26n 的 mixed FP16 OM：20T 上无论运行本板转换还是 8T 转换的 OM，相同输入的重复输出都会变化；两份 OM 在 8T 上重复输出稳定。这排除了“只有跨板运行才会出错”的解释。两模型的 FP32 OM 在 20T 上也重复稳定，但其与 ONNX 参考的数值门限仍未通过。

定点探针将 YOLOv10n 的触发区段缩小到第一处注意力 MatMul 路径，将 YOLO26n 缩小到 /model.14/Resize 路径。对应单算子小图稳定；等价改写 ONNX 后，新 OM 在 20T 上各五次输出稳定，而原 OM 紧邻复测仍波动。这支持原始整图的编译与执行组合触发波动，但不证明单个 MatMul 或 Resize 内核有缺陷。

目前有三类合理假设：ATC 在 B1 mixed FP16 下为相邻节点选择了有问题的融合/布局；运行时对中间张量的缓冲区复用或同步存在问题；某个只在整图形状与上下文中触发的 kernel 路径不稳定。定点 Dump 和等价改写会改变图优化、缓冲区布局或执行时序，故“打开 Dump 后稳定”不能作为单算子定罪。下一步应在保留原始输入和输出合同的前提下，让编译器/运行时诊断分别记录异常图段前后的张量，并检查两种 OM 的算子映射、融合和内存规划；任何候选修复都要再次通过原始 ONNX 数值门限和真实图像框级验证。

两份改写 OM 的最终输出仍未通过原定 ONNX 数值门限，不可直接用于生产。现有实验也不能单独区分“B1 硬件缺陷”与 B1 专属编译策略、驱动/固件组合或运行时缺陷。

这两个 mixed FP16 组合目前不得以“可跨板加载”代替“结果稳定”准入。其余 15 个组合的逐位一致仅覆盖固定合成输入；部分组合仍未通过与 ONNX 的数值门限，也未完成真实图像框级质量或 COCO mAP 验证。完整协议、逐模型结果和板端原始报告位置见 samples/case4/docs/08-detector-onnx-om-consolidated-20261113.md。

两板都失败时如何改变归因

SN0002 USB 摄像头提供的视频 UVC 接口可枚举，但其 UAC 麦克风在 20T 上只采集到 22 个样本便报 Input/output error；8T 上也独立复现了相同的 22 样本失败。日志还记录过 usb_set_interface failed (-110)、音频端点设置失败、USB 断连或复位。8T 上另一款 UGREEN 摄像头能够完成 16 kHz 立体声采集。

这组对照缩小了问题范围：20T 独有的 NPU 算子错误不能解释两板上同一 UAC 外设的相同失败；8T 能采集另一款设备，也不能说明 8T 的所有 USB 麦克风都可用。更合理的候选解释是 SN0002 的 UAC 描述符/固件、USB 音频时钟或当前内核 USB 音频驱动之间存在兼容问题；哪一项是真正原因仍未定位。下一步应固定采样率、声道和连接方式，在两板分别测试 SN0002 与已验证麦克风，并按时间对齐 USB 错误。这样才能区分“外设自身问题”与“外设和系统组合问题”。原始记录见 samples/case9/docs/09-troubleshooting.md 的“SN0002 摄像头 UAC 麦克风不兼容”。

不应归入 20T 硬件缺陷的现象

• Health: Alarm 在本次 20T、8T 对照中均出现；单独的告警不能推翻已完成的 ACL 推理，也不能替代具体错误码、设备复位或数值差异。
• 多个检测模型的 OM 与 ONNX 参考未通过数值门限，但其中一些在两板逐位相同；模型导出、编译精度、输出合同、后处理和数值比较方式都需要逐一核对。两板一致不能证明结果正确，也不能单凭门限失败证明 B1 硬件错误。
• SN0002 的跨板失败已在上节分析，应先按外设与 USB 音频组合问题排查，不能列作 20T 独有故障。

从现象到解释的复测顺序

每条新增记录至少写明板卡 SoC/算力、系统与内核、驱动/固件/CANN、Python 环境、模型与输入合同、完整命令、错误码或输出差异、原始报告位置，以及是否在同板重复、同精度对照和另一块板复现。先判定失败发生于环境启动、ATC、ACL 生命周期、数值比较、任务质量还是外设链路，再记录根因状态。对于 139、设备 reset 或整板重启，应停止当前批次并保留现场，不用其他模型的成功结果覆盖该次失败。

每个假设都应写出它预期出现的信号和能推翻它的对照。例如“仅跨板 OM 导致波动”预期本板 OM 稳定，而实测本板 OM 也波动，所以该解释已被否定；“单独 Resize 内核必然有错”预期小图也不稳定，而实测小图稳定，因此也不成立。不能用多个同时改变的条件解释一次恢复。

复测结论只能更新对应故障项的状态；一次恢复不抹去历史失败，也不自动扩展到不同的 SoC、CANN 版本或输入形状。对于上文六项，人工审核应重点确认：现象与环境是否对应、已确认的直接环节是否有原始证据、候选原因是否写明验证办法、没有复测的历史问题是否仍明确标为历史。