Repository navigation
[Bug] A5 TMR 分块 URMA GET 在 CI 中偶发 S3 超时 #2860
Description
Platform
a5 (Ascend 950 hardware)
Runtime Variant
tensormap_and_ringbuffer
Description
A5 onboard CI 的 TestUrmaChunkedFetch::test_run 偶发失败：同一测试在一次 PR CI 中通过，在后续 CI 中因设备调度器 S3 超时失败。两次 CI 的 checkout SHA 不同，因此这是间歇性现象的证据，尚不能据此计算失败率或认定根因。该用例已在 main 的 #2853 中临时标记为 skip，测试代码仍保留；需要定位后恢复。
Steps to Reproduce
- 使用 A5 URMA-enabled 构建，
SIMPLER_ENABLE_PTO_URMA_WORKSPACE=ON，在分配到的两个 A5 设备上运行tests/st/a5/tensormap_and_ringbuffer/urma_deferred_completion/test_urma_deferred_completion.py::TestUrmaChunkedFetch::test_run（L3）。设备查询、预检和测试均应在同一个task-submit设备分配任务内完成。 - CI 配置
SIMPLER_SCHEDULER_TIMEOUT_MS=2000。用例每个 rank 执行256 MiB + 32 KiB的分块 URMA GET，后继 consumer 读取结果。 - 对照 CI 记录：#2853 成功 job 在
238PR-npu-a5-2、设备[3,2]上通过（8.2 秒）；#2853 失败 job 在238PR-npu-a5-1、设备[5,6]上失败（子用例约 190.9 秒）。两次 job 分别运行 PR merge SHA8df0511dd98276eaf6440017c7cd48bf3511d521和a5b6b3ad3756fba22a2a5ac4655bb0da4fe79e82，不构成同 revision 对照。
Expected Behavior
两个 rank 的分块 GET 和后继 consumer 完成，结果校验通过，通信域正常释放。
Actual Behavior
失败 job 中设备 5 首先报告调度器无进展超时：
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/2 running=0 ready=1 waiting=1 orch_done=1 stuck_task_id=0xffffffffffffffff stuck_core=-1
随后 host 收到通用 AICPU 异常 507018，run lane 被标记 poisoned。另一 rank 后续发生 alloc_0_release barrier 120 秒超时，测试 teardown 报子进程关闭超时。这些清理阶段错误不能单独解释首个 S3 停滞。
Git Commit ID
失败 job 实际 checkout：a5b6b3ad3756fba22a2a5ac4655bb0da4fe79e82（PR merge SHA）。临时 skip 合入 main 的提交：2a51ac118（#2853）。
CANN Version
尚未从该 job 日志确认。
Driver Version
尚未从该 job 日志确认。
Host Platform
Other (please specify): Linux，自托管 runner 238PR-npu-a5-1；CPU 架构尚未确认。
Additional Context
- 相关 [Bug] A5 TMR 分块 URMA PUT 在 CI 中出现 S3 停滞及后续释放超时 #2854 记录了两次
TestUrmaChunkedPut的相同 S3 现象，均在238PR-npu-a5-1的设备[5,6]或[6,5]。本次 GET 失败也落在该设备对，应优先比较相同构建在该设备对和其他设备对上的行为；目前不能判定硬件、URMA 队列或调度器哪一层是根因。 S3的running=0是故障时刻的状态快照，不足以区分任务未调度、异步完成未退休或其他状态问题。失败 job 没有上传对应的设备日志，缺少 SQ/CQ/CQE 现场。- Support: capture A5 URMA stall diagnostics in CI #2858 是为该类停滞增加 URMA 队列/CQE 和设备日志采集的诊断 PR，并非修复。建议用诊断数据核对首个未完成请求，并比较 2 秒与更长无进展阈值；一次重跑通过或单纯放宽阈值不足以证明修复。
Activity
doraemonmj commentedon Nov 4, 2026
补充一次 普通 GET 的 A5 onboard CI 失败，说明同类 S3 现象并不限于本 issue 原先记录的分块 GET。
9085cec4459bdf98e15e927592154a212e61b749，runner238PR-npu-a5-1，设备[5,6]。tests/st/a5/tensormap_and_ringbuffer/urma_deferred_completion/test_urma_deferred_completion.py::TestUrmaGet::test_run，casepeer_fetch（普通 GET，非TestUrmaChunkedFetch）。子用例约 186.76 秒后报告 1 failed、1 teardown error。sched_error_code=100 runtime_status=-100，scheduler timeout sub_class=S3:ready-but-all-idle (detail=3) completed=0/2 running=0 ready=1 waiting=1 orch_done=1。host 随后报告 AICPU507018，run lane poisoned。rank 1 在清理时出现file_barrier('alloc_0_release') timed out after 120s waiting for rank 0，teardown 报 child process 未在 close budget 内退出。SIMPLER_ENABLE_PTO_URMA_WORKSPACE=ON、SIMPLER_SCHEDULER_TIMEOUT_MS=2000，Per-PR sweep 的--manual exclude。PR Fix profiler buffer alignment across simulated runtimes #2863 没有修改这个 URMA 用例或 A5 onboard workflow。这与原报告的分块 GET 有相同的 S3 分类、runner 和设备对，但用例规模不同。清理超时是执行失败之后的症状；现有 job 日志不足以判断首个停滞来自 URMA、调度器还是设备环境，也不能计算发生率。建议将普通 GET 一并纳入 #2858 的设备日志及队列/CQE 诊断对照。
ChaoZheng109 commentedon Nov 11, 2026
结论：升级 CANN 至 9.3.0（1104 包）并重启机器后，本问题已恢复正常，本 issue 按已完成关闭。
环境：a5pr；HCOMM/HCCL/runtime 均为
9.3.0 / 20261104_000324968，驱动25.7.rc1.12。复测沿用旧 simpler 基线a2ae1953b390c62bee84860278100f8580aa6657和旧 PTO-ISA5487a6b0e8d9bd3653dbee8d7c874c667ee8db2f，未依靠升级 ISA 或修改通信实现来恢复。2026-11-11 UTC，在原物理设备对 5/6 上专项复测：
TestUrmaChunkedFetch::test_run：每 rank256 MiB + 32 KiB分块 GET 及后继 consumer，3/3 通过。tests=1, failures=0, errors=0, skipped=0。TestUrmaGet已在上一轮 5/6 复测中 3/3 通过。2000 ms，没有通过放宽该阈值规避故障。专项任务：
task_20261111_030930_61891914347；普通 GET 任务：task_20261110_144356_6531477077。专项复测时距同一次重启约 13 小时，期间机器已有其他 CI 工作负载。此次只在隔离复测中解除 skip，未修改仓库中的 CI quarantine 标记。相关 #2854、#2969 也已复测通过。
当前按 CANN 升级并重启后的复测结果结项；尚未单独区分升级与重启清理状态各自的作用。后续如再次出现相同问题，将继续跟踪或重新打开本 issue，补充当时的 CANN/驱动版本、卡对、运行历史及 SQ/CQ/CQE 现场。