Linux AMD (RADV): VK_ERROR_DEVICE_LOST after the opening cutscene and before the Great Deku Tree appears (RX 6600 XT)

ouni666 commented

2026-11-11 10:54:25 +00:00

(Migrated from github.com)

Hookshot version

v2.1.0

What kind of problem

Crash, freeze or black screen

What happened

Subtitle
Reproducible GPU reset/device loss at a specific scene transition on Linux + AMD RADV; occurs after the opening cutscene and before the Great Deku Tree appears.

Description
Summary

On Linux with an AMD GPU using the RADV driver, the application (v2.1.0, a decompiled/recompiled project, not an emulator) crashes after the Vulkan device is lost with VK_ERROR_DEVICE_LOST. Immediately before the device loss, the log shows a GPU sync wait of about 2580 ms, several very slow memory-sync submissions, capture write-back timeouts, and heavy texture re-upload activity. The RADV/amdgpu driver then reports that the command stream was cancelled because the context was lost.

Timing / reproducibility

The GPU reset / device loss occurs consistently after the opening cutscene and before the Great Deku Tree appears. This suggests the crash may be triggered by a particular texture upload, memory-sync, or shader/resource burst during that scene transition rather than by random load.

Environment

OS: Linux (please fill in distro and kernel version)

CPU: AMD Ryzen 7 7840HS

GPU: AMD Radeon RX 6600 XT (8 GB VRAM)

RAM: 32 GB

GPU Driver: RADV/Mesa (please fill in version), amdgpu kernel driver

Application: Decompiled/recompiled project, version v2.1.0

API: Vulkan

Steps to reproduce

Launch the application (v2.1.0) with the Vulkan backend on Linux + AMD RADV using an RX 6600 XT.

Start a new game and let the opening cutscene play.

Continue until the scene transitions to the point where the Great Deku Tree is about to appear.

At this point, the application stalls, the GPU is reset, and the application closes.

The following fatal error appears in the log:

text
vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more
radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.
vk: batched submit 32875 failed (-4)
vk: device lost: reading the fault info
Expected behavior

The application should continue rendering without losing the Vulkan device.

Actual behavior

The GPU device is lost, Vulkan submissions fail with -4 (VK_ERROR_DEVICE_LOST), and the application closes.

Relevant log evidence

Immediately before the device loss:

text
[hos sead::MainThread] nvn: GPU waits in 5 s: 1 sync waits (2580 ms), 0 polls timed out (0 ms), 0 queue finishes (0 ms)
Multiple slow memory-sync submissions:

text
[hos sead::MainThread] vk: slow submit: 176.4 ms: memory sync 176.3
[hos sead::MainThread] vk: slow submit: 252.8 ms: memory sync 252.8
[hos sead::MainThread] vk: slow submit: 258.4 ms: memory sync 258.2
[hos sead::MainThread] vk: slow submit: 251.7 ms: memory sync 251.6
Capture write-back waits timing out:

text
[hos sead::MainThread] vk: a capture's wait for write-back 156638 timed out (done 156634)
[hos sead::MainThread] vk: a capture's wait for write-back 156645 timed out (done 156641)
[hos sead::MainThread] vk: a capture's wait for write-back 156652 timed out (done 156641)
Textures re-uploaded because the GPU wrote to their storage:

text
[hos host] vk: texture 0x10003200e00 2048x1152x1 x1 levels 1 NVN 0x25 (9216 KB of storage) re-uploaded (its memory was written; flags 0x8)
[hos host] vk: texture 0x100030a1a00 1600x1600x1 x3 levels 1 NVN 0x32 (15600 KB of storage) re-uploaded (its memory was written; flags 0x8)
Then the device is lost:

text
radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.
[hos ModuleSystemWorker1] vk: batched submit 32875 failed (-4)
[hos ModuleSystemWorker1] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST)
Additional information

The crash occurs after a GPU sync wait of ~2580 ms. On some kernels the amdgpu lockup_timeout default may be shorter than this, causing the kernel to reset the GPU before the submission completes.

The log shows heavy texture re-upload activity caused by GPU writes into texture storage, which can amplify memory-sync pressure.

Where in the game

occurs after the opening cutscene and before the Great Deku Tree appears.

How often

Every time

Graphics card and driver version

AMD Radeon RX 6600 XT (8 GB VRAM) mesa:26.2.6

CPU, RAM and operating system

AMD Ryzen 7 7840HS ，32G，LINUX:AOSC OS

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.1.0 ### What kind of problem Crash, freeze or black screen ### What happened Subtitle Reproducible GPU reset/device loss at a specific scene transition on Linux + AMD RADV; occurs after the opening cutscene and before the Great Deku Tree appears. Description Summary On Linux with an AMD GPU using the RADV driver, the application (v2.1.0, a decompiled/recompiled project, not an emulator) crashes after the Vulkan device is lost with VK_ERROR_DEVICE_LOST. Immediately before the device loss, the log shows a GPU sync wait of about 2580 ms, several very slow memory-sync submissions, capture write-back timeouts, and heavy texture re-upload activity. The RADV/amdgpu driver then reports that the command stream was cancelled because the context was lost. Timing / reproducibility The GPU reset / device loss occurs consistently after the opening cutscene and before the Great Deku Tree appears. This suggests the crash may be triggered by a particular texture upload, memory-sync, or shader/resource burst during that scene transition rather than by random load. Environment OS: Linux (please fill in distro and kernel version) CPU: AMD Ryzen 7 7840HS GPU: AMD Radeon RX 6600 XT (8 GB VRAM) RAM: 32 GB GPU Driver: RADV/Mesa (please fill in version), amdgpu kernel driver Application: Decompiled/recompiled project, version v2.1.0 API: Vulkan Steps to reproduce Launch the application (v2.1.0) with the Vulkan backend on Linux + AMD RADV using an RX 6600 XT. Start a new game and let the opening cutscene play. Continue until the scene transitions to the point where the Great Deku Tree is about to appear. At this point, the application stalls, the GPU is reset, and the application closes. The following fatal error appears in the log: text vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST): the driver stopped or reset the GPU, and nothing sent to it runs any more radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent. vk: batched submit 32875 failed (-4) vk: device lost: reading the fault info Expected behavior The application should continue rendering without losing the Vulkan device. Actual behavior The GPU device is lost, Vulkan submissions fail with -4 (VK_ERROR_DEVICE_LOST), and the application closes. Relevant log evidence Immediately before the device loss: text [hos sead::MainThread] nvn: GPU waits in 5 s: 1 sync waits (2580 ms), 0 polls timed out (0 ms), 0 queue finishes (0 ms) Multiple slow memory-sync submissions: text [hos sead::MainThread] vk: slow submit: 176.4 ms: memory sync 176.3 [hos sead::MainThread] vk: slow submit: 252.8 ms: memory sync 252.8 [hos sead::MainThread] vk: slow submit: 258.4 ms: memory sync 258.2 [hos sead::MainThread] vk: slow submit: 251.7 ms: memory sync 251.6 Capture write-back waits timing out: text [hos sead::MainThread] vk: a capture's wait for write-back 156638 timed out (done 156634) [hos sead::MainThread] vk: a capture's wait for write-back 156645 timed out (done 156641) [hos sead::MainThread] vk: a capture's wait for write-back 156652 timed out (done 156641) Textures re-uploaded because the GPU wrote to their storage: text [hos host] vk: texture 0x10003200e00 2048x1152x1 x1 levels 1 NVN 0x25 (9216 KB of storage) re-uploaded (its memory was written; flags 0x8) [hos host] vk: texture 0x100030a1a00 1600x1600x1 x3 levels 1 NVN 0x32 (15600 KB of storage) re-uploaded (its memory was written; flags 0x8) Then the device is lost: text radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent. [hos ModuleSystemWorker1] vk: batched submit 32875 failed (-4) [hos ModuleSystemWorker1] vk: FATAL: the GPU device was lost (VK_ERROR_DEVICE_LOST) Additional information The crash occurs after a GPU sync wait of ~2580 ms. On some kernels the amdgpu lockup_timeout default may be shorter than this, causing the kernel to reset the GPU before the submission completes. The log shows heavy texture re-upload activity caused by GPU writes into texture storage, which can amplify memory-sync pressure. ### Where in the game occurs after the opening cutscene and before the Great Deku Tree appears. ### How often Every time ### Graphics card and driver version AMD Radeon RX 6600 XT (8 GB VRAM) mesa:26.2.6 ### CPU, RAM and operating system AMD Ryzen 7 7840HS ，32G，LINUX:AOSC OS ### 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/34683970/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.

dupereira1978 commented

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

(Migrated from github.com)

The same happens on my Steam Deck Oled!

👍 2

ouni666 commented

2026-11-11 11:13:35 +00:00

(Migrated from github.com)

Just before the crash, the log reveals a critical resource binding error (an unbound storage buffer) in a specific shader program:

[hos host] vk: storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20

Root Cause Analysis (Unbound Storage Buffer)

Based on the logs, the GPU hang is not caused by memory exhaustion (VRAM usage is only ~1.3 GB of 7.6 GB). Instead, it is caused by a fatal resource binding issue that triggers a hardware/driver deadlock.

Immediately before the crash, the engine attempts to dispatch a graphics/compute program (program da7a7ab28b8e73d9) that accesses a storage buffer (SSBO) at address 0x4180000000000200 which is NOT bound.

Because the buffer is unbound, the system falls back to reading zeros. If the shader relies on this buffer's data for loop conditions or calculations, this undefined behavior can lead to an infinite loop on the GPU. On the RADV driver, this infinite loop triggers the amdgpu kernel watchdog, which eventually resets the GPU and causes the VK_ERROR_DEVICE_LOST.

This specific error occurs exactly at the scene transition before the Great Deku Tree appears. Fixing the resource binding for this shader program or correcting the data passed to this SSBO should resolve the device loss.

``` Just before the crash, the log reveals a critical resource binding error (an unbound storage buffer) in a specific shader program: [hos host] vk: storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20 ``` **Root Cause Analysis (Unbound Storage Buffer)** Based on the logs, the GPU hang is not caused by memory exhaustion (VRAM usage is only ~1.3 GB of 7.6 GB). Instead, it is caused by a fatal resource binding issue that triggers a hardware/driver deadlock. Immediately before the crash, the engine attempts to dispatch a graphics/compute program (program `da7a7ab28b8e73d9`) that accesses a storage buffer (SSBO) at address `0x4180000000000200` which is **NOT bound**. Because the buffer is unbound, the system falls back to reading zeros. If the shader relies on this buffer's data for loop conditions or calculations, this undefined behavior can lead to an infinite loop on the GPU. On the RADV driver, this infinite loop triggers the amdgpu kernel watchdog, which eventually resets the GPU and causes the `VK_ERROR_DEVICE_LOST`. This specific error occurs exactly at the scene transition before the Great Deku Tree appears. Fixing the resource binding for this shader program or correcting the data passed to this SSBO should resolve the device loss.

DaFlavours commented

2026-11-11 11:31:05 +00:00

(Migrated from github.com)

similar issue with my Rog Xbox Ally X

16gb RAM
8gb VRAM
APU 35W (turbo)

hookshot_log.txt

similar issue with my Rog Xbox Ally X 16gb RAM 8gb VRAM APU 35W (turbo) [hookshot_log.txt](https://github.com/user-attachments/files/34685387/hookshot_log.txt)

DuxMuxxy commented

2026-11-11 12:44:29 +00:00

(Migrated from github.com)

Same crash here on Linux (CachyOS, kernel 7.3.3): RX 6800 (Navi 21), Mesa 26.2.6 RADV, stock clocks.
VK_ERROR_DEVICE_LOST after the opening cutscene, then an amdgpu ring timeout and GPU reset.

Workaround: set the Mesh shaders option to Compute (mesh_shaders=2 in hookshot_options.ini). With that, I get no crash at all. It's a workaround, not a fix: Native still crashes, and Compute costs some performance.

In-game tests:

Default (Mesh shaders = Automatic, which is native on Linux): ❌ crash. gfx ring timeout, MODE1 reset.
mesh_shaders=2 (Compute: task and mesh programs both on the compute fallback): ✅ no crash.
RX_VK_TASK_MESH_FALLBACK=1 (only task + mesh draws on the fallback): ❌ crash.
RX_VK_MESH_NOCULL=… (the #817 Steam Deck workaround): ❌ crash.
RX_VK_CHECKPOINTS=1: ❌ crash. Last marker RUNNING after a memory write-back.
- with RX_VK_WB_DIFF=0: ❌ crash. Last marker on a draw program, so the WB diff is ruled out.
- with RX_VK_SKIP_PROG= set to the two programs from the markers: ❌ crash. Last marker moves to a texture upload, so those programs were victims, not the cause.

amdgpu devcoredumps (no VM page fault in either):

Native: no waves running, with the gfx ring and RADV's gang compute ring stuck waiting on each other. That looks like a deadlock between task and mesh.
RX_VK_TASK_MESH_FALLBACK=1: waves running on gfx and the compute queue empty, so a mesh-only draw that never finishes.

Conclusions:

It's not one specific shader (the checkpoint culprit changes from run to run), not the WB diff, not the #817 culling issue, not a VM fault and not an overclock.
RADV's native mesh path hangs on Navi 21, both for task + mesh and for mesh-only draws. Only the full Compute mode is stable.
The existing Navi 21/22 default (#1747, #1992) is _WIN32-only and only moves task + mesh draws to the fallback. Doing the same on Linux wouldn't be enough (test 3).
The root cause can be in RADV, or in how the game's mesh pipelines run on it.

Same crash here on Linux (CachyOS, kernel 7.3.3): RX 6800 (Navi 21), Mesa 26.2.6 RADV, stock clocks. VK_ERROR_DEVICE_LOST after the opening cutscene, then an amdgpu ring timeout and GPU reset. Workaround: set the Mesh shaders option to Compute (mesh_shaders=2 in hookshot_options.ini). With that, I get no crash at all. It's a workaround, not a fix: Native still crashes, and Compute costs some performance. In-game tests: 1. Default (Mesh shaders = Automatic, which is native on Linux): ❌ crash. gfx ring timeout, MODE1 reset. 2. mesh_shaders=2 (Compute: task and mesh programs both on the compute fallback): ✅ no crash. 3. RX_VK_TASK_MESH_FALLBACK=1 (only task + mesh draws on the fallback): ❌ crash. 4. RX_VK_MESH_NOCULL=… (the #817 Steam Deck workaround): ❌ crash. 5. RX_VK_CHECKPOINTS=1: ❌ crash. Last marker RUNNING after a memory write-back. - with RX_VK_WB_DIFF=0: ❌ crash. Last marker on a draw program, so the WB diff is ruled out. - with RX_VK_SKIP_PROG= set to the two programs from the markers: ❌ crash. Last marker moves to a texture upload, so those programs were victims, not the cause. amdgpu devcoredumps (no VM page fault in either): - Native: no waves running, with the gfx ring and RADV's gang compute ring stuck waiting on each other. That looks like a deadlock between task and mesh. - RX_VK_TASK_MESH_FALLBACK=1: waves running on gfx and the compute queue empty, so a mesh-only draw that never finishes. Conclusions: - It's not one specific shader (the checkpoint culprit changes from run to run), not the WB diff, not the #817 culling issue, not a VM fault and not an overclock. - RADV's native mesh path hangs on Navi 21, both for task + mesh and for mesh-only draws. Only the full Compute mode is stable. - The existing Navi 21/22 default (#1747, #1992) is _WIN32-only and only moves task + mesh draws to the fallback. Doing the same on Linux wouldn't be enough (test 3). - The root cause can be in RADV, or in how the game's mesh pipelines run on it.

Fortich commented

2026-11-11 18:46:25 +00:00

(Migrated from github.com)

RX 6800 XT (RADV, Linux): the device loss after the opening cutscene is gone with mesh shaders off

Hardware and versions: RX 6800 XT (RADV NAVI21), Vulkan 1.4, Mesa 25.0.7, kernel 7.0.0-42-generic, running inside a container (games-on-whales), build v2.0.11-871-g9447e1d from main. The dump is my own, supported build.

Before. Title and the whole opening movie ran at 60.0 fps (AV1 1920x1080, 2 draws a frame). Then the fps series went 60.0 for about 78 reports, 10.6, 15.6, and:

radv/amdgpu: The CS has been cancelled because the context is lost
batched submit 11917 failed (-4) → VK_ERROR_DEVICE_LOST
kernel, 83 s before the ring timeout: WARNING: refcount_t: underflow; use-after-free with amdgpu_job_free → amdgpu_cs_parser_fini → amdgpu_cs_ioctl, on a thread of the game
then ring gfx_0.0.0 timeout, signaled seq=87513, emitted seq=87515, Ring gfx_0.0.0 reset failed, GPU reset begin!. Source: 1, VRAM is lost due to GPU reset!, device wedged, but recovered through reset

Start to device lost: 4 min 34 s.

After RX_VK_FORCE_MESH_FALLBACK=1 in hookshot_env.txt:

vk: no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback)
vk: AMD Radeon RX 6800 XT (RADV NAVI21) ... mesh shaders no, host memory import yes
the session passed the same point and held 60.0 fps for about 7 minutes, no device lost.

Later in that run it became CPU-bound in a dense scene (1,100–1,600 draws: GPU 10.3 ms a frame, queue submit ~34 ms). That part was ours, not the port: the container had no /dev/udmabuf, so it logged guest memory stays host-pointer imports for the GPU (slow submissions on AMD). With the device exposed the same build reports guest memory as dma-bufs: yes.

So this matches #2245 and the fix in #2362. I can attach the full run log and the kernel block.

RX 6800 XT (RADV, Linux): the device loss after the opening cutscene is gone with mesh shaders off Hardware and versions: RX 6800 XT (RADV NAVI21), Vulkan 1.4, Mesa 25.0.7, kernel 7.0.0-42-generic, running inside a container (games-on-whales), build v2.0.11-871-g9447e1d from main. The dump is my own, supported build. Before. Title and the whole opening movie ran at 60.0 fps (AV1 1920x1080, 2 draws a frame). Then the fps series went 60.0 for about 78 reports, 10.6, 15.6, and: radv/amdgpu: The CS has been cancelled because the context is lost batched submit 11917 failed (-4) → VK_ERROR_DEVICE_LOST kernel, 83 s before the ring timeout: WARNING: refcount_t: underflow; use-after-free with amdgpu_job_free → amdgpu_cs_parser_fini → amdgpu_cs_ioctl, on a thread of the game then ring gfx_0.0.0 timeout, signaled seq=87513, emitted seq=87515, Ring gfx_0.0.0 reset failed, GPU reset begin!. Source: 1, VRAM is lost due to GPU reset!, device wedged, but recovered through reset Start to device lost: 4 min 34 s. After RX_VK_FORCE_MESH_FALLBACK=1 in hookshot_env.txt: vk: no mesh shaders: task and mesh programs run as compute shaders (issue 640 fallback) vk: AMD Radeon RX 6800 XT (RADV NAVI21) ... mesh shaders no, host memory import yes the session passed the same point and held 60.0 fps for about 7 minutes, no device lost. Later in that run it became CPU-bound in a dense scene (1,100–1,600 draws: GPU 10.3 ms a frame, queue submit ~34 ms). That part was ours, not the port: the container had no /dev/udmabuf, so it logged guest memory stays host-pointer imports for the GPU (slow submissions on AMD). With the device exposed the same build reports guest memory as dma-bufs: yes. So this matches #2245 and the fix in #2362. I can attach the full run log and the kernel block.

❤️ 1

NotRexed commented

2026-11-11 21:27:45 +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. Pull request #2362, #2311 works on this.