GPU hang (ring gfx timeout, reset fails) freezes the whole system on RX 6700 / RADV (OoT and MKW) #2321

Closed

opened 2026-11-11 14:59:04 +00:00 by RoiSoleil · 4 comments

RoiSoleil commented

2026-11-11 14:59:04 +00:00

(Migrated from github.com)

Hookshot: v2.1.0, Linux AppImage (Hookshot-v2.1.0-x86_64.AppImage)
Games: The Legend of Zelda: Ocarina of Time (0400486024dec000, v131072), Mario Kart World
System:

GPU: AMD Radeon RX 6700 10 GB (NAVI22), Resizable BAR on (16 GB BAR)
Driver: RADV, Mesa 26.0.8-1ubuntu0.3, Vulkan 1.4.335
Kernel: Linux 7.0.0-43-generic (Ubuntu), Wayland (GNOME)
CPU: Ryzen 5 5600G, 16 GB RAM

What happens: after a few minutes of play (in OoT twice at the end of the opening cutscene, once in the field), the screen goes black and the whole PC freezes; only a hard reset brings it back. The kernel log shows a GPU hang that the driver cannot recover from:

nov. 11 15:33:00 amdgpu 0000:03:00.0: [drm] AMDGPU device coredump file has been created
nov. 11 15:33:00 amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=49702, emitted seq=49704
nov. 11 15:33:00 amdgpu 0000:03:00.0:  Process hookshot pid 6068 thread mkw_vk display pid 7796
nov. 11 15:33:00 amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed
nov. 11 15:33:04 amdgpu 0000:03:00.0: GPU mode1 reset

The same with Mario Kart World, another thread:

nov. 10 00:11:19 amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=8085016, emitted seq=8085019
nov. 10 00:11:19 amdgpu 0000:03:00.0:  Process hookshot pid 27813 thread sead::MainThrea pid 27823
nov. 10 00:11:19 amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed
nov. 10 00:11:29 amdgpu 0000:03:00.0: GPU mode1 reset failed
nov. 10 00:11:29 amdgpu 0000:03:00.0: ASIC reset failed with error, -62 for drm dev, 0000:03:00.0

No VM page fault is reported before the timeouts. The GPU was not under stress when it hung (about 40 % busy, 43 °C, 19 W, 1.7-4.9 GB of VRAM used, 5 GB of RAM free). No other application hangs this GPU.

Settings tried, each one hung:

default options (frame_generation=2, upscaling=1, robust_buffers=0)
robust_buffers=1
robust_buffers=1 and frame_generation=0
launched directly (./bin/hookshot) and with gamemoderun

Last lines of the game log before the 15:21 hang, at the end of the opening cutscene (it was loading the textures of the next scene):

[hos Presentation Thread] vk: slow submit: 87.5 ms: draw 63.2 descriptors 45.9 texture lookups 65.1 uploads 63.4 programs 16.2 dispatch 3.1
[hos Presentation Thread] vk: a frame's uploads took 240 ms: ASTC on the GPU 9 (5.7 MB, 53 ms); unswizzled on the GPU 3 (39.0 MB, 33 ms); on the CPU 179 (208.2 MB, 154 ms)
[hos Presentation Thread] vk: 107 new ASTC textures left for a later frame (this frame's uploads took their budget; 107 so far)

The full hookshot_log.txt (420 KB) is available on request. The devcoredump was lost with the reset; I can try to capture /sys/class/drm/card1/device/devcoredump/data on the next hang if it helps.

This report was put together with an AI assistant (Claude Code) from my kernel and game logs.

**Hookshot:** v2.1.0, Linux AppImage (`Hookshot-v2.1.0-x86_64.AppImage`) **Games:** The Legend of Zelda: Ocarina of Time (0400486024dec000, v131072), Mario Kart World **System:** - GPU: AMD Radeon RX 6700 10 GB (NAVI22), Resizable BAR on (16 GB BAR) - Driver: RADV, Mesa 26.0.8-1ubuntu0.3, Vulkan 1.4.335 - Kernel: Linux 7.0.0-43-generic (Ubuntu), Wayland (GNOME) - CPU: Ryzen 5 5600G, 16 GB RAM **What happens:** after a few minutes of play (in OoT twice at the end of the opening cutscene, once in the field), the screen goes black and the whole PC freezes; only a hard reset brings it back. The kernel log shows a GPU hang that the driver cannot recover from: ``` nov. 11 15:33:00 amdgpu 0000:03:00.0: [drm] AMDGPU device coredump file has been created nov. 11 15:33:00 amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=49702, emitted seq=49704 nov. 11 15:33:00 amdgpu 0000:03:00.0: Process hookshot pid 6068 thread mkw_vk display pid 7796 nov. 11 15:33:00 amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed nov. 11 15:33:04 amdgpu 0000:03:00.0: GPU mode1 reset ``` The same with Mario Kart World, another thread: ``` nov. 10 00:11:19 amdgpu 0000:03:00.0: ring gfx_0.0.0 timeout, signaled seq=8085016, emitted seq=8085019 nov. 10 00:11:19 amdgpu 0000:03:00.0: Process hookshot pid 27813 thread sead::MainThrea pid 27823 nov. 10 00:11:19 amdgpu 0000:03:00.0: Ring gfx_0.0.0 reset failed nov. 10 00:11:29 amdgpu 0000:03:00.0: GPU mode1 reset failed nov. 10 00:11:29 amdgpu 0000:03:00.0: ASIC reset failed with error, -62 for drm dev, 0000:03:00.0 ``` No VM page fault is reported before the timeouts. The GPU was not under stress when it hung (about 40 % busy, 43 °C, 19 W, 1.7-4.9 GB of VRAM used, 5 GB of RAM free). No other application hangs this GPU. **Settings tried, each one hung:** - default options (`frame_generation=2`, `upscaling=1`, `robust_buffers=0`) - `robust_buffers=1` - `robust_buffers=1` and `frame_generation=0` - launched directly (`./bin/hookshot`) and with `gamemoderun` **Last lines of the game log before the 15:21 hang**, at the end of the opening cutscene (it was loading the textures of the next scene): ``` [hos Presentation Thread] vk: slow submit: 87.5 ms: draw 63.2 descriptors 45.9 texture lookups 65.1 uploads 63.4 programs 16.2 dispatch 3.1 [hos Presentation Thread] vk: a frame's uploads took 240 ms: ASTC on the GPU 9 (5.7 MB, 53 ms); unswizzled on the GPU 3 (39.0 MB, 33 ms); on the CPU 179 (208.2 MB, 154 ms) [hos Presentation Thread] vk: 107 new ASTC textures left for a later frame (this frame's uploads took their budget; 107 so far) ``` The full `hookshot_log.txt` (420 KB) is available on request. The devcoredump was lost with the reset; I can try to capture `/sys/class/drm/card1/device/devcoredump/data` on the next hang if it helps. _This report was put together with an AI assistant (Claude Code) from my kernel and game logs._

kaizokuu1 commented

2026-11-11 15:17:33 +00:00

(Migrated from github.com)

i have the same issue on windows 11 with hookshot v2.1.0
System:

GPU: AMD Radeon RX 6800XT 16 Go
CPU: AMD ryzen 5600x 6 core processor
Ram : 16 Go DDR4

i have the same issue on windows 11 with hookshot v2.1.0 System: - GPU: AMD Radeon RX 6800XT 16 Go - CPU: AMD ryzen 5600x 6 core processor - Ram : 16 Go DDR4

bunbeans2-arch commented

2026-11-11 17:11:13 +00:00

(Migrated from github.com)

A Windows data point that may or may not be the same thing: RX 9070 XT 16 GB, 32 GB RAM, Windows 11, v2.1.0 built from source. One whole-PC freeze so far (hard reset needed).

When: right after the window went windowed -> fullscreen and Frame generation was set to 8x from the menu and, by the user's account, Frame pacing was being switched to Off (the log does not show that last change). The game log has display: windowed, display: fullscreen, frame interpolation ready: 8x the game's frames, then 64 more ordinary lines (a status: 600 frames line among them) and stops. No device lost line anywhere in it.
What Windows kept: only Kernel-Power 41 at the next boot. No Display event 4101 ("display driver stopped responding and has successfully recovered") and no LiveKernelEvent report for that night. This PC has logged both kinds before with other software (4101: 32 times since last December; LiveKernelEvent: 41 reports in the last 30 days, codes 141 and 117 among them), so the logging works here; their absence that night says there was no RECOVERED driver hang. A hang the driver could not recover from would leave the same nothing, and so would anything else that stops the PC dead.
Why it may be something else here: that start had built the shader programs in the same process and was at 33.3 GB of private bytes on a 32 GB PC (numbers in #2180), so running out of commit is a second candidate for us. What the PC left behind does not tell the two apart.
Not reproduced: replays of the same steps under a watchdog, one of them from a start that built the shader programs first, did not freeze.
Unlike the report above, ours was standing still, not at a scene load, and frame generation had just been raised.

For the Windows report above, the same two places would show whether the driver tried to recover: Event Viewer, Windows Logs, System, sources Display and Kernel-Power around the time of the freeze.

A Windows data point that may or may not be the same thing: RX 9070 XT 16 GB, 32 GB RAM, Windows 11, v2.1.0 built from source. One whole-PC freeze so far (hard reset needed). - When: right after the window went windowed -> fullscreen and Frame generation was set to 8x from the menu and, by the user's account, Frame pacing was being switched to Off (the log does not show that last change). The game log has `display: windowed`, `display: fullscreen`, `frame interpolation ready: 8x the game's frames`, then 64 more ordinary lines (a `status: 600 frames` line among them) and stops. No device lost line anywhere in it. - What Windows kept: only Kernel-Power 41 at the next boot. No `Display` event 4101 ("display driver stopped responding and has successfully recovered") and no LiveKernelEvent report for that night. This PC has logged both kinds before with other software (4101: 32 times since last December; LiveKernelEvent: 41 reports in the last 30 days, codes 141 and 117 among them), so the logging works here; their absence that night says there was no RECOVERED driver hang. A hang the driver could not recover from would leave the same nothing, and so would anything else that stops the PC dead. - Why it may be something else here: that start had built the shader programs in the same process and was at 33.3 GB of private bytes on a 32 GB PC (numbers in #2180), so running out of commit is a second candidate for us. What the PC left behind does not tell the two apart. - Not reproduced: replays of the same steps under a watchdog, one of them from a start that built the shader programs first, did not freeze. - Unlike the report above, ours was standing still, not at a scene load, and frame generation had just been raised. For the Windows report above, the same two places would show whether the driver tried to recover: Event Viewer, Windows Logs, System, sources `Display` and `Kernel-Power` around the time of the freeze.

bunbeans2-arch commented

2026-11-11 17:33:56 +00:00

(Migrated from github.com)

So the state the PC froze in was Ultra + 8x + pacing On at 3840x2160, in Castle Town, 45 log lines after that reading. Our replays so far all pressed the pacing row as well, which puts the preset back to Custom and the budget back to 6144 MB, so they did not test that state. On the normal budget, walking between two areas takes this card to 13.0-13.6 GB of the 14.6 GB the driver then allows (about 3 GB of it free space inside the blocks), with 8x adding about 0.8 GB; our guard ends those runs at 91 %. Whether running out of VRAM is what stopped the PC is not shown.

A correction to my comment above, from the user himself: Frame pacing was On and he was not changing it. What he did was pick the Ultra preset, go windowed and back to fullscreen, and set Frame generation to 8x; nothing else. That agrees with the log, whose last VRAM line (after the 8x line) still shows Ultra's texture budget: `VRAM: 10953 MB used of 15450 MB allowed ...; textures 5012 MB (budget 11000 MB)`. So the state the PC froze in was Ultra + 8x + pacing On at 3840x2160, in Castle Town, 45 log lines after that reading. Our replays so far all pressed the pacing row as well, which puts the preset back to Custom and the budget back to 6144 MB, so they did not test that state. On the normal budget, walking between two areas takes this card to 13.0-13.6 GB of the 14.6 GB the driver then allows (about 3 GB of it free space inside the blocks), with 8x adding about 0.8 GB; our guard ends those runs at 91 %. Whether running out of VRAM is what stopped the PC is not shown.

NotRexed commented

2026-11-11 21:28:53 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #1000, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #1000 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.

Commenting is not possible because the repository is archived.