Failures
Paste your error
Client-side matcher against 16 patterns we have actually cited (as of 2026-10-12). No invented issue numbers. If nothing hits, that is a honest miss — file it upstream and tell us.
Nothing pasted yet. The list below is the full catalog.
Catalog
hip · gfx1201 · compile
hipErrorNoBinaryForGpu
Cause. HIP has a GPU, but no compiled kernel image for that ISA. Official HIP definition: “No kernel image is available for execution on the device.” On gfx1201 that usually means the wheel, container, or llama.cpp HIP build was compiled for a different AMDGPU_TARGETS list.
Fix. Rebuild or reinstall with an explicit gfx1201 target (`-DAMDGPU_TARGETS=gfx1201` / `-DGGML_HIP=ON` for llama.cpp, or the gfx1201 ROCm family package). Do not paper over it with a random HSA_OVERRIDE_GFX_VERSION on a card current ROCm already lists. If HIP still has no binary, use llama.cpp Vulkan tonight.
HIP error codes — hipErrorNoBinaryForGpu (209) · Matching threads · Ask the forum
hip · wheels
invalid device function
Cause. A kernel launched on a device it was not compiled for — the HIP cousin of CUDA’s “invalid device function.” Same family as a missing binary: wrong gfx target, mixed ROCm libraries, or a CUDA-shaped wheel.
Fix. Confirm `rocminfo` shows gfx1201, then confirm the process is a HIP/ROCm build (`torch.version.hip` is not None; vLLM image is `*-rocm`, not default PyPI). Rebuild llama.cpp with `AMDGPU_TARGETS=gfx1201`. If the stack is CUDA-shaped, uninstall it.
HIP error codes (invalid device function / missing kernel image) · Matching threads · Ask the forum
hsa · gfx1201 · unofficial
HSA_OVERRIDE_GFX_VERSION
Cause. An unofficial environment variable that pretends the GPU is a different gfx target so an older binary will load. People set 11.0.0 / 12.0.0 / 12.0.1 when a build has no gfx1201 kernels. On Windows Ollama + R9700, those overrides still failed to initialize ROCm (#14686).
Fix. On a current gfx1201 card with ROCm 10.0/10.1, you should not need it. Unset it. Install a userspace that actually lists gfx1201, or run llama.cpp Vulkan. If you keep an override, treat it as unofficial and expect wrong kernels or silent CPU fallback.
kernel · hang · mes
amdgpu MODE1 reset / GPU hang
Cause. The amdgpu driver declared the GPU hung and issued a MODE1 (SMU) reset. On gfx12 this has shown up after MES (“failed to suspend gangs”) failed to recover a compute queue — including during ROCm HSA selftests on linux-next (July 2026 amd-gfx thread). VRAM is lost across the reset.
Fix. Check `dmesg | grep -iE 'amdgpu|MODE1|MES'` after a hang. If it started after a kernel upgrade, bisect kernel vs ROCm userspace before you reinstall TheRock. Fine-tune KI on the R9700: try `TORCH_BLAS_PREFER_HIPBLASLT=0` before blaming the model. For inference, switch to llama.cpp Vulkan and see if the hang follows HIP.
amd-gfx — GPU reset / MODE1 on gfx12 HSA tests (Jul 2026) · Matching threads · Ask the forum
ollama · gfx1201 · docker
Ollama gfx1201 — missing hipBLASLt tensile (Linux/Docker)
Cause. Official `ollama:rocm` (reported on RX 9070 XT, gfx1201) looked for `TensileLibrary_lazy_gfx1201.dat` under `hipblaslt/library/` while the file lived under `rocblas/library/` (#12908). hipBLASLt then failed heuristic fetch. Same class of “bundled ROCm does not match gfx1201.”
Fix. Do not treat official Ollama ROCm as the daily driver on gfx1201. Use llama.cpp you compiled (Vulkan or HIP gfx1201) and `rocm-smi` to prove GPU use. If you stay on Ollama, upgrade past the image that shipped the path bug and read the issue before you set overrides.
ollama · windows · gfx1201
Ollama ROCm fails on R9700 Windows
Cause. Ollama 0.17.7 on Windows 11 with an R9700 detected gfx1201, then logged `filtering device which didn't fully initialize` and ran on CPU (#14686). The bundled ROCm (amdhip64_6.dll / 6.x tensiles through gfx1151) had no gfx1201 kernels. Vulkan (`OLLAMA_VULKAN=1`) worked.
Fix. On Windows, use Vulkan llama.cpp (or Ollama’s Vulkan path) and do not expect a full ROCm userspace. Linux + llama.cpp is the path this site documents for HIP.
install · apt · packaging
Distro apt ROCm mixed with AMD’s repo
Cause. Canonical/Ubuntu `rocm` / `libamdhip64-dev` (5.7-era and 7.1-era archive reports) can shadow AMD’s 10.x install. ROCm #6110: gfx1201 “has 2 ISAs but can only support a single ISA” went away after removing Ubuntu-packaged HIP/HSA libs that were loaded instead of ROCm 7.2.1.
Fix. Pick one source. Purge archive `rocm`, `libamdhip64-dev`, `libhsa-runtime*` before adding AMD’s 10.0/10.1 repo. Re-read `ldconfig` / `ldd $(which rocminfo)` so `/opt/rocm` wins. See the install decision tree.
permissions · kfd
ROCm “no GPU found” / render and video groups
Cause. Userspace is installed but the process cannot open `/dev/kfd` or `/dev/dri`. Official Linux installs put the user in `render` and `video`. New groups do not apply until a full logout or reboot. Containers also need those device nodes and matching GIDs.
Fix. `sudo usermod -aG render,video "$USER"` then log out completely. `groups | grep -E 'render|video'`. `ls -l /dev/kfd /dev/dri`. In Docker: `--device /dev/kfd --device /dev/dri --group-add video`. Do not `sudo` inference to dodge permissions.
ROCm 10.1.0 install — post-install device access · Matching threads · Ask the forum
vram · context · calculator
Out of VRAM at long context
Cause. Context grows the KV cache. This site’s estimate is `2 × kv_layers × kv_heads × head_dim × context × bytes` — hybrid Qwen cards only grow KV on full-attention layers. A 262K f16 KV on Qwen3.6-35B-A3B is a large add on top of the 26.6 GB publisher GGUF.
Fix. Open the calculator. Stay at or above Q4. Prefer a smaller context or q8_0/q4_0 KV before you drop the weight quant. Daily driver on our rig is 262K f16 KV with 0% RAM offload on one 32 GB card — if your estimate overflows, do not invent a Q3 to “make it fit.”
Quant + Hardware Calculator (KV formula; estimates only) · Matching threads · Ask the forum
llama.cpp · vulkan · hip
Vulkan vs HIP — which backend?
Cause. llama.cpp can build HIP (`GGML_HIP`) or Vulkan (`GGML_VULKAN`). They are different compilers on the same VRAM. HIP shares DNA with PyTorch and vLLM. Vulkan shares DNA with the desktop driver. Daily driver on our rig is Vulkan. HIP CMake failing is not a reason to give up.
Fix. Consumer default: llama.cpp. If HIP configure cannot find ROCm, build Vulkan and pick the RADV GFX1201 device, not the iGPU. Keep HIP for PyTorch/vLLM. Measure both on the same GGUF if you like — notes, not a leaderboard. See the backend chooser.
llama.cpp — HIP and Vulkan backends · Matching threads · Ask the forum
vllm · pytorch · wheels
CUDA wheel from default PyPI (vLLM / PyTorch)
Cause. `pip install vllm` or default `torch` from PyPI is the CUDA build. Import then looks NVIDIA-shaped. AMD’s 10.0 docs pin vLLM 0.27 + PyTorch 2.13 via ROCm images/indexes, not default PyPI.
Fix. Uninstall the CUDA wheel. Use AMD’s ROCm vLLM page or `vllm/vllm-openai-rocm` (0.31 is a community try). Confirm `torch.version.hip`. Consumers should stay on llama.cpp anyway.
AMD — vLLM on ROCm (not default PyPI) · Matching threads · Ask the forum
devices · igpu
Process attached to the iGPU
Cause. Many boxes have a RAPHAEL/Strix iGPU plus the R9700. The first HIP or Vulkan device may be the iGPU. Ollama #12908 logs `description="AMD Radeon Graphics"` on a 16 GB card — marketing strings are not enough.
Fix. `llama-cli --list-devices` and pick RADV GFX1201 / the discrete index. Set `HIP_VISIBLE_DEVICES` / `GGML_VK_VISIBLE_DEVICES` / `ROCR_VISIBLE_DEVICES` only after you see the confusion. Isolation docs: AMD GPU isolation.
AMD — GPU isolation environment variables · Matching threads · Ask the forum
kernel · secure-boot
Secure Boot blocks the amdgpu DKMS module
Cause. An unsigned DKMS `amdgpu` will not load when Secure Boot is on. `lsmod | grep amdgpu` is empty; `rocminfo` sees only the CPU.
Fix. Enroll a MOK as your distro documents, disable Secure Boot, or keep a signed distro module and install userspace only (`--no-dkms` when that is the method you chose). Do not install a third driver to “fix” a black screen.
ROCm 10.1.0 install methods (DKMS / distro module) · Matching threads · Ask the forum
training · hipblaslt
Fine-tune GPU reset (hipBLASLt)
Cause. ROCm 10.0 known-issue class on the R9700: training / fine-tune can GPU-reset. The living tracker’s first mitigation is `TORCH_BLAS_PREFER_HIPBLASLT=0` before blaming the model. This is not an inference daily-driver issue.
Fix. Export `TORCH_BLAS_PREFER_HIPBLASLT=0` and retry the training step. File a bug with `rocminfo`, kernel, and ROCm prefix if it persists. Do not “fix” inference by applying training workarounds blindly.
ROCm 10.0.0 release notes (KI class; confirm on the live page) · Matching threads · Ask the forum
vllm · rccl · multi-gpu
vLLM / RCCL dies on two home cards
Cause. Two consumer / PRO cards are an RCCL and topology project, not a checkbox. vLLM warmup failures on older 0.21–0.25 lines were a documented class of pain. This site’s daily driver uses one R9700.
Fix. Single GPU first. Pin a vLLM release the notes say is fixed, or skip vLLM and stay on llama.cpp. Two-card speed is not promised.
AMD vLLM on ROCm — treat multi-GPU as a separate project · Matching threads · Ask the forum
qwen · llama.cpp
Qwen thinks forever / wrong chat template
Cause. Current Qwen instruct templates need `--jinja` on llama.cpp. Wrong template or an abliterated edit can break termination so “thinking” never ends.
Fix. Pass `--jinja`. Compare official instruct before any abliterated file. Disable thinking if the card says to. Do not “fix” it by grabbing a random uncensored GGUF.
llama.cpp — `--jinja` chat templates · Matching threads · Ask the forum
Broader order-of-operations: Troubleshooting. Backend pick: chooser. Community: forum.