[Issue]: gfxhub SDMA0 page fault under ROCm compute (rocFFT) on RDNA3, introduced in 6.18, present through 7.0.x — no supported kernel serves RDNA3 + Arrow Lake Refresh

Problem Description

A kernel regression introduced in the 6.18 series and still present in 7.0.x causes GPU memory access faults under ROCm compute on RDNA3. In my case the trigger is rocFFT: workloads fault with "Page not present or supervisor privilege," faulting UTCL2 client SDMA0, escalating to a full GPU reset.

This appears to be the same regression as ROCm/amdgpu#204 (good on 6.17.9, bad on 6.18.3–6.18.6, RX 7900 GRE / ComfyUI) and the kernel-regression reports collected in the comments of ROCm/ROCm#5051. My report adds an HPC/rocFFT reproducer and a second RDNA3 SKU.

This regression has an unusual cost because of platform constraints on the CPU side. Arrow Lake Refresh (Core Ultra 200S Plus) systems want 6.12+; the last kernel unaffected by this regression is 6.17, which is EOL. The only maintained kernel that avoids the fault is 6.12 LTS. Every current kernel is unusable for RDNA3 ROCm compute on this fault path. Users are choosing between a security-maintained kernel and a working GPU.

Is it possible to triage of #204 (currently unlabeled/unassigned after ~7 months), and get a bisect/fix of the 6.17 to 6.18 change in the SDMA/KFD mapping path? The 6.17.9-good / 6.18.3-bad boundary in #204 should make the bisect tractable.

Operating System

Fedora 44

CPU

Intel Arrow Lake Refresh 270K Plus

GPU

ADM Radeon 7900 XTX

ROCm Version

7.1.1

ROCm Component

rocFFT

Steps to Reproduce

1. Boot kernel 6.18.x or 7.0.x with ROCm 7.x on gfx1100.

2. Run sustained batched FFTs through rocFFT. My reproducer is via Julia/AMDGPU.jl (which wraps the system rocFFT — same libhsa-runtime64/librocfft as C/HIP callers):

   using AMDGPU, AbstractFFTs
   A = AMDGPU.rand(ComplexF32, 2048, 2048)
   p = plan_fft(A)
   for i in 1:100_000
   p * A
   AMDGPU.synchronize()
   end

The fault also surfaces simply by running AMDGPU.jl's test suite (FFT tests).
3. Userspace reports: "Memory access fault by GPU node-1 ... Reason: Page not present or supervisor privilege" (raised from libhsa-runtime64 VMFaultHandler — i.e. the HSA runtime relaying the kernel fault, not a Julia-level error).
4. dmesg concurrently shows: [gfxhub] page fault, GCVM_L2_PROTECTION_FAULT, Faulty UTCL2 client ID: SDMA0 (0xd), followed by GPU reset. This kernel-side fault is the bug; the userspace entry point is incidental.
5. Boot into another distro with 6.17.x or 6.12 LTS; the identical loop and the full AMDGPU.jl test suite pass indefinitely. (I've used Debian 13 Trixie with ROCm 7.2.4 for this purpose.)

(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support

No response

Additional Information

Reproducer language is Julia but the fault is not wrapper-specific: identical SDMA0 signature reported from PyTorch/ComfyUI in ROCm/amdgpu#204. AMDGPU.jl links the system ROCm libraries directly. I can and will provide a pure HIP/rocFFT C reproducer on request if that helps.

Start with ROCm/amdgpu#204 and compare the known-good 6.17.9 and bad 6.18.3 kernels. Reproduce through rocFFT or the AMDGPU.jl FFT tests while checking dmesg for the gfxhub SDMA0 fault, then bisect the SDMA/KFD mapping path. Done means the fault no longer occurs on affected kernels and the sustained FFT loop and test suite pass.