MagicBeanDev/Hookshot

Archived

Watch

Fork 0

[CachyOS Linux/AMD] GPU hang (gfx ring timeout → MODE2 reset, device lost) on Radeon 680M iGPU / RADV after the intro movie; window stays black (works on Windows, same hardware) #984

Closed

opened 2026-11-09 04:52:40 +00:00 by cmcc7x · 1 comment

cmcc7x commented

2026-11-09 04:52:40 +00:00

(Migrated from github.com)

Hookshot version

v2.0.5

What kind of problem

Crash, freeze or black screen

What happened

Summary

On an AMD Radeon 680M (integrated, RADV), Hookshot boots, plays the startup logo and intro movie, starts loading the first scene, and then the GPU hangs. amdgpu reports a gfx ring timeout, the per-ring reset fails, and the kernel does a full MODE2 GPU reset. The game's VkDevice is lost (every later submit fails with -4), the monitor briefly loses signal, and the window stays black until I close it.

The README lists AMD cards as "never tested", so this is a first data point. The hang is reproducible (4 times in one boot) and does not happen on Windows on the same hardware.

Environment

Hookshot: commit a598b9f (source 7df921e1), Linux build, language es-419
Game build: [fill in, e.g. e0f3ccfa]
OS: CachyOS Linux (latest), kernel 7.3.3-1-cachyos
Desktop: KDE Plasma 6.8.2, Wayland (Qt 6.12.0, KDE Frameworks 6.31.0)
CPU: AMD Ryzen 7 7735HS with Radeon Graphics (16 threads)
GPU: AMD Radeon 680M (integrated, RDNA2 / Rembrandt, 0x1002:0x1681)
RAM: 24 GiB (19.3 GiB usable)
Driver: Mesa 26.2.6-arch3.1, RADV, Vulkan API 1.4.354, conformance 1.4.5.3
amdgpu 3.64.0, VBIOS 113-REMBRANDT-X37 (2022/04/12), SMU fw 69.59.0
Memory as seen by the driver: VRAM 4096M (carve-out), GTT 9883M
Vulkan layers installed on the system: MangoHud, Gamescope WSI, Mesa anti-lag, Steam overlay/fossilize [state whether any was active]
Controller: X360 Controller (SDL)

What happens

Shader preparation finishes (prepared 31985 shader programs ... in 93.7 s, 7 failed).
Startup logo and intro movie play fine at 45-60 fps.
When the game starts loading, the texture count and submit times grow. I see slow submit entries from hundreds of ms up to 2.5 s, and slow present: 2471.0 ms.

The GPU hangs:

radv/amdgpu: The CS has been cancelled because the context is lost. This context is guilty of a hard recovery.
vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers)
vk: batched submit 4653 failed (-4)

Every later batched submit fails with -4, and vk: the window is not shown (no image back in 100 ms) appears. The window stays black. I closed it manually (display: window closed, exiting).

Works on Windows (same hardware)

The same Hookshot build [same build/commit: confirm] does not hit this device lost on Windows on the same machine [confirm it is the same PC], using AMD's Windows driver [Adrenalin version]. There it gets past the loading stage where Linux hangs [describe how far it goes, and any stutter or other issues].

So the Radeon 680M itself seems able to run this workload, and the problem looks specific to the Linux path: Mesa/RADV 26.2.6 or the Linux host/Vulkan code. I can't tell which one from my side.

Kernel log (same boot, reproducible)

The hang is a gfx ring timeout, and dmesg has no page fault lines (see the coredump analysis below for one misleading line in the dump header). It happened 4 times in one boot, always from the game's Vulkan thread:

amdgpu 0000:06:00.0: ring gfx_0.0.0 timeout, signaled seq=75475, emitted seq=75476
amdgpu 0000:06:00.0:  Process hookshot pid 13387 thread mkw_vk display pid 13507
amdgpu 0000:06:00.0: Starting gfx_0.0.0 ring reset
amdgpu 0000:06:00.0: Ring gfx_0.0.0 reset failed
amdgpu 0000:06:00.0: GPU reset begin!. Source:  1
amdgpu 0000:06:00.0: MODE2 reset
amdgpu 0000:06:00.0: GPU reset(4) succeeded!
amdgpu 0000:06:00.0: [drm] device wedged, but no recovery needed

Timeouts at 143 s, 7335 s, 7454 s and 7985 s of uptime. The per-ring reset fails every time, the full MODE2 reset succeeds, the desktop survives, and the game's VkDevice is lost.
Once, a compute ring timeout followed 3 s after the gfx one (ring comp_1.2.0 timeout); that one recovered with a ring reset.

Coredump analysis (amdgpu devcoredump of the 4th hang, attached as `amdgpu_coredump.txt.gz`)

Header: time: 7985.91, pasid: 87, vmid: 7, process_name: hookshot TGID: 13387 thread: mkw_vk display PID: 13507, ring gfx_0.0.0.

Not a real page fault. The dump prints [gfxhub] Page fault observed / address 0x0 / status 0x0, but that looks like an empty record: GCVM_L2_PROTECTION_FAULT_STATUS, all *_UTCL1/UTCL0_STATUS registers and CP_GFX_ERROR are 0.
The CP was inside the main draw IB. CP_IB1_BASE = 0x8001_0146e000 and CP_IB1_CMD_BUFSZ = 0x2d00 match "IB #3" in the dump exactly (VA 0xffff80010146e000, 11520 dw). CP_IB2_BASE = 0x8001_00025000, size 0xa8, matches the IB called from "IB #0".
Graphics pipeline stuck busy. GRBM_STATUS = 0xe7f100ac (by my reading of the bits: GUI_ACTIVE, CP_BUSY, and GE/PA/SC/SPI/DB/CB busy, CB/DB not clean). The ring had 256 dwords pending (Rptr 0x100, Wptr 0x200, ring size 2048 dw).
IB #3 contents: 90 DRAW_INDEX_2, 13 DRAW_INDEX_AUTO, 2 DISPATCH_DIRECT, 252 DMA_DATA, ~34 packets with opcodes 0x4d/0x9f that I could not identify. IB #0 contains an opcode 0xA9 packet, which I believe is DISPATCH_TASK_STATE_INIT, so task/mesh shaders are probably involved in this submission.
I could not tell from the dump which draw or shader hung. A RADV_DEBUG=hang dump would answer that; I haven't captured one.
The comp_1.2.0 timeout 3 s later may be related if task shaders run on the async compute queue, but that is only a guess.

Possible factors

Linux/RADV-specific. Since Windows (AMD's driver) does not hang, a RADV bug or a difference in how the Linux path submits work (mesh/task shaders, synchronization, memory budget) seems more likely than a plain GPU limitation.
A long-running or non-terminating GPU job inside the graphics pipeline. There is no real page fault, so an invalid address seems unlikely. The mesh/task shaders (the log says they are built without the driver optimizer on AMD: RX_VK_MESH_OPT=1: with it) or one of the heavy compute passes are my first suspects.
Memory context (probably secondary). Right before the first hang the log shows:
- heap 0 (system): used 5652 of 4659 MB
- heap 1 (device): used 6995 of 7656 MB
- working set 9796 MB, 1607 textures (3565 MB), texture budget 6144 MB
The iGPU has a 4 GB carve-out plus shared system memory, so the budget may be optimistic, but the lack of a real fault, and the fact that Windows runs on the same RAM, suggest this is not the direct cause.
Unsupported or untranslated shaders (probably not the direct cause):
- program 499dbfd0721d2858 not translated: ... GlobalAtomicAddF32 is not implemented
- 6 NVN2 stage-5 programs with unsupported native opcode (native op 0x3a9)
- several compute "networks" rejected (a network left out on this card) and the TAAU network fd029a317a9a4b94 is stood in for
- storage buffer NOT bound (reads zeros) for several mesh programs
- view of texture ... as vk 95 ... not made

Attachments

hookshot_log.3.txt: full game log of the failing Linux run
dmesg excerpt (amdgpu / ring / reset lines) from the same boot
amdgpu_coredump.txt.gz: devcoredump of the 4th hang (includes the dumped IBs)
vulkaninfo --summary output
[Optional] Windows log of the same game, for side-by-side comparison

Where in the game

Link's house

How often

Every time

Graphics card and driver version

GPU: AMD Radeon 680M (integrated, RDNA2) , Driver: Mesa 26.2.6-arch3.1, RADV, Vulkan API 1.4.354

CPU, RAM and operating system

AMD Ryzen 7 7735HS with Radeon Graphics (16 threads), RAM: 24 GiB (19.3 GiB usable), CachyOS Linux (latest), kernel 7.3.3-1-cachyos

Changes from the defaults

No response

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

amdgpu_coredump.tar.gz

dmesg.txt

hookshot_log.3.txt

vulkaninfo --summary.txt

Screenshots or video

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.5 ### What kind of problem Crash, freeze or black screen ### What happened ## Summary On an AMD Radeon 680M (integrated, RADV), Hookshot boots, plays the startup logo and intro movie, starts loading the first scene, and then the GPU hangs. amdgpu reports a gfx ring timeout, the per-ring reset fails, and the kernel does a full MODE2 GPU reset. The game's VkDevice is lost (every later submit fails with `-4`), the monitor briefly loses signal, and the window stays black until I close it. The README lists AMD cards as "never tested", so this is a first data point. The hang is reproducible (4 times in one boot) and does not happen on Windows on the same hardware. ## Environment - Hookshot: commit `a598b9f` (source `7df921e1`), Linux build, language es-419 - Game build: [fill in, e.g. e0f3ccfa] - OS: CachyOS Linux (latest), kernel 7.3.3-1-cachyos - Desktop: KDE Plasma 6.8.2, Wayland (Qt 6.12.0, KDE Frameworks 6.31.0) - CPU: AMD Ryzen 7 7735HS with Radeon Graphics (16 threads) - GPU: AMD Radeon 680M (integrated, RDNA2 / Rembrandt, `0x1002:0x1681`) - RAM: 24 GiB (19.3 GiB usable) - Driver: Mesa 26.2.6-arch3.1, RADV, Vulkan API 1.4.354, conformance 1.4.5.3 - amdgpu 3.64.0, VBIOS 113-REMBRANDT-X37 (2022/04/12), SMU fw 69.59.0 - Memory as seen by the driver: VRAM 4096M (carve-out), GTT 9883M - Vulkan layers installed on the system: MangoHud, Gamescope WSI, Mesa anti-lag, Steam overlay/fossilize [state whether any was active] - Controller: X360 Controller (SDL) ## What happens 1. Shader preparation finishes (`prepared 31985 shader programs ... in 93.7 s`, 7 failed). 2. Startup logo and intro movie play fine at 45-60 fps. 3. When the game starts loading, the texture count and submit times grow. I see `slow submit` entries from hundreds of ms up to 2.5 s, and `slow present: 2471.0 ms`. 4. The GPU hangs: ``` radv/amdgpu: The CS has been cancelled because the context is lost. This context is guilty of a hard recovery. vk: device lost: reading the fault info (RX_VK_CHECKPOINTS=1 for markers) vk: batched submit 4653 failed (-4) ``` 5. Every later batched submit fails with `-4`, and `vk: the window is not shown (no image back in 100 ms)` appears. The window stays black. I closed it manually (`display: window closed, exiting`). ## Works on Windows (same hardware) The same Hookshot build [same build/commit: confirm] does **not** hit this device lost on Windows on the same machine [confirm it is the same PC], using AMD's Windows driver [Adrenalin version]. There it gets past the loading stage where Linux hangs [describe how far it goes, and any stutter or other issues]. So the Radeon 680M itself seems able to run this workload, and the problem looks specific to the Linux path: Mesa/RADV 26.2.6 or the Linux host/Vulkan code. I can't tell which one from my side. ## Kernel log (same boot, reproducible) The hang is a **gfx ring timeout**, and `dmesg` has no page fault lines (see the coredump analysis below for one misleading line in the dump header). It happened 4 times in one boot, always from the game's Vulkan thread: ``` amdgpu 0000:06:00.0: ring gfx_0.0.0 timeout, signaled seq=75475, emitted seq=75476 amdgpu 0000:06:00.0: Process hookshot pid 13387 thread mkw_vk display pid 13507 amdgpu 0000:06:00.0: Starting gfx_0.0.0 ring reset amdgpu 0000:06:00.0: Ring gfx_0.0.0 reset failed amdgpu 0000:06:00.0: GPU reset begin!. Source: 1 amdgpu 0000:06:00.0: MODE2 reset amdgpu 0000:06:00.0: GPU reset(4) succeeded! amdgpu 0000:06:00.0: [drm] device wedged, but no recovery needed ``` - Timeouts at 143 s, 7335 s, 7454 s and 7985 s of uptime. The per-ring reset fails every time, the full MODE2 reset succeeds, the desktop survives, and the game's VkDevice is lost. - Once, a compute ring timeout followed 3 s after the gfx one (`ring comp_1.2.0 timeout`); that one recovered with a ring reset. ## Coredump analysis (amdgpu devcoredump of the 4th hang, attached as `amdgpu_coredump.txt.gz`) Header: `time: 7985.91`, `pasid: 87`, `vmid: 7`, `process_name: hookshot TGID: 13387 thread: mkw_vk display PID: 13507`, ring `gfx_0.0.0`. - **Not a real page fault.** The dump prints `[gfxhub] Page fault observed / address 0x0 / status 0x0`, but that looks like an empty record: `GCVM_L2_PROTECTION_FAULT_STATUS`, all `*_UTCL1/UTCL0_STATUS` registers and `CP_GFX_ERROR` are 0. - **The CP was inside the main draw IB.** `CP_IB1_BASE = 0x8001_0146e000` and `CP_IB1_CMD_BUFSZ = 0x2d00` match "IB #3" in the dump exactly (VA `0xffff80010146e000`, 11520 dw). `CP_IB2_BASE = 0x8001_00025000`, size `0xa8`, matches the IB called from "IB #0". - **Graphics pipeline stuck busy.** `GRBM_STATUS = 0xe7f100ac` (by my reading of the bits: GUI_ACTIVE, CP_BUSY, and GE/PA/SC/SPI/DB/CB busy, CB/DB not clean). The ring had 256 dwords pending (`Rptr 0x100`, `Wptr 0x200`, ring size 2048 dw). - **IB #3 contents:** 90 `DRAW_INDEX_2`, 13 `DRAW_INDEX_AUTO`, 2 `DISPATCH_DIRECT`, 252 `DMA_DATA`, ~34 packets with opcodes `0x4d`/`0x9f` that I could not identify. IB #0 contains an opcode `0xA9` packet, which I believe is `DISPATCH_TASK_STATE_INIT`, so task/mesh shaders are probably involved in this submission. - I could not tell from the dump which draw or shader hung. A `RADV_DEBUG=hang` dump would answer that; I haven't captured one. - The `comp_1.2.0` timeout 3 s later may be related if task shaders run on the async compute queue, but that is only a guess. ## Possible factors - **Linux/RADV-specific.** Since Windows (AMD's driver) does not hang, a RADV bug or a difference in how the Linux path submits work (mesh/task shaders, synchronization, memory budget) seems more likely than a plain GPU limitation. - **A long-running or non-terminating GPU job inside the graphics pipeline.** There is no real page fault, so an invalid address seems unlikely. The mesh/task shaders (the log says they are built without the driver optimizer on AMD: `RX_VK_MESH_OPT=1: with it`) or one of the heavy compute passes are my first suspects. - **Memory context (probably secondary).** Right before the first hang the log shows: - `heap 0 (system): used 5652 of 4659 MB` - `heap 1 (device): used 6995 of 7656 MB` - `working set 9796 MB`, `1607 textures (3565 MB)`, texture budget 6144 MB The iGPU has a 4 GB carve-out plus shared system memory, so the budget may be optimistic, but the lack of a real fault, and the fact that Windows runs on the same RAM, suggest this is not the direct cause. - **Unsupported or untranslated shaders** (probably not the direct cause): - `program 499dbfd0721d2858 not translated: ... GlobalAtomicAddF32 is not implemented` - 6 NVN2 stage-5 programs with `unsupported native opcode (native op 0x3a9)` - several compute "networks" rejected (`a network left out on this card`) and `the TAAU network fd029a317a9a4b94 is stood in for` - `storage buffer NOT bound (reads zeros)` for several mesh programs - `view of texture ... as vk 95 ... not made` ## Attachments - `hookshot_log.3.txt`: full game log of the failing Linux run - `dmesg` excerpt (amdgpu / ring / reset lines) from the same boot - `amdgpu_coredump.txt.gz`: devcoredump of the 4th hang (includes the dumped IBs) - `vulkaninfo --summary` output - [Optional] Windows log of the same game, for side-by-side comparison ### Where in the game Link's house ### How often Every time ### Graphics card and driver version GPU: AMD Radeon 680M (integrated, RDNA2) , Driver: Mesa 26.2.6-arch3.1, RADV, Vulkan API 1.4.354 ### CPU, RAM and operating system AMD Ryzen 7 7735HS with Radeon Graphics (16 threads), RAM: 24 GiB (19.3 GiB usable), CachyOS Linux (latest), kernel 7.3.3-1-cachyos ### Changes from the defaults _No response_ ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [amdgpu_coredump.tar.gz](https://github.com/user-attachments/files/34564000/amdgpu_coredump.tar.gz) [dmesg.txt](https://github.com/user-attachments/files/34564022/dmesg.txt) [hookshot_log.3.txt](https://github.com/user-attachments/files/34564025/hookshot_log.3.txt) [vulkaninfo --summary.txt](https://github.com/user-attachments/files/34564027/vulkaninfo.--summary.txt) ### Screenshots or video <img width="1413" height="818" alt="Image" src="https://github.com/user-attachments/assets/3cdd8f25-80c5-4d11-99ec-1f48a236835c" /> <img width="1413" height="818" alt="Image" src="https://github.com/user-attachments/assets/241ae55d-1bb2-49b7-9016-ff1a445aa96a" /> ### 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 06:03:09 +00:00

(Migrated from github.com)

Tracked in #1000, follow there. That issue collects every report of Linux / Steam Deck GPU hangs, crashes, low fps and build failures, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.

Commenting is not possible because the repository is archived.