The Cthulhu case is evidence, not a solved diagnosis
The user-reported investigation involved a Ryzen 7 5800X3D and RX 9060 XT / Navi 44 on NixOS, with kernel 7.2.8, Mesa/RADV 26.1.8 and Vulkan 1.4.x reported during that investigation. These are supplied case details, not a verified recommendation for current versions. Lightweight games remained stable; movement in a heavy game caused 1–2-second pauses or hard-locks with black displays and maximum fan speed. Some failures lacked a final useful GPU message; an earlier Arch test reported the GPU disappearing from the bus. Neither silence nor the movement trigger identifies one cause.
Movement can exercise several independent paths
Moving can demand new assets, shader or pipeline work, allocations, CPU simulation and different GPU submissions. Investigate GPU execution, PCIe transport, kernel/firmware and graphics userspace alongside storage. The case also had ata2 interface errors, BadCRC, READ FPDMA QUEUED and link resets: those are real storage evidence, potentially independent of the GPU fault. READ FPDMA QUEUED names a queued read command, not a fault by itself. Relocating the game to NVMe did not eliminate the reported problem, which weakens a SATA-only explanation but does not repair the separately failing SATA path or exclude all remaining I/O.
A lower power cap changes the experiment
The reported 112 W GPU cap avoided some hard crashes while pauses remained. This is correlation, not proof of a faulty power supply or a solved driver bug. A cap changes clocks, power and timing, so it can affect several mechanisms. Record short stalls, GPU resets and full hard-locks as different outcomes. Preserve the original settings and stop reproductions that repeatedly require forced shutdown. Inspect the actual game mount, shader-cache location and swap before claiming that every relevant read moved to NVMe. Repair a proven storage-link fault on its own evidence while continuing the separate GPU investigation.
Gather evidence before changing the system
Run one command at a time in the relevant host or game environment. Read its requirements and interpretation first. The website displays commands and never runs them.
Read-only observation
journalctl -k -b -1 -o short-monotonic --no-pagerRequirements: Persistent previous-boot kernel journal and read access.
After a reboot, compare GPU, PCIe and ATA messages with the observed stall time. Keep all three classes; absent retained logs cannot establish a clean failure interval.
Read-only observation
findmnt -T "/path/to/game"Requirements: util-linux findmnt and a real game directory; no elevated privileges normally needed.
Replace the path with the installed game directory. Record the backing mount; this does not identify the separate prefix, shader cache or swap device.
Read-only observation
iostat -xz 1Requirements: sysstat installed; device names must be mapped to the relevant mounts.
Observe successive device intervals during a safe short route. Elevated request waiting near a stall supports an I/O investigation, not a confirmed GPU explanation. The first report may cover time since boot. Stop with Ctrl+C.
Read-only observation
lspci -tRequirements: pciutils on the host; this is a read-only topology view.
Read PCI topology and identify bridges in the GPU path. A bridge being present is not evidence that it is faulty; pair topology with AER and link observations.
A controlled test with a way back
Use an already safe short reproduction and change only an in-game frame cap or streaming-related setting. Note each stall, reset and hard-lock separately with timestamps. Do not copy the case’s 112 W value to arbitrary hardware.
Rollback: Restore the recorded in-game setting and stop the monitoring command. If a power-cap experiment was separately chosen, restore that machine’s recorded original value using its supported control; no universal sysfs path is provided.
What this test cannot establish: The case remains unresolved. Its published acceptance logs are labeled synthetic and anonymized; they do not add a GPU timeout to the original no-final-error observation. Power-cap response, VRAM changes and SATA resets do not establish a single shared cause.
Sources and scope
This editorial review uses primary project and distribution references. It does not establish that a fix has been reproduced on your hardware. Installed versions, the game runtime and the selected graphics API can change the result.
- Linux kernel: AMDGPU module parameters
Scheduler timeouts and GPU recovery are configurable behavior, not universal repairs.
- Linux kernel: PCIe AER reporting
Correctable and uncorrectable PCIe reports have different severity and recovery implications.
- Linux kernel: libATA error handling
ATA error handling can freeze a port and reset a link; this is independent of the graphics stack.
- sysstat: iostat manual
Interval device statistics expose request waiting and activity; modern parallel devices need careful interpretation.
- Linux kernel: Pressure Stall Information
Memory and I/O pressure measure stalled task time; they do not identify a game’s root cause.