Thanks for sending an issue! Please fill in the following template to help quickly solve your problem.

Describe the current behavior / 问题描述 (Mandatory / 必填)

mssanitizer -t synccheck 跑样例matmul_async_iterate报 WAIT_FLAG_DEV ×28（全是奇数号 AIV）+ MSTX_WAIT_CROSS ×28（全部 AIC）→ SUMMARY: 56 pipe(s) locked up。
算子本身运行没有任何问题，根因是 KFC 框架里一对"AIC 写 / AIV 读同一个 UB 流控变量"的上报桩配不上：

• AIC 侧：KfcCommServer::FreeUB()（kfc_comm_server_gm.h:93-100）上报 MSTX_WAIT_CROSS，但没写 .isMore ⇒ 工具按"严格模式"要求它必须有配对方；
• AIV 侧：配对方是 KfcCommClient::AllocUB()（kfc_comm_client_gm.h:179-187）的 MSTX_SET_CROSS，而它只在"UB 内容借道 GM 中转"的 DataCopy 路径里被调用 —— 本样例只做 UB→UB / UB→GM，走不到那里。

于是 AIC 那条 wait 全程没有 SET；工具对 isMore=false 的 MSTX wait 是严格匹配（pipeline_replayer.cpp:206-232）：找不到 SET 就判 PROCESS_STALLED → 该 AIC 队列卡死 → 它后面那条 FFTS_SYNC(flagid=1) 永远不被回放 → 等 flagid=1 的 28 个奇数号 AIV 一起卡住 → 报 56 个 pipe。

实测补 1 行即消除（同族本来就有这个标志：kfc_comm_gm.h:515-521 的 RcvMessageImpl 写着 .isMore = true;）：
补后连跑 5 次都通过、结果不变。

期望算子侧确认一下此问题根因，推动框架侧修改kfc代码，解决该算子误报告警的问题。

Environment / 环境信息 (Mandatory / 必填)

Ascend950PR（Ascend950PR_9579，dav-3510）、NPU 3；
CANN 9.1.0（安装包 Ascend-cann-toolkit_9.1.0_linux-x86_64.run + Ascend-cann-950-ops_9.1.0_linux-x86_64.run，自昇腾社区下载）；
msSanitizer 26.0.0（随 CANN 包提供）；
样例 asc-devkit examples/01_simd_cpp_api/04_advanced_api/00_matmul/matmul_async_iterate。

Steps to reproduce the issue / 重现步骤 (Mandatory / 必填)

source <CANN>/set_env.sh ; export ASCFLAGS="-g --cce-enable-sanitizer" TMPDIR=/tmp ASCEND_RT_VISIBLE_DEVICES=3
SAMPLE=<asc-devkit>/examples/01_simd_cpp_api/04_advanced_api/00_matmul/matmul_async_iterate
cmake -S $SAMPLE -B ./b222 -DSCENARIO_NUM=1 -DCMAKE_ASC_ARCHITECTURES=dav-3510 -DCMAKE_ASC_LINK_FLAGS=--cce-enable-sanitizer && make -j48 -C ./b222
cd ./b222 && mkdir -p input output && python3 $SAMPLE/scripts/gen_data.py
./demo                                                # ✅ 正确，maxdiff 2.29e-05
mssanitizer -t synccheck --log-level=error -- ./demo   # ❌ 报 56 pipe(s) locked up；按下面"预期结果"改框架头重编后再跑 → ✅ No error detected

Describe the expected behavior / 预期结果 (Mandatory / 必填)

框架侧（KFC）给 FreeUB() 的上报记录补一个字段即可：

             .addr = reinterpret_cast<uint64_t>(ubAvalidTail),
             .flagId = 1,
             .pipe = pipe_t::PIPE_MTE3,
+            .isMore = true,
         };

语义是"这条跨核 wait 允许没有配对方"（UB 流控变量是"谁需要谁读"，消费方可能整次运行都不走那条路）。
改后 synccheck 应报 No error detected；

建议顺带把框架里同类桩排查一遍（共 5 处：kfc_comm_client_gm.h L111/L152/L180、kfc_comm_gm.h L515、kfc_comm_server_gm.h L94，目前只有 L515 标了 isMore）。

Related log / screenshot / 日志 / 截图 (Mandatory / 必填)

见附件 222_synccheck误报.zip：改前/改后 synccheck 日志、记录流关键行、框架头 orig/patched 与 fix.diff、验证报告。
222_synccheck误报.zip

Special notes for this issue/备注 (Optional / 选填)

• 算子侧不需要改任何代码：本样例只用了 Matmul 高阶 API 的常规用法（Iterate<false> + GetTensorC<false> + DataCopy），问题在框架上报桩的标志位；请协助转框架（KFC）侧。
• 影响面：任何"只做 UB→UB / UB→GM 拷贝、不触发 AllocUB"的 matmul 类算子，挂 synccheck 都会被判 "kernel locked up"。