Hello AMDGPU maintainers, I’m investigating recurring GPUVM faults on an RX 6700 XT (Navi 22), with symptoms closely matching the October 5 report about UTCL2/TCP permission faults on the same GPU.
The issue has persisted across two physical RX 6700 XT cards, multiple kernel/Mesa/firmware versions, KDE Plasma and Hyprland. Our retained evidence index identifies 33 separate gfxhub fault episodes through November 5, 2026. Recurring signature: - gfxhub, UTCL2/TCP shader client - Non-zero PASID/VMID - READ faults with PERMISSION_FAULTS=0x3 - WRITE faults with PERMISSION_FAULTS=0x5 - MAPPING_ERROR=0 - gfx ring timeout typically 10–12 seconds after the first fault, sometimes followed by MODE1 reset and VRAM loss On October 13, a GPUVM lifecycle trace captured 18,386 events without reported loss, starting before VM creation. It did not show a software mapping/PTE update for the first faulting VA (0x800901108000, PASID 14, VMID 3). However, we cannot confirm the actual hardware PTE/TLB state, or which shader instruction issued the access. We have also built an isolated RadeonSI command/descriptor recorder and verified it with a real EGL test, but have not yet captured the operation responsible for a desktop fault. Mesa report: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16584 Related Navi 22 report: https://mail-archive.com/[email protected]/msg152661.html Could you advise: 1. Does this signature suggest an invalid shader-generated VA, a GPUVM/PTE update or invalidation race, or a known Navi 22 issue? 2. Which kernel tracepoints or diagnostics would reliably establish PTE update and TLB invalidation completion for the faulting PASID? 3. Is there a known patch or a targeted, reversible workaround worth testing? We can provide sanitized journal excerpts, incident timelines and selected devcoredump metadata. We would prefer not to publish raw VRAM or user-memory contents. Thank you.
