vrcompositor RenderThread triggers recurring amdgpu GPU page faults (RDNA2 / RADV), often requiring a hard reset
This is a two day investigation of myself in co-op with Claude Opus 5.
Summary
On an RX 6800 XT with RADV, vrcompositor's RenderThread repeatedly triggers a GPU
page fault in a narrow, recurring VA range. The kernel usually fails to reset the graphics
ring afterwards and performs a full GPU reset, which kills the session and requires a
hard power cycle.
The behaviour is independent of Mesa version, kernel version, Proton version, the running
application, and the SteamVR version — all were varied, see the exclusion list below.
vrcompositor is the faulting process in every single occurrence.
The problem is not new: systemd holds 41 vrcompositor / vrserver coredumps going back
to 2026-07-30. Most compositor crashes are invisible to the user because SteamVR
restarts the compositor; it only becomes fatal when the crash coincides with a GPU hang.
System
|
|
| GPU |
AMD Radeon RX 6800 XT — Navi 21, 1002:73bf rev c1 |
| Driver |
RADV (Mesa), amdgpu |
| CPU |
AMD Ryzen 9 5950X |
| RAM |
125 GB |
| OS |
Arch Linux, KDE Plasma on Wayland (kwin_wayland) |
| Kernel |
tested 6.18.49-lts and 7.2.3-arch1 |
| Mesa |
tested 26.1.6 and 26.2.2 |
| linux-firmware |
20260810 |
| HMD |
Valve Index, DisplayPort, tested at 90 Hz and 120 Hz |
| SteamVR |
tested 2.17.8 (beta 2026-09-01) and the 2026-06-18 beta branch |
Symptom
The headset and both desktop monitors go black. The machine does not recover; a hard
reset is required. In a minority of cases the kernel manages Ring reset succeeded and
the session survives with visible rendering corruption.
Kernel log (representative)
amdgpu 0000:0c:00.0: [gfxhub] page fault (src_id:0 ring:24 vmid:6 pasid:182)
amdgpu 0000:0c:00.0: Process vrcompositor pid 8990 thread RenderThread pid 9080
amdgpu 0000:0c:00.0: in page starting at address 0x00000080013c5000 from client 0x1b (UTCL2)
amdgpu 0000:0c:00.0: GCVM_L2_PROTECTION_FAULT_STATUS:0x00601430
amdgpu 0000:0c:00.0: Faulty UTCL2 client ID: SQC (data) (0xa)
amdgpu 0000:0c:00.0: MORE_FAULTS: 0x0
amdgpu 0000:0c:00.0: WALKER_ERROR: 0x0
amdgpu 0000:0c:00.0: PERMISSION_FAULTS: 0x3
amdgpu 0000:0c:00.0: MAPPING_ERROR: 0x0
amdgpu 0000:0c:00.0: RW: 0x0
amdgpu 0000:0c:00.0: ring gfx_0.1.0 timeout, signaled seq=117748, emitted seq=117751
amdgpu 0000:0c:00.0: Process kwin_wayland pid 2788 thread kwin_wayla:cs0 pid 2846
amdgpu 0000:0c:00.0: Starting gfx_0.1.0 ring reset
amdgpu 0000:0c:00.0: Ring gfx_0.1.0 reset failed
amdgpu 0000:0c:00.0: GPU reset begin!. Source: 1
The fault is always client 0x1b (UTCL2), SQC (data), PERMISSION_FAULTS: 0x3 — a shader
reading memory it is not permitted to touch. The ring timeout is subsequently attributed to
kwin_wayland because the compositor of the desktop is the next submitter to the hung ring.
Observed faults
13 occurrences over two days. All in vrcompositor / RenderThread.
| Time |
Faulting VA |
Outcome |
| 2026-09-06 21:52 |
0x00000080013be000 |
GPU reset |
| 2026-09-06 22:01 |
0x00000080013b3000 |
GPU reset |
| 2026-09-06 22:27 |
0x00000080013be000 |
GPU reset |
| 2026-09-07 13:42 |
0x00000080013b3000 |
GPU reset |
| 2026-09-07 14:11 |
0x00000080013b3000 |
ring reset ×4, recovered |
| 2026-09-07 14:57 |
0x00000080013c5000 |
GPU reset |
| 2026-09-07 15:17 |
0x00000080013c5000 |
recovered |
| 2026-09-07 15:19 |
0x00000080013c5000 |
GPU reset |
| 2026-09-07 15:35 |
0x00000080013c5000 |
GPU reset |
| 2026-09-07 16:39 |
0x00000080013c5000 |
GPU reset |
| 2026-09-07 17:06 |
0x00000080013c5000 |
recovered |
| 2026-09-07 17:12 |
0x00000080013c5000 |
GPU reset |
| 2026-09-07 17:22 |
0x0000008001387000 |
GPU reset |
Every faulting address falls inside a ~250 KB window (0x8001387000 – 0x80013c5000).
The address is stable across many runs and shifts only when the SteamVR build changes.
Second failure mode
Once, with no application running at all — SteamVR had just been started — the display
pipeline hung instead:
[drm] *ERROR* dc_stream_state is NULL for crtc '2'! (×7)
[drm] *ERROR* [CRTC:100:crtc-2] flip_done timed out
[drm] *ERROR* [CRTC:100:crtc-2] hw_done or flip_done timed out
followed by vrcompositor aborting from its own ThreadWatchdog (SIGABRT). The system
survived. This confirms the fault is not tied to any particular application.
Ruled out
Each of the following was changed and the crash still reproduced:
- Application: Skyrim VR with and without mods, SKSE, Mod Organizer 2 / usvfs.
One crash occurred with no application running at all.
- Proton: 11.0 and Experimental. Proton prefix rebuilt from scratch.
- Mesa:
1:26.1.6-1 and 1:26.2.2-1.
- Kernel:
6.18.49-lts and 7.2.3-arch1.
- SteamVR:
2.17.8 (2026-09-01 beta) and the 2026-06-18 beta branch.
- Render resolution: SteamVR supersample 1.5 and 1.0; in-app render scale 1.5 and 1.0.
- Refresh rate: 120 Hz and 90 Hz.
- Async reprojection: both enabled (
CAP_SYS_NICE present) and disabled
(Insufficient permission to create high priority queue). Crashes occur either way.
- DisplayPort link: no link-training errors in the kernel log at any point.
Other VR titles (Beat Saber, Hellblade: Senua's Sacrifice VR) are playable, but the
coredump history shows vrcompositor was crashing during those sessions too — silently,
because SteamVR restarts it.
Crash history
coredumpctl records for vrcompositor / vrserver, by day:
2026-07-30 6 2026-08-04 2 2026-08-09 2
2026-07-31 6 2026-08-05 6 2026-09-04 1
2026-08-01 1 2026-08-06 2 2026-09-06 1
2026-08-03 4 2026-09-07 8
Attachments available on request
- Two
amdgpu devcoredumps (/sys/class/drm/card1/device/devcoredump/data), captured
under kernel 7.2.3 and under the June SteamVR build.
dmesg for each.
- Two
vrcompositor userspace coredumps with stack traces — one SIGSEGV, one SIGABRT
from ThreadWatchdog. Offsets only; the binary is stripped.
Representative userspace trace (SIGSEGV, main thread), with a second thread inside RADV:
Stack trace of thread 9558:
#0 0x0000559872bce6d6 (vrcompositor + 0x22f6d6)
#1 0x0000559872c09c66 (vrcompositor + 0x26ac66)
#2 0x0000559872c279b8 (vrcompositor + 0x2889b8)
#3 0x0000559872c27be8 (vrcompositor + 0x288be8)
#4 0x00007f17d4427781 (libc.so.6 + 0x27781)
#5 0x00007f17d44278b9 (libc.so.6 + 0x278b9)
#6 0x0000559872aebe1a (vrcompositor + 0x14ce1a)
Stack trace of thread 9583:
#0 0x00007f17d44a0952 (libc.so.6 + 0xa0952)
#1 0x00007f17d449754c (libc.so.6 + 0x9754c)
#2 0x00007f17ce59351e (libvulkan_radeon.so + 0x39351e)
#3 0x00007f17ce55cfad (libvulkan_radeon.so + 0x35cfad)
#4 0x00007f17ce59348d (libvulkan_radeon.so + 0x39348d)
#5 0x00007f17d44980a2 (libc.so.6 + 0x980a2)
#6 0x00007f17d452080c (libc.so.6 + 0x12080c)
vrcompositor RenderThread triggers recurring amdgpu GPU page faults (RDNA2 / RADV), often requiring a hard reset
This is a two day investigation of myself in co-op with Claude Opus 5.
Summary
On an RX 6800 XT with RADV,
vrcompositor'sRenderThreadrepeatedly triggers a GPUpage fault in a narrow, recurring VA range. The kernel usually fails to reset the graphics
ring afterwards and performs a full GPU reset, which kills the session and requires a
hard power cycle.
The behaviour is independent of Mesa version, kernel version, Proton version, the running
application, and the SteamVR version — all were varied, see the exclusion list below.
vrcompositoris the faulting process in every single occurrence.The problem is not new: systemd holds 41
vrcompositor/vrservercoredumps going backto 2026-07-30. Most compositor crashes are invisible to the user because SteamVR
restarts the compositor; it only becomes fatal when the crash coincides with a GPU hang.
System
1002:73bfrev c1kwin_wayland)6.18.49-ltsand7.2.3-arch126.1.6and26.2.2202608102.17.8(beta 2026-09-01) and the 2026-06-18 beta branchSymptom
The headset and both desktop monitors go black. The machine does not recover; a hard
reset is required. In a minority of cases the kernel manages
Ring reset succeededandthe session survives with visible rendering corruption.
Kernel log (representative)
The fault is always
client 0x1b (UTCL2),SQC (data),PERMISSION_FAULTS: 0x3— a shaderreading memory it is not permitted to touch. The ring timeout is subsequently attributed to
kwin_waylandbecause the compositor of the desktop is the next submitter to the hung ring.Observed faults
13 occurrences over two days. All in
vrcompositor/RenderThread.0x00000080013be0000x00000080013b30000x00000080013be0000x00000080013b30000x00000080013b30000x00000080013c50000x00000080013c50000x00000080013c50000x00000080013c50000x00000080013c50000x00000080013c50000x00000080013c50000x0000008001387000Every faulting address falls inside a ~250 KB window (
0x8001387000–0x80013c5000).The address is stable across many runs and shifts only when the SteamVR build changes.
Second failure mode
Once, with no application running at all — SteamVR had just been started — the display
pipeline hung instead:
followed by
vrcompositoraborting from its ownThreadWatchdog(SIGABRT). The systemsurvived. This confirms the fault is not tied to any particular application.
Ruled out
Each of the following was changed and the crash still reproduced:
One crash occurred with no application running at all.
1:26.1.6-1and1:26.2.2-1.6.18.49-ltsand7.2.3-arch1.2.17.8(2026-09-01 beta) and the 2026-06-18 beta branch.CAP_SYS_NICEpresent) and disabled(
Insufficient permission to create high priority queue). Crashes occur either way.Other VR titles (Beat Saber, Hellblade: Senua's Sacrifice VR) are playable, but the
coredump history shows
vrcompositorwas crashing during those sessions too — silently,because SteamVR restarts it.
Crash history
coredumpctlrecords forvrcompositor/vrserver, by day:Attachments available on request
amdgpudevcoredumps (/sys/class/drm/card1/device/devcoredump/data), capturedunder kernel 7.2.3 and under the June SteamVR build.
dmesgfor each.vrcompositoruserspace coredumps with stack traces — one SIGSEGV, one SIGABRTfrom
ThreadWatchdog. Offsets only; the binary is stripped.Representative userspace trace (SIGSEGV, main thread), with a second thread inside RADV: