Troubleshooting Ollama GPU Inference Failures on AMD Ryzen AI Max

I use Ollama with ROCm on GMKtec EVO-X2 systems equipped with an AMD Ryzen AI Max+ 395 and Radeon 8060S integrated GPU. While setting up another EVO-X2, I encountered a failure that was not obvious from the usual GPU checks: ROCm detected the GPU, but Ollama could not run a model.

I eventually restored GPU inference by booting an earlier Linux kernel. This article describes the symptoms, the checks I performed, and what I learned from the comparison.

For the initial ROCm, Docker, and Ollama installation, see my setup guide.

1. The problem

The affected machine was running Ubuntu 24.04, with Ollama in a ROCm-enabled Docker container. The Radeon 8060S was detected as gfx1151 by rocminfo.

However, attempting to run the relatively small Llama 3.2 3B model returned:

Error: 500 Internal Server Error: llama runner process has terminated: exit status 2

The kernel was 6.17.0-19-generic at the time. I had also encountered ROCm memory-related errors while trying a much larger model, but the fact that 3B inference failed as well meant that model size alone could not explain the problem.

A successful rocminfo check establishes that the host can enumerate a GPU agent. It does not establish that Ollama can initialize its inference backend, allocate resources, load model layers, and generate a response.

2. Checking the failure

I checked the host, the container, and the model separately. On the Ubuntu host, these commands provide the essential evidence:

# Identify the running kernel and ROCm GPU target.
uname -r
rocminfo | grep -E 'gfx1151|AMD RYZEN AI MAX' | head -n 15

# Confirm the container is running and inspect its errors.
docker ps --filter name=ollama
docker logs --tail 100 ollama

# Check the Ollama version and installed models.
docker exec ollama ollama --version
docker exec ollama ollama list

I then reproduced the error with the smaller model:

docker exec ollama ollama run llama3.2:3b "Reply with OK."

This last command assumes that llama3.2:3b is already installed. It is an active inference test, unlike the read-only checks above.

I also removed HSA_OVERRIDE_GFX_VERSION=11.5.1 from the container configuration during troubleshooting. That change alone did not resolve the error. I retained the seccomp=unconfined setting used in the affected ROCm container configuration.

At this point, the GPU was visible but inference still failed, so I compared the available kernel configurations rather than continuing to adjust the model's memory settings.

3. Comparing kernel versions

The machine still had an earlier kernel installed. I booted that version from GRUB and retested Ollama.

Kernel	Observed result on this EVO-X2
6.17.0-19-generic	Llama 3.2 3B inference failed with HTTP 500 / runner exit status 2
6.17.0-14-generic	Ollama loaded the ROCm backend and GPU inference succeeded

After booting 6.17.0-14-generic, the Ollama logs reported:

Device 0: AMD Radeon Graphics, gfx1151
load_tensors: offloaded 29/29 layers to GPU

The logs also showed HTTP 200 responses from both /api/generate and /api/chat. This provided stronger evidence than GPU detection alone: the model had loaded onto the GPU and served inference requests.

The comparison identified a kernel-dependent compatibility problem in that software environment. It did not establish which kernel change was responsible, and it was not a controlled experiment across every ROCm, driver, or container version.

4. What I would check before changing a kernel

If I encounter the same symptom again, I follow a short sequence:

1. Confirm the failure with a small model. A 3B model helps distinguish a general inference failure from a large-model memory limit.
2. Check GPU visibility and the runner logs separately. rocminfo and docker logs ollama answer different questions.
3. Record the complete environment. At minimum, keep uname -r, Ollama and ROCm versions, the Docker image identity, and relevant error logs.
4. Compare only known, compatible configurations. If a previously working kernel is still installed, test it only with a verified recovery path and local or out-of-band console access.
5. Verify actual inference afterward. A successful API response and GPU layer-offload log are more meaningful than a running container alone.

A remote kernel change can make a machine unreachable, so I would not reboot a server solely on the basis of this article. I also would not permanently block security updates without a plan to validate and adopt a supported kernel.

Do not treat 6.17.0-14-generic as a generally recommended kernel. AMD's later RDNA 3.5 kernel requirements identify additional KFD fixes for Ryzen AI Max and list newer minimum kernel package versions for supported ROCm configurations. My result describes a specific earlier software combination, not an instruction to downgrade a current installation. Also, the short uname -r string does not show the full Ubuntu package revision.

Conclusion

The failure taught me to distinguish GPU detection from successful GPU inference. On this EVO-X2, gfx1151 was visible to ROCm even though Ollama's runner failed. Returning to the earlier kernel restored inference, and the logs confirmed that all 29 layers of Llama 3.2 3B were offloaded to the GPU.

The practical lesson is to test the actual inference path and preserve a known-working software combination before changing the kernel or GPU runtime.

References

• AMD ROCm: RDNA 3.5 kernel requirements
• Ollama: Troubleshooting
• Ollama: GPU support

---

AI disclosure: This article documents my own technical setup and results. An LLM was used to help draft, organize, and edit the English text. I remain responsible for its technical accuracy.