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 #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
-
Boot kernel 6.18.x or 7.0.x with ROCm 7.x on gfx1100.
-
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 #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.
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 #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
Boot kernel 6.18.x or 7.0.x with ROCm 7.x on gfx1100.
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 #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.