• mes=1（dmesg 确认 mes_v11_0_0 / sdma_hqd_mask 0xfc）：同配置 26 条崩 2 次，报错和 mes=0 一字不差（conversation snapshot copy + SDMA1/MAPPING_ERROR 0x1）。不是非 MES 路径的问题。
• 6.8.0-147（mes=0、ROCm 7.2 不变）：Strata 缓存全开 120/120、0 page fault（40.8 min，32K 10.5 s）；ComfyUI 10 s 工作流 3/3，热跑 361.8 s（7.0 是 361.7 s）。
• 7.0.0-42 同配置约 30 次崩 4 次。

所以 7.0 这代内核是放大器（和 #5475 的 6.18+ 概率上涨对得上），已切 6.8 默认并重开缓存，HSA_ENABLE_SDMA=0 留兜底。6.8 不是根治，只是 120 次没触发。

补一句：这台 7.0 的 amdgpu 编译默认就是 mes=0，不是我们关的。

问一下：6.18+ 的 userptr 回归有 upstream 确认或测试内核吗？

从 dmesg 看是 SDMA1 在 UTCL2 上碰到未映射页（MAPPING_ERROR 0x1），典型是「拷贝过程中源/目标映射已被回收」。20GB DiT + 15GB 文本塔在 24G 卡上必然大量 evict/migrate，长上下文 KV 又在涨，ComfyUI 换模型时 free/mmap 与 SDMA 搬运竞争就会偶发。你关会话缓存不崩、HSA_ENABLE_SDMA=0 不崩，正好对应「少走 SDMA 的 hostVRAM 搬运」。另外 XNACK off 时 GPU 页错误不会重试，任何失效映射都直接 illegal address，这解释了同一工作流时好时坏。

建议按这个顺序试：

1. 先做对照：mes=1（默认）跑同一套 145 次压测。若稳定，问题基本锁定在非 MES 路径，生产别用 mes=0，把两组 dmesg 一起提给 ROCm/amd。
2. 必须 mes=0 时，把「同时驻留」降下来：ComfyUI 用 --normalvram/--lowvram 分批换模型，文本塔跑完即卸，别让 DiT 和文本塔同时压满；长上下文任务别和视频生成并发。
3. 保留 HSA_ENABLE_SDMA=0 作生产兜底（你已测 120 次 0 崩），冷 prefill +21% 比崩进程划算。
4. 补一组内核对照：7.0.0-42 很新，ROCm 7.2 的 amdgpu 与内核版本错配也会出 UTCL2 错，换 ROCm 官方支持的内核（6.8/6.11 LTS）跑同样压测，能排除内核侧回归。
5. 复现时开 AMD_LOG_LEVEL=3，把崩溃前的 HSA 调用尾部一起留档；有 debugfs 权限的话再抓 amdgpu_vm_info，定位是哪个 BO 没映射。

结论：mes=0 在 gfx11 上属未验证路径，先证明 mes=1 稳，再决定要不要为它继续投入。