Skip to content

[Bug] A5 TMR 分块 URMA PUT 在 CI 中出现 S3 停滞及后续释放超时 #2854

New issue
New issue
Closed
Closed
[Bug] A5 TMR 分块 URMA PUT 在 CI 中出现 S3 停滞及后续释放超时#2854
Assignees
JiaSalixYeChaoZheng109

Description

@JiaSalixYe
JiaSalixYe
opened on Nov 3, 2026

Platform

a5 (Ascend 950 hardware)

Runtime Variant

tensormap_and_ringbuffer

Description

A5 Per-PR onboard CI 的 TestUrmaChunkedPut::test_run 在两个独立 PR 上出现相同执行阶段停滞：S3:ready-but-all-idle，completed=0/3 running=0 ready=1 waiting=2 orch_done=1。设备 5 的 run 1 失败，随后出现 507018、poisoned run lane、通信域 release barrier 超时及子进程关闭超时。

本 issue 跟踪首个执行阶段故障及其后续清理症状；根因尚未确认。不能仅凭 507018 判定 URMA、scheduler 或硬件故障，也不能把后续 release 超时当作首个卡住的原因。

两次 CI 的共同 main 基线为 142ee15a7fa46925b9802984fa1ac75676e87d43，PTO-ISA pin 为 f83d4b7e4be0a4ca9805944ae2d9ce8c84e581f7。

CI 证据 实际 checkout 物理设备顺序 结果
#2818 onboard job PR merge bb87243742b81edc16e7d39703b7059eee20631a [5,6] TestUrmaChunkedPut，上述 S3 状态；约 191.1 秒后子用例失败
#2850 onboard job PR merge 590ce489ce1b8fe54603023a3ca19e5e0884bfa6 [6,5] 同一用例、相同 S3 计数及 release 超时；约 191.0 秒后子用例失败

#2850 当时的 head 8e806bfeadfab56baa580d39c7b5ed5a77c7289b 相对共同 main 仅修改两个 A5 HBG 测试文件，不包含 #2818 的 A3 Host 改动。因此该症状的出现不依赖 A3 Host 改动；尚未进行纯 main checkout 的专门硬件复现。

Steps to Reproduce

  1. 使用上述失败 revision、其固定 PTO-ISA 和兼容的 A5 SDK，构建与 CI 一致的 URMA-enabled runtime；两次 job 均使用 SIMPLER_ENABLE_PTO_URMA_WORKSPACE=ON。

  2. 在 A5 设备队列分配内运行 onboard Per-PR sweep。原 CI 的 pytest 入口为：

    .venv/bin/python -m pytest examples tests/st \
  --platform a5 --exclude-level 4 --device <allocated-devices> -v \
  --require-pto-isa --pto-session-timeout 1200 --manual exclude

    <allocated-devices> 应替换为队列实际分配的设备，不绕过共享设备锁。

  3. 检查 tests/st/a5/tensormap_and_ringbuffer/urma_deferred_completion/test_urma_deferred_completion.py::TestUrmaChunkedPut::test_run。该用例对 256 MiB + 32 KiB 数据执行分块 PUT，再由后继 GET 和 consumer 验证结果。

  4. 可在相同构建和设备队列中缩小到该 pytest node 进行定位；本次未新增独立硬件运行，单例是否稳定复现尚未确认。

Expected Behavior

分块 PUT 完成后，后继 GET 和 consumer 正确执行并通过数值校验；通信域和 Worker 正常关闭。发生真实设备错误时，保留首个故障证据并明确报告后续回收状态。

Actual Behavior

两条 job 的首个执行失败具有相同诊断：

simpler runtime failed: orch_error_code=0 sched_error_code=100 runtime_status=-100
scheduler timeout sub_class=S3:ready-but-all-idle (detail=3) completed=0/3 running=0 ready=1 waiting=2 orch_done=1 stuck_task_id=0xffffffffffffffff stuck_core=-1

Host 随后报告 AICPU stream 的 507018；run 1 的 finalize 返回 -100，run lane 被标记 poisoned。另一 rank 的后续清理报告：

file_barrier('alloc_0_release') timed out after 120s waiting for rank 0
release_domain: barrier timed out; releasing local state anyway

测试 teardown 还出现子进程未在 close budget 内退出的错误。

S3 中 running=0 来自当时的 core ownership，ready=1 来自未完成任务的 fanin 已满足；这些计数本身不足以区分未调度、已执行但 deferred completion 未退休或其他状态问题。

Git Commit ID

CANN Version

本次未从 job 日志确认精确版本，不借用其他机器或其他硬件验证的版本。

Driver Version

本次未从 job 日志确认。

Host Platform

Other (please specify): Linux，自托管 runner 238PR-npu-a5-1（#2818 job 元数据）；本次未确认 CPU 架构。日志中的 Python 为 3.10.18。

Additional Context

Activity

  1. JiaSalixYe
    added a commit that references this issue on Nov 3, 2026

    CI: print complete A5 stall logs before artifact upload

    43e6917
  2. hw-native-sys-bot
    assigned
    ChaoZheng109
    on Nov 3, 2026
  3. ChaoZheng109
    added a parent issue on Nov 4, 2026

  4. JiaSalixYe commented on Nov 4, 2026

    @JiaSalixYe
    JiaSalixYe
    on Nov 4, 2026
    ContributorAuthor

    补充近期 CI 的横向核查结果：在本次已检查的 CI 样本中，URMA GET/PUT 的同类 S3 失败都集中在物理设备 5、6 配对（devices=[5,6] 或 [6,5]）；暂未发现其他设备组合执行这些 URMA GET/PUT 用例时出现同类问题，其他卡对有明确的用例 PASS 记录。

    核查范围：2026-11-03 18:31 至 2026-11-04 15:49（北京时间）创建的 66 个 CI run；读取相应 A5 onboard 日志，并补查重试前的 attempt，避免最新绿色结果掩盖原失败。部分重试会复用成功 job 的日志，没有将它们重复计为独立实验。

    失败记录

    共查到 8 次不同执行的同类失败：4 次大分块 PUT、4 次普通 GET，均在 238PR-npu-a5-1，均报告 device 5 的调度超时。

    时间（北京时间） 用例 设备顺序 耗时 Job
    11-03 19:09 TestUrmaChunkedPut [6,5] 191.0s 日志
    11-03 20:10 TestUrmaChunkedPut [5,6] 190.8s 日志
    11-03 21:34 TestUrmaChunkedPut [5,6] 128.9s 日志
    11-03 22:19 TestUrmaChunkedPut [6,5] 190.8s 日志
    11-03 22:45 TestUrmaGet [6,5] 189.7s 日志
    11-03 23:24 TestUrmaGet [6,5] 189.7s 日志
    11-04 09:43 TestUrmaGet [5,6] 189.2s 日志
    11-04 12:19 TestUrmaGet [5,6] 126.9s 日志

    共同症状是 orch_error_code=0、sched_error_code=100、runtime_status=-100、S3:ready-but-all-idle，随后 alloc_0_release 等待对端超时 120 秒。PUT 为 completed=0/3 running=0 ready=1 waiting=2 orch_done=1；普通 GET 为 completed=0/2 running=0 ready=1 waiting=1 orch_done=1。

    其他设备组合的明确通过记录（示例）

    Job GET PUT
    runner 1，本轮固定源码诊断 大 GET [7,6] PASS 8.1s；普通 GET [7,6] PASS 6.0s 大 PUT [5,4] PASS 7.9s；普通 PUT [5,4] PASS 6.0s
    runner 2，重试轮 普通 GET [0,2] PASS 6.4s 大 PUT [3,1] PASS 8.3s；普通 PUT [3,1] PASS 6.0s
    runner 2 普通 GET [1,2] PASS 6.1s 大 PUT [0,3] PASS 8.3s；普通 PUT [0,3] PASS 6.0s

    其中 runner 1 的固定源码轮实际 checkout 43e6917815b0f05a73301b4b5014119aee9e0b84，大 GET/PUT 均未 skip，两个子进程运行窗口重叠约 3.7 秒；所以不仅是换到 runner 2 才通过，设备 5、6 分别与其他卡配对也能通过。

    对定位的影响

    • 不是仅 GET [5,6]、PUT [6,5]：两类用例在两种设备顺序下都失败过。 devices 列表表示设备分配顺序，不能直接解释成单向传输；两端都会向对端发起操作，PUT 用例还包含后续 GET 读回。
    • 普通 GET 只有 64 KiB，也能出现同类 S3；大 GET 被 skip 后，大 PUT 仍有失败。因此“大分块”或“大 GET/PUT 并发”并非这些故障的必要条件。
    • 有些 run 的重试换了 runner/卡对后通过，不能据最新绿色状态认定原 5/6 组合已经修复。
    • 当前最强的观察是故障集中在 5/6 配对。这是已检查样本的结论，不等于已证明某张卡损坏，也不能仅凭相同 S3 确认所有失败的底层根因完全一致。最新失败日志缺少 SQ/CQ/CQE 现场，仍需针对该组合进一步定位。

  5. JiaSalixYe commented on Nov 4, 2026

    @JiaSalixYe
    JiaSalixYe
    on Nov 4, 2026
    ContributorAuthor

    补充更新统计和 A5DT 自测结果。

    CI 核查范围：北京时间 2026-11-03 16:27:31 至 2026-11-04 18:18:24 创建的最新 100 个 CI run，包含历史 attempt。 读取77份 A5 job 日志，按实际用例结果及时间去重复用日志。仅统计 tests/st/a5/tensormap_and_ringbuffer/urma_deferred_completion/test_urma_deferred_completion.py 内实际执行并有最终结果的 URMA 回归；skip、前置失败和未执行的组合不计。

    CI 设备配对 通过 失败
    [5,6] / [6,5] 0 12
    其他设备配对 322 0

    5/6 的12次失败均在 238PR-npu-a5-1：普通 GET 6次、大 GET 1次、大 PUT 5次。新增失败包括今天 17:09 的大 PUT [6,5] 和 17:45 的普通 GET [5,6]。后者重试通过时已换成 GET [4,6]、PUT [7,5]，不能算作5/6通过。

    A5DT 自测未复现： 在可登录的238 DT/CANN 9.3环境，分别用 [1,3] 和 [5,6]，复用原 C++ 用例逻辑的独立 runner，运行64 KiB GET、64 KiB PUT和原规模 256 MiB + 32 KiB PUT，均完成全量输出校验及正常关闭。测试基线为旧产品代码加只读诊断，没有靠后续产品修复获得通过；本次是独立执行，非原 pytest sweep/并发组合。

    目前观察是：这批 CI 样本中5/6全失败、其他配对全通过，而 A5DT 当前受控条件下无法复现。 尚未确认 DT 入口与失败 CI 是同一套物理设备，因此暂不能认定硬件损坏或根因已定位。

  6. ChaoZheng109
    assigned
    JiaSalixYe
    on Nov 5, 2026

  7. JiaSalixYe commented on Nov 6, 2026

    @JiaSalixYe
    JiaSalixYe
    on Nov 6, 2026
    ContributorAuthor

    11 月 4 日 20:20（北京时间）重启 suzhou-blue128 后，截至 11 月 6 日 10:43，已检查的 47 份 A5 板上 CI 日志里没有再出现本 issue 的 S3:ready-but-all-idle。原故障卡对 5/6 在 CI 上通过了 7 次普通 GET（64 KiB）和 2 次大分块 PUT（256 MiB + 32 KiB），其中原 runner 238PR-npu-a5-1 分别通过 6 次和 1 次。大分块 GET 仍被跳过，恢复验证由 #2860 跟踪。 首次 GET 恢复 · 原 runner 的大 PUT · 同机另一 runner 的大 PUT

    重启前，11 月 2 日晚还有 5/6 通过记录。11 月 3 日首次报错到重启前，核查到的 5/6 样本为 0 通过、16 失败，16 次都在物理卡 5 报执行失败，其中 15 次明确记录了 S3。同期其他卡对未观察到同型 S3。 故障前通过 · 首次 S3 · 重启前最后一次 S3

    另外，两台 A5 都做过固定物理卡 5/6 的复测，均未复现。

    • **独立 A5DT 机器（11 月 4 日）**用旧产品基线 142ee15a 加只读诊断，在复用原 C++ 用例逻辑的独立 runner 上运行 64 KiB GET、64 KiB PUT 和原规模 256 MiB + 32 KiB PUT。三项均通过全量结果校验并正常退出。
    • 原 A5 CI 主机重启后（11 月 5 日），5/6 用当时的 main 跑通了原规模 TestUrmaChunkedPut。用旧基线 142ee15a 加只读诊断、配旧 ISA f83d4b7e 重测，也通过了同一个用例。另外用历史失败提交 41a0599 和旧 ISA，在重放相关前序用例的四卡短序列中，5/6 的 TestUrmaGet（64 KiB）也通过。同机重启后的首次 CI GET 恢复早于 Fix: preserve communication domain ownership through rollback #2835 和 Update: adapt PTO communication to caller-owned workspace #2847 合入。

    重启前后对照样本的 TDT 日志记录主机侧 HCOMM 兼容包均为 9.2.0 / 20261009_000323778。重启前的两份 5/6 失败样本（大 PUT 和普通 GET）中，两端设备均上报 9.2.0 / 20261015_201912253。重启后旧代码复测通过时，两端均上报 9.2.0 / 20261009_000323778。故障窗口内，4/5 曾在两端均为 10 月 15 日构建的情况下跑通同规模 PUT，设备日志中的 RsOpenUrmaSo 行号也与失败样本一致。由于重启还更换了内核并重新初始化了设备服务，仍无法把恢复归因到某一项。 4/5 通过的 job · 4/5 设备日志

    建议按 重启后未再复现，根因未确认 暂结。如再次出现同型 S3，可在设备 reset 前保留双端 HCOMM 构建和首个未完成任务的 SQ/CQ/CQE，再按现场继续定位。

  8. JiaSalixYe
    closed this as not plannedon Nov 6, 2026

  9. ChaoZheng109 commented on Nov 9, 2026

    @ChaoZheng109
    ChaoZheng109
    on Nov 9, 2026
    Collaborator

    补充一次重启后出现的同型故障：PR #2939 的 11 月 7 日 A5 CI 中，设备 5/6 配对再次出现 S3:ready-but-all-idle，报错设备仍为 device 5。 这次用例是并发 PUT，而非本 issue 最初的分块 PUT；目前确认症状和设备组合一致，尚未确认底层根因相同。

    本次执行与日志

    任务图与首个故障

    L3 提交一次 next-level 调用，L2 生成 8 个任务节点：三轮各两个独立 PUT，随后一个 GET，最后一个 consumer。

    PUT A0 + PUT B0
       |
PUT A1 + PUT B1  （每个都依赖上一轮的两个 PUT）
       |
PUT A2 + PUT B2
       |
GET（2 blocks）
       |
consumer（读取结果并 +1）

    六个 PUT 均为单 block AIV 任务，每个任务内重复发起 4 次 PUT；GET 为双 block AIV 任务。任务总数 8 不包含外层 L3 next-level 调用，也不按每次通信请求计数。

    首轮 run 约 2 秒后报告：

    orch_error_code=0 sched_error_code=100 runtime_status=-100
scheduler timeout sub_class=S3:ready-but-all-idle (detail=3)
completed=0/8 running=0 ready=2 waiting=6 orch_done=1
stuck_task_id=0xffffffffffffffff stuck_core=-1

    按依赖图推断，两个 ready 对应首轮 PUT A0/B0；日志没有打印这两个任务的具体 ID。这些计数不能区分“尚未下发执行”和“核上已执行、异步通信完成尚未确认、任务尚未退休”，因此目前不能断言是纯任务下发问题，也不能确认 PUT 已在核上执行后卡住。

    随后 Host 报 AICPU stream 507018，跳过输出 copy-back；清理阶段 rank 1 的 file_barrier('alloc_0_release') 等待 rank 0 超时 120 秒，报告 reclamation unconfirmed; retaining owner，并出现子进程 teardown 错误及 finalize 阶段 segmentation fault。后续清理异常不应替代首个 S3 作为定位起点。

    与本 issue 的关系

    此前关闭说明是“11 月 4 日重启后未再复现，根因未确认”。本次发生在该重启之后，与历史故障共同具备：5/6 配对、device 5 报错、零任务完成、S3、随后 release barrier 超时 120 秒。不同点是任务图从原分块 PUT 的 0/3、ready=1、waiting=2 变成并发 PUT 的 0/8、ready=2、waiting=6。

    建议作为同型故障复发线索继续跟踪；若再次采集现场，应在 reset 前保留双端 HCOMM 构建信息、首轮 PUT 的执行/异步等待状态及 SQ/CQ/CQE，区分调度下发与通信完成路径。本次仅核对现有 CI 日志和用例源码，未新增硬件复现或重跑，也尚未取得足以确认根因的队列现场。

  10. JiaSalixYe
    reopened this on Nov 9, 2026

  11. ChaoZheng109 commented on Nov 9, 2026

    @ChaoZheng109
    ChaoZheng109
    on Nov 9, 2026
    Collaborator

    补充 PR #2929 的 A5 CI 失败记录：与 #2854 的历史故障高度相似，可作为同型故障继续跟踪，但目前尚不能确认底层根因相同，也不能据此排除PR #2929 的影响。

    失败现场

    • 测试 head：0b7b554ba654b8261dbda49115c14ef53db4695f。
    • A5 onboard job，runner 238PR-npu-a5-1。
    • 用例：tests/st/a5/tensormap_and_ringbuffer/urma_multi_jetty/test_urma_multi_jetty.py::TestUrmaMultiJettyBoundaries::test_run，内部 case put_below_j1。
    • 设备对 [5,6]，device 5 / worker 0 报错，发生在 run 9。
    • 使用 DEVICE 源 URMA 通信域，单 jetty，每次传输 256 MiB − 32 KiB，尚不需要按 256 MiB 分块。

    首个执行阶段故障为：

    orch_error_code=0 sched_error_code=100 runtime_status=-100
scheduler timeout sub_class=S3:ready-but-all-idle (detail=3)
completed=0/7 running=0 ready=1 waiting=6 orch_done=1
stuck_task_id=0xffffffffffffffff stuck_core=-1

    任务依赖图是：

    PUT_1 -> observer_1 -> PUT_2 -> observer_2 -> GET readback -> observer_3 -> consumer

    按依赖图推断，唯一 ready 对应第一轮 PUT；日志没有给出有效的任务 ID。这些计数不能区分“尚未下发执行”和“核上已执行、异步通信完成尚未确认、任务尚未退休”，因此不能直接断言是纯调度下发问题或 URMA completion 问题。

    Host 同时报告 AICPU stream 507018。后续清理中，另一 rank 的 file_barrier('alloc_8_release') 等待 rank 0 超时 120 秒，并报告 reclamation unconfirmed; retaining owner。release 超时是后续症状，应以首个 S3 为定位起点。

    本轮实际通过范围

    • Boundary 用例先执行的 8 个 GET case 全部通过：单/双 jetty × below/exact/above/tail。
    • 随后第一个 PUT case put_below_j1 失败；其余 PUT boundary case 未执行，不能说双 jetty 的 PUT 边界测试全部通过。
    • 独立的 TestUrmaMultiJettyDepth、TestUrmaMultiJettyQueueWrap、TestUrmaMultiJettySenders、TestUrmaMultiJettySmallRequests 均通过，使用另一设备对 [7,4]。

    与 #2854 的关系

    共同点是 5/6 配对、device 5 报错、零任务完成、S3、running=0、orch_done=1，以及后续 release barrier 超时。#2854 原分块 PUT 的计数为 0/3、ready=1、waiting=2，本次因任务图不同变为 0/7、ready=1、waiting=6。

    #2854 后续也记录过普通 GET 失败，因此大分块并非历史同型故障的必要条件。该 issue 曾在主机重启后暂未复现，但最新又记录了 #2939 并发 PUT 在同一设备对上的同型 S3，并已重新打开：复发记录。

    目前证据支持沿 #2854 的方向继续排查；还没有足够现场认定硬件根因、确认与PR #2929 无关，或认定多 jetty 配置引入了回归。下一步定位需要在 reset 前保留双端 HCOMM 构建信息、首个 PUT 的执行/异步等待状态及 SQ/CQ/CQE，以区分任务下发与通信完成路径。本次为现有 CI 日志及源码核查，未新增硬件复现或重跑。

  12. ChaoZheng109 commented on Nov 9, 2026

    @ChaoZheng109
    ChaoZheng109
    on Nov 9, 2026
    Collaborator

    补充本轮复现与定位结果（2026-11-09 UTC，关联 #2939）：当前 A5PR 机器状态下，设备 5 向设备 6 发起 URMA PUT/GET 稳定失败；同一故障已在不经过 simpler 的原生 PTO-ISA 用例中复现。尚不能认定 mesh 物理连接损坏。

    1. simpler 基线与 PR 对照

    最新已报告的 CI 失败：run 42544882570 / job 128927635214，TestUrmaChunkedPut 在设备 5/6 上失败，设备 5 报 S3，completed=0/3 running=0 ready=1 waiting=2 orch_done=1。

    在 a5pr 使用隔离 checkout、独立 venv、架构预检查和 task-submit 锁卡对照：

    版本 / 用例 设备对 结果
    PR 修改前基线 a2ae1953b390c62bee84860278100f8580aa6657，ChunkedPut 5/6 失败，同样是设备 5 S3
    PR head 4b3bf8745ce4f911f13475608affbace6a9b119c，ChunkedPut 5/6 失败
    基线，64 KiB GET 5/6 失败
    基线，ChunkedPut 1/2、5/7 均通过
    基线加只读超时快照，scheduler timeout 从 2 s 延至 20 s 5/6 仍失败，无 CQ 完成进展

    因此，该失败在 #2939 修改之前已存在，不能归因于这个 PR 新增的 initializer。

    诊断版本在超时时捕获：

    wait_count=1 normal_done=1 waiting=2 conditions=2
row=60 target_bb=1 target_cqe=1
sq_head=2 sq_tail=0 submitted_cqe=2 cq_tail=0
cqe_dw0=0x00000000 next_cqe_dw0=0x00000000

    PUT 的 AIV 函数体已经返回，两项 URMA 完成条件仍未满足，后继 GET/consumer 因此不能开始。ready=1, running=0 不能解释成“PUT 尚未下发执行”。SQ head 是软件发布的 producer 状态，这个快照不证明硬件已消费 WQE/doorbell。20 s 对照得到相同的零 CQ 进展（该次 row=56）。

    2. 原生 PTO-ISA 对照：绕过 simpler

    固定使用与失败 CI 相同的 ISA 提交 5487a6b0e8d9bd3653dbee8d7c874c667ee8db2f。CANN HCOMM/HCCL/runtime 为 9.2.0 / 20261009_000323778，driver 为 25.7.rc1.12。

    运行官方 C++/MPI 用例：

    • TPutAsyncUrma.Vec_FloatSmall：1 KiB PUT。
    • TGetAsyncUrma.Vec_FloatSmall：1 KiB GET。
    • TPutAsyncUrma.Vec_Int32_Over256MB_Chunked：257 MiB PUT，拆为 256 MiB + 1 MiB。

    原生路径自己通过 HcclCommInitRootInfo 和 UrmaWorkspaceManager::Init 初始化，在 AIV 内 event.Wait()，随后校验数据；不加载 simpler，不经过其子通信域创建、任务调度或 AICPU deferred-completion 管理。唯一源码适配是把测试原先固定的设备 0/1 映射到队列分配的 TASK_DEVICE，未改通信初始化参数、发送或等待逻辑。每个用例使用全新的 MPI 进程。

    下表箭头表示请求发起端 → 对端，不是 GET 的数据流向：

    请求发起端 → 对端 1 KiB PUT 1 KiB GET 257 MiB 分片 PUT
    5 → 6 失败 失败 失败
    6 → 5 通过 通过 通过
    5 → 7 通过 通过 通过

    以上 9 次均实际运行双 rank，无 skip。两个失败的 PUT 都有：

    [ISA_BIND] rank=0 device=5
[ISA_BIND] rank=1 device=6
Rank 0 Device 5 SyncRet 0 peer 1 status=-2 (0=never attempted, -1=BuildAsyncSession, -2=Wait)
Rank 1 Device 6 SyncRet 0 Expected: 0 Actual: -1

    GET 则报告 Rank 0 Device 5 SyncRet 0 Expected: 10000 Actual: -1。GET 原用例没有检查 Wait 的布尔返回，因此其直接证据是数据校验失败；PUT 明确记录了 Wait 失败。SyncRet=0 代表 kernel/stream 正常返回，并不代表 URMA 成功。三个失败用例总耗时约 23.8–24.5 s；通过用例约 2.9–4.0 s（均含初始化/清理，不是传输延迟）。

    反向及 5/7 对照通过后，再启动全新进程重复 5→6 小 PUT，仍得到相同的 Wait 失败和未更新数据（约 23.6 s）。所以目前应描述为当前机器状态下稳定复现，而不是已经证明任何机器状态下必现。

    3. 对 mesh / 状态问题的判断边界

    • 故障可以在本次运行完全绕开 simpler 时复现；并不要求复用 simpler 的 run/domain 或完成状态。
    • 不能直接认定“5/6 的 mesh 物理连接坏了”：6 发起 GET 5 时，数据也是从 5 流向 6，但测试通过。当前失败共同点是由 5 对 6 发起请求，需要继续检查这一路径的 SQ/doorbell、通信端点、实际端口选择和请求/应答处理。
    • 试过仅在进程内设置 PTO_URMA_PEER_ROUTE=uplink，但该机器 rank graph 没有可达的 layer>0 端口，初始化被拒绝。这不是一次传输超时，也没有验证替代物理路径。
    • 设备 5/6 当前 fault event 数为 0；设备 5 的 SIO TX/RX error 数为 0。这些计数不能证明 URMA/UB 链路健康。捕获日志中暂未发现明确的 URMA completion/ACK 错误码。
    • 原生测试前没有做设备级/机器级复位，所以仍不能排除先前工作负载（包括此前 simpler 运行）遗留的设备/链路持久状态。当前证据还不能在 ISA、HCOMM、驱动、固件或机器状态之间确定最终责任层。

    建议下一步在独占维护窗口建立干净设备状态，按“先原生 ISA → 再 simpler → 再原生 ISA”的顺序测试，并采集对应端口/队列状态。不要在共享机器仍有其他任务时直接复位。

    4. 实验索引

    实验 task-submit ID
    simpler 基线 ChunkedPut，5/6 task_20261109_020434_359856518756
    simpler PR head ChunkedPut，5/6 task_20261109_020948_366795528246
    simpler 基线 GET，5/6 task_20261109_022201_38122921888
    simpler 基线 ChunkedPut，1/2 task_20261109_020948_366790216494
    simpler 基线 ChunkedPut，5/7 task_20261109_022247_381878211665
    simpler 超时快照，5/6 task_20261109_022720_384468818229
    simpler 20 s 超时快照，5/6 task_20261109_023325_38640788733
    原生 ISA 三用例，5→6 task_20261109_032839_41878242830
    原生 ISA 三用例，6→5 task_20261109_032839_41878593138
    原生 ISA 三用例，5→7 task_20261109_032839_41879254252
    原生 ISA uplink 初始化对照 task_20261109_033317_172663733
    原生 ISA 5→6 小 PUT 重复 task_20261109_033317_1730119674

    原生结果保存在测试账号的 ~/pr2939-isa-20261109/results/，并归档为 native-results.tgz、native-followup.tgz；设备绑定补丁和二进制摘要分别为 harness.patch、binary-sha256.txt。早期 MPI 动态库加载失败导致的 skip 已排除，未计作通过。以上实验全部结束，本轮没有修改 PR、进行全机复位或更改全局配置。

  13. ChaoZheng109 commented on Nov 10, 2026

    @ChaoZheng109
    ChaoZheng109
    on Nov 10, 2026
    Collaborator

    补充 URMA 与 CANN/HCOMM 官方流程的对照结果（2026-11-10）。没有发现当前路径遗漏必要的建域开关；发现一个 WQE 完成顺序与完成判定不匹配的风险，以及 ISA 原生测试的异常清理缺口。两者尚未证实为本 issue 卡死的根因。

    对照版本

    • 最近失败 job 129689937288，simpler 7b5f08e49ed43ba0b969848fcb4dccb2a9794534。
    • CI 的 PTO-ISA 为 90a3796597a5fabc2ce5066e73f785c2e85822f7；与之前原生实验的 5487a6b0e8d9bd3653dbee8d7c874c667ee8db2f 相比，URMA 实现及 A5 comm 测试没有差异。
    • a5pr 实际安装 HCOMM/HCCL/Runtime 均为 Version=9.2.0, timestamp=20261009_000323778。虽然安装目录名为 cann-9.3.0，不能据目录名判断组件版本发生升级。
    • 对照了实际安装包头文件、CANN 官方 asc-comm 示例及 hcomm 官方文档/源码。较新开源源码仅作为参考，不假定与已安装二进制完全相同。本轮没有新增上板实验或重启设备。

    1. 优先验证 WQE completion order

    普通 PUT/GET 配置 官方安装包默认值 当前 PTO-ISA
    WQE flag 0x2d 0x20
    completion order 开启 关闭
    fence 开启 关闭

    实际安装包的 asc/impl/comm_api/aicore/hcomm/common/hcomm_inner_def.h 中，URMA_DEFAULT_CFG 为 odr=5, fence=1, cqe=1，经官方 FillSqeCtx 编码得到 0x2d。当前官方源码也可对照：默认配置。

    ISA 的 FillSqeCtx / UrmaAwaitOneCqe 使用 flag = 0x20 | placeOrder；普通 PUT/GET 的 placeOrder 为 0。另一方面，GetUrmaCompletionRecordAt / UrmaPollCqAt 按 CQE 个数/位置推断对应 SQ 前缀完成，没有按 CQE entryIdx 识别具体完成的 WQE；队列压力回收收到一个 CQE 后直接把 SQ tail 加一。

    因此，同一 SQ 同时存在 A、B 两个未完成请求时，如果 B 先完成，第一条 CQE 可能被当成 A 完成，进而提前放行依赖或回收 SQ 槽。检查 CQE 前缀的 owner/status 并不能代替完成顺序或 WQE 身份保证。

    不要求机械照抄官方所有 flag，但完成判定必须与 ordering 保证匹配。 建议独立比较普通 PUT/GET 的 0x20、只增加 completion-order 的 0x24、官方默认 0x2d，保持路由、通道数、队列深度不变。FAA/notify 的执行顺序语义需单独保留。

    因果边界：此前 fresh queue 上单 WQE 的 1 KiB PUT/GET 也失败，没有第二个请求可以抢先完成。因此这项静态正确性风险不能单独解释已观察到的所有 CQ 不前进现象。

    2. ISA 原生测试的失败清理存在风险

    common.hpp 中：

    • CleanupSetupFailure() 忽略 HcclCommDestroy 返回值。
    • Cleanup() 在 Destroy 失败时打印错误，但仍置空 comm、Finalize manager、释放已注册的 workspace/devBuf。
    • 原生 GET 测试未检查 Wait 的返回值；stream synchronize 成功并不代表 URMA 已完成。

    Destroy 失败不能证明通信资源已停止引用内存；MPI barrier 也不能证明 DMA 停止。这与 manager 要求先销毁 HCCL 资源、再释放 external workspace 的生命周期前提不一致。应传播 Wait/Destroy 错误，无法证明停止时保留 backing，并停止该测试进程的继续复用。官方示例的简化析构本身也未完整处理 Destroy 失败，不能直接当作异常恢复规范。

    之前保存的原生实验输出未观察到 HcclCommDestroy failed，尚不能说这个分支已经造成设备污染。

    3. 建域、正常回收与剩余差异

    官方 AIV URMA 示例 的主流程为：注册内存 → 查询 endpoint → HcclChannelAcquire(COMM_ENGINE_AIV) → WriteNbi/ReadNbi → Drain → stream/rank 同步 → 销毁 comm → 释放 backing。AIV 直驱明确不需要配置 hcclOpExpansionMode。

    当前 simpler 已使用 AIV engine、每 domain 私有子通信域、双端 data/notify 两块注册内存，并在正常释放时检查 SQ/CQ drained 和 peers release barrier，然后销毁 comm、释放 backing。固定 memTag 不等于同一 comm 重复注册。HcclChannelAcquire 的通道由 HCCL 管理，不能因为未显式调用 HcommChannelDestroy 就判断泄漏，也不应混用两套所有权接口。官方 Acquire 文档、Destroy 文档。

    最近失败提交的 comm_hccl.cpp 在 Destroy 失败时不会继续 free；ChipWorker::finalize 在 live comm 且回收未确认时阻止继续 device finalize/reset。代价是资源可能保留到进程退出；这不是成功回收，也尚不能证明跨进程驱动资源泄漏。需要确认失败 worker 真正退出及驱动层资源回收，不能只用下一次 stream/malloc 成功作为 URMA 健康证据。

    另外仍需隔离验证：

    • 官方示例限定 CTP；ISA 默认取 layer 0 第一个 CTP/TP 链路。应记录成功/失败卡对的实际 protocol、双端 EID、tpID，尚无证据证明选择错误或 mesh 物理损坏。
    • ISA 原生小测试也默认为全部 AIV 建通道，资源规模并不小。应先用单 AIV/单 channel 与官方样例对照，再放大通道数。
    • ISA 自定义 SQ depth 使用 HcclChannelDesc.raws，属于版本敏感路径；当前 simpler 和已测原生 small/chunked 的 sqDepth=0，不走该覆盖，不能据此解释本次失败。
    • 已安装 ChannelEntity/SQ/CQ 相关布局未发现明显错位，但 ISA 自维护队列状态与官方 Hcomm 数据面不同；比较时应新建 channel，不要在同一活跃 channel 上混用两套实现。

    下一轮最小实验

    1. 相同安装包/设备对：官方 Hcomm 单 channel → ISA 单 AIV/单 channel → simpler，分别使用独立进程。
    2. ISA 单独比较 ordering，采集 WQE、SQ/CQ head/tail、CQE owner/status/entryIdx、endpoint 和通道数。
    3. 分开测试“只建/销毁不发送”“建一次多次发送”“反复建/发送/销毁”，同时比较同进程与新进程；检查 jetty/QP、CQ、MR、endpoint 资源，而不只看显存。
    4. 首次失败即保存现场和清理返回值。如果需要证明谁遗留了设备状态，应在获准的维护窗口从确认恢复的状态开始做官方→ISA→simpler→官方对照。之前原生复现没有全局复位前置条件，不能排除更早工作负载留下的状态。

    以上实验尚未执行，当前不将配置差异或异常清理风险写成已证实根因。

  14. ChaoZheng109 commented on Nov 11, 2026

    @ChaoZheng109
    ChaoZheng109
    on Nov 11, 2026
    Collaborator

    结论：升级 CANN 至 9.3.0（1104 包）并重启机器后，本问题已恢复正常，本 issue 按已完成关闭。

    环境：a5pr；HCOMM/HCCL/runtime 均为 9.3.0 / 20261104_000324968，驱动 25.7.rc1.12。复测沿用旧 simpler 基线 a2ae1953b390c62bee84860278100f8580aa6657 和旧 PTO-ISA 5487a6b0e8d9bd3653dbee8d7c874c667ee8db2f，未依靠升级 ISA 或修改通信实现来恢复。

    2026-11-10 UTC 重启后复测，全部真实执行、无跳过：

    测试 结果
    原生 ISA，5→6 三轮、6→5 一轮；每轮 1 KiB PUT、1 KiB GET、257 MiB 分块 PUT 12/12 通过，双 rank 均通过
    simpler 5/6 TestUrmaChunkedPut 3/3 通过
    simpler 5/6 TestUrmaGet 3/3 通过
    simpler 0/1 TestUrmaDeferredCompletionDemo 3/3 通过

    原生 ISA 复用了升级后、重启前仍失败的同一份二进制，SHA256 一致。升级后未重启时仍复现，重启后恢复，因此此处的解决措施包含升级 CANN + 重启。

    任务：task_20261110_144051_56431211090、task_20261110_144356_6531477077、task_20261110_144356_65308515992。

    同一次重启约 13 小时后，#2860 分块 GET 和 #2969 完整通信域生命周期也分别连续三轮通过。

    当前按 CANN 升级并重启后的复测结果结项；尚未单独区分升级与重启清理状态各自的作用。后续如再次出现相同问题，将继续跟踪或重新打开本 issue，补充当时的 CANN/驱动版本、卡对、运行历史及 SQ/CQ/CQE 现场。

  15. ChaoZheng109
    closed this as completedon Nov 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions