MagicBeanDev/Hookshot

Archived

Watch

Fork 0

[Linux/AMD] GPU hang (ring timeout → MODE1 reset) on scene change, RX 6800 XT / RADV — buffer-marker logs attached #1275

Closed

opened 2026-11-09 20:11:30 +00:00 by Alexatre · 6 comments

Alexatre commented

2026-11-09 20:11:30 +00:00

(Migrated from github.com)

Hookshot version

v2.0.11

What kind of problem

Graphics (missing, black or wrong-coloured things, lighting, flicker)

What happened

Summary

On an RX 6800 XT with RADV, the GPU hangs on area transitions (leaving Link's house / first frames after a load).
amdgpu times out the ring after ~10 s, the ring reset fails and the kernel does a full MODE1 reset (VRAM lost).
The game then shows a black window and its RAM use keeps growing until it is closed.

System

Hookshot v2.0.11 (source 10f983ad), also seen on v2.0.9 and v2.0.10
GPU: AMD Radeon RX 6800 XT (RADV NAVI21), 16 GB
Driver: Mesa 26.2.6-arch1.1 (RADV), Vulkan 1.4
OS: Arch Linux, running under XWayland (same hang earlier under X11)
Game: built from my own dump, supported build, pt-BR

What happens

Title, intro movie and the first area run fine at ~60 fps.
On the first scene change / first gameplay frames after a load, one submission never completes:
slow submit: 10982.2 ms: ... slot wait 10705.2
radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.
then batched submit ... failed (-4) / device lost.
Kernel log (every hang is owned by hookshot):

ring gfx_0.0.0 timeout ... Process hookshot pid 32219 thread OptimizeChangeB
ring comp_1.2.0 timeout ... Process hookshot pid 32219 thread OptimizeChangeB
Ring comp_1.2.0 reset failed -> MODE1 reset -> VRAM is lost due to GPU reset!

Threads owning the hung job across 7 runs: OptimizeChangeB (x3), Presentation Th (x2), mkw_vk order, sead::MainThrea.
No page fault lines in the kernel log.

Buffer markers (RX_VK_CHECKPOINTS=1, VK_AMD_buffer_marker)

The point where the GPU stops differs between runs:

Run	Last marker whose earlier work finished	Next markers (not reached)
16:48 (markers only)	43008: write-back of pool 0x1020000000, frame 1946	draws of 722b5b774ea9f6f0, 8350cd652f2bd017
16:54 (RX_VK_WB_DIFF=0)	33325: draw of program d4c156cb4503b850, frame 1797	more d4c156cb..., then 5c1aa67aea93a84f
17:03 (RX_VK_BATCH=0)	32005: write-back of pool 0x100d000000, frame 1464	draws of a898ad0245e08c88, 41d0afa9907641f1

Possible lead (a guess, not verified): both write-back hangs are on small dma-buf pools created at boot,
and 0x100d000000 is the pool holding the NVN events (event 0x100d6c8000 in CommandBufferWait/SignalEvent).
If a write-back can land stale data over an event value a queue is waiting on, the wait would never be met,
which would fit a ~10 s hang whose exact position moves between runs.

Switches tried (hookshot_env.txt)

Switch	Result
RX_VK_SKIP_CODE=2c56dc1006942f74	Still hangs (the culling draws were left out, confirmed in the log)
RX_VK_WB_DIFF=0	Still hangs, at a draw instead of a write-back
RX_VK_BATCH=0	Still hangs (`batched submits off` confirmed)
RX_VK_NO_DMABUF=1	Not usable: host-pointer import refused (`not imported (VkResult -1000072003)`), 0 draws, black picture

Second issue: memory grows after the device is lost

After device lost the replay keeps running and nothing is retired:
captures kept goes from 25 to 2948 (and 6527 in another run), and staging from 256 MB in 4 arenas to 1408 MB in 22 arenas.
System RAM fills up until the window is closed. Exiting (or at least stopping the replay) on device loss would avoid this.

Attached

hookshot_log.txt of the 16:48, 16:54 and 17:03 runs (buffer markers on)
the journalctl ring-timeout excerpt above

Possibly related: #708, #614 (device lost on RX 6600), #604, #528 (Linux AMD).

hookshot_log.txt

Where in the game

Link's House, after load save

How often

Every time

Graphics card and driver version

6X6800XT

CPU, RAM and operating system

R7 5700X3D, 64GB RAM, Arch Linux

Changes from the defaults

No response

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

Screenshots or video

No response

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version v2.0.11 ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened ### Summary On an RX 6800 XT with RADV, the GPU hangs on area transitions (leaving Link's house / first frames after a load). amdgpu times out the ring after ~10 s, the ring reset fails and the kernel does a full MODE1 reset (VRAM lost). The game then shows a black window and its RAM use keeps growing until it is closed. ### System - Hookshot v2.0.11 (source 10f983ad), also seen on v2.0.9 and v2.0.10 - GPU: AMD Radeon RX 6800 XT (RADV NAVI21), 16 GB - Driver: Mesa 26.2.6-arch1.1 (RADV), Vulkan 1.4 - OS: Arch Linux, running under XWayland (same hang earlier under X11) - Game: built from my own dump, supported build, pt-BR ### What happens 1. Title, intro movie and the first area run fine at ~60 fps. 2. On the first scene change / first gameplay frames after a load, one submission never completes: `slow submit: 10982.2 ms: ... slot wait 10705.2` 3. `radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.` then `batched submit ... failed (-4)` / `device lost`. 4. Kernel log (every hang is owned by hookshot): ring gfx_0.0.0 timeout ... Process hookshot pid 32219 thread OptimizeChangeB ring comp_1.2.0 timeout ... Process hookshot pid 32219 thread OptimizeChangeB Ring comp_1.2.0 reset failed -> MODE1 reset -> VRAM is lost due to GPU reset! Threads owning the hung job across 7 runs: OptimizeChangeB (x3), Presentation Th (x2), mkw_vk order, sead::MainThrea. No `page fault` lines in the kernel log. ### Buffer markers (RX_VK_CHECKPOINTS=1, VK_AMD_buffer_marker) The point where the GPU stops differs between runs: | Run | Last marker whose earlier work finished | Next markers (not reached) | |---|---|---| | 16:48 (markers only) | 43008: write-back of pool 0x1020000000, frame 1946 | draws of 722b5b774ea9f6f0, 8350cd652f2bd017 | | 16:54 (RX_VK_WB_DIFF=0) | 33325: draw of program d4c156cb4503b850, frame 1797 | more d4c156cb..., then 5c1aa67aea93a84f | | 17:03 (RX_VK_BATCH=0) | 32005: write-back of pool 0x100d000000, frame 1464 | draws of a898ad0245e08c88, 41d0afa9907641f1 | Possible lead (a guess, not verified): both write-back hangs are on small dma-buf pools created at boot, and 0x100d000000 is the pool holding the NVN events (`event 0x100d6c8000` in CommandBufferWait/SignalEvent). If a write-back can land stale data over an event value a queue is waiting on, the wait would never be met, which would fit a ~10 s hang whose exact position moves between runs. ### Switches tried (hookshot_env.txt) | Switch | Result | |---|---| | RX_VK_SKIP_CODE=2c56dc1006942f74 | Still hangs (the culling draws were left out, confirmed in the log) | | RX_VK_WB_DIFF=0 | Still hangs, at a draw instead of a write-back | | RX_VK_BATCH=0 | Still hangs (`batched submits off` confirmed) | | RX_VK_NO_DMABUF=1 | Not usable: host-pointer import refused (`not imported (VkResult -1000072003)`), 0 draws, black picture | ### Second issue: memory grows after the device is lost After `device lost` the replay keeps running and nothing is retired: `captures kept` goes from 25 to 2948 (and 6527 in another run), and staging from 256 MB in 4 arenas to 1408 MB in 22 arenas. System RAM fills up until the window is closed. Exiting (or at least stopping the replay) on device loss would avoid this. ### Attached - hookshot_log.txt of the 16:48, 16:54 and 17:03 runs (buffer markers on) - the journalctl ring-timeout excerpt above Possibly related: #708, #614 (device lost on RX 6600), #604, #528 (Linux AMD). [hookshot_log.txt](https://github.com/user-attachments/files/34597871/hookshot_log.txt) ### Where in the game Link's House, after load save ### How often Every time ### Graphics card and driver version 6X6800XT ### CPU, RAM and operating system R7 5700X3D, 64GB RAM, Arch Linux ### Changes from the defaults _No response_ ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.txt](https://github.com/user-attachments/files/34598028/hookshot_log.txt) ### Screenshots or video _No response_ ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

NotRexed commented

2026-11-09 20:18:16 +00:00

(Migrated from github.com)

Thanks for the buffer-marker logs. Linking this to the Linux tracker #1000, with the same RADV ring timeout and MODE1 reset as #1065 and #1227.

NotRexed commented

2026-11-10 01:59:49 +00:00

(Migrated from github.com)

Fixed in the v2.0.12 branch, closing when it ships. After a device lost the game now ends cleanly instead of showing a black window while its RAM keeps growing. The RADV hang itself is still being looked at.

naxil commented

2026-11-10 07:29:45 +00:00

(Migrated from github.com)

Thanks for the buffer-marker logs. Linking this to the Linux tracker #1000, with the same RADV ring timeout and MODE1 reset as #1065 and #1227.

Sorry, I'm writing to you here. But where can I find all the values that can be given in env.txt?

> Thanks for the buffer-marker logs. Linking this to the Linux tracker #1000, with the same RADV ring timeout and MODE1 reset as #1065 and #1227. Sorry, I'm writing to you here. But where can I find all the values that can be given in env.txt?

NotRexed commented

2026-11-10 07:46:25 +00:00

(Migrated from github.com)

The hookshot_env.txt switches are listed in the development guide, under "Switches for testing and debugging": https://git.magicbean.dev/MagicBeanDev/Hookshot/src/branch/main/docs/development.md#switches-for-testing-and-debugging (one NAME=VALUE a line, beside image.bin).

The `hookshot_env.txt` switches are listed in the development guide, under "Switches for testing and debugging": https://git.magicbean.dev/MagicBeanDev/Hookshot/src/branch/main/docs/development.md#switches-for-testing-and-debugging (one `NAME=VALUE` a line, beside `image.bin`).

Fortich commented

2026-11-11 18:47:07 +00:00

(Migrated from github.com)

Same GPU (RX 6800 XT / NAVI21, RADV). Here the ring timeout and the MODE1 reset stop with RX_VK_FORCE_MESH_FALLBACK=1: the run that died at 4 min 34 s now holds 60 fps past that point. Full details in #2245

NotRexed commented

2026-11-11 21:22:21 +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.