Skip to content

[Bug] A5 URMA first GET stalls waiting for CQE on physical cards 5 to 6 #2969

Closed

Description

@ChaoWao

Platform

a5 (Ascend 950 hardware)

Runtime Variant

tensormap_and_ringbuffer

Description

On the original st-onboard-a5 runner, a two-rank URMA GET from physical card 5 to physical card 6 consistently leaves the first CQE pending until the scheduler reports S3 and the AICPU stream returns 507018. The reverse transfer on the same pair completes. This reproduces before domain A is released and with domain B absent.

Steps to Reproduce

  1. Build and install the A5 package at the commit below with PTO-ISA 90a3796597a5fabc2ce5066e73f785c2e85822f7 and CANN 9.3.0 on suzhou-blue128.

  2. On the original physical cards, run the retained-domain test from the checkout using its installed environment.

    task-submit --device 5,6 --run '
      SIMPLER_SCHEDULER_TIMEOUT_MS=2000 \
      SIMPLER_OP_EXECUTE_TIMEOUT_US=3000000 \
      SIMPLER_STREAM_SYNC_TIMEOUT_MS=6000 \
      python -m pytest \
        tests/st/a5/tensormap_and_ringbuffer/urma_deferred_completion/test_urma_domain_lifecycle.py::test_retained_urma_domain_release_preserves_other_domain \
        --resource-child --platform a5 --runtime tensormap_and_ringbuffer \
        --device "$TASK_DEVICE" --exclude-level 4 --require-pto-isa \
        --pto-session-timeout 1200 --manual exclude -v
    '

Expected Behavior

Both first GETs complete, both dependent consumers run and match their golden outputs, and the test subsequently verifies that releasing domain A preserves domain B.

Actual Behavior

Card 5 emits FIN for the first GET. The host-readable failure snapshot shows both mailbox messages consumed, the normal completion sentinel received, and one software submission. The first CQ slot still has its pending owner phase when the scheduler exits.

AICPU stream 61, task 17: 507018
scheduler code=100 S3 completed=0/2 running=0 ready=1 waiting=1 orch_done=1
head=2 tail=2 normal_done=1 row=58 target_bb=1 target_cqe=1
sq_head=1 sq_tail=0 submitted=1 cq_tail=0 depth=32768 cqe_dw0=0x0
Controlled run on the same installed diagnostic build Outcome
Original test, physical 5/6 1 failed, 0 skipped. Card 5 row 58 stayed pending. Card 6 completed both native tasks.
Delay allocation of domain B until after the first GET and value check, physical 5/6 1 failed, 0 skipped. Card 5 showed the same snapshot before B was allocated.
Same single-domain first transfer, reverse Worker rank order to [6,5] 1 failed, 0 skipped. Physical card 5 still failed, now on row 2. Card 6 completed using row 58.
Same single-domain first transfer, replace peer 6 with 7 in the same card group 1 passed, 0 skipped. The test completed all subsequent domain lifecycle assertions.

The snapshot confirms what the AICPU poller observed. Transport doorbell delivery and visibility of the CQE from another device-side observer remain to be checked.

Git Commit ID

Original CI checkout e465bd65ae032aac4b5fd2e90aaca54a0813f76e. The same first fault reproduced on #2966 head 8a5305056f244f15b5432c8f9ff258036efbebe8. The local diagnostic build 5e8c43449a37e7d22a925e9e68aee5d933627691 adds the read-only snapshot.

CANN Version

9.3.0

Driver Version

25.7.rc1.12, as reported by npu-smi

Host Platform

Linux (x86_64)

Additional Context

Original A5 CI job. #2966 covers the secondary force-reset crash after the failed communication run. The initial URMA stall remains reproducible with that protection.

Related to #2860, which records an intermittent chunked URMA GET failure on the same physical pair. The reproduction here uses the first small GET, with the completion and rank/peer controls above. A shared cause remains unverified.

Activity

  1. ChaoZheng109 commented on Nov 11, 2026

    @ChaoZheng109
    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-11 UTC,在原物理设备对 5/6 上运行完整用例 test_retained_urma_domain_release_preserves_other_domain,3/3 通过,每轮 JUnit 均为 tests=1, failures=0, errors=0, skipped=0。

    每轮均完成以下全部阶段及结果校验:

    1. 创建保留域 A/B,完成 A 的首次双 rank GET 和后继 consumer。
    2. 释放 A,验证 B 未被释放并继续 GET。
    3. 重建同名 A,验证新 domain ID 并完成 GET。
    4. 释放剩余域,确认 worker.live_domains == {},正常退出。

    本轮测试源码与 issue 引用的 #2966 head 8a5305056f244f15b5432c8f9ff258036efbebe8 逐字一致;运行库沿用上述旧基线,并非该 head 的精确构建。保持 scheduler 2000 ms、op-execute 3000000 us、stream-sync 6000 ms。

    任务:task_20261111_030930_61891914347。本轮距同一次重启约 13 小时;#2854 与 #2860 的相关复现场景也已通过。

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions