[Issue]: Memory access fault by GPU - hipMemcpy Host-to-Device cause on gfx1150 APU
@Jonathan03ant is already working on this.
Since Apr 20, 2026.
- Dominant language
- C
- Stars
- 460
- Forks
- 143
- PR merge metrics
- No merged PRs in 30d
Description
Problem Description
hipMemcpy Host-to-Device triggers WALKER_ERROR=1/MAPPING_ERROR=1 on gfx1150 APU — regression in kernel 6.17 (works on 6.14)
[!NOTE]
After wasting 3 days debugging and a lot tokens I finally think the problem was pin pointed.
Sharing outcome to help improve rocm ecosystem. :-)
Description generated from the co-debugging sessions.
Problem Description
On an AMD Ryzen AI 9 HX PRO 370 (Strix Halo APU, Radeon 890M gfx1150), every
hipMemcpy(HostToDevice) immediately triggers a GPU memory access fault with
WALKER_ERROR: 0x1 and MAPPING_ERROR: 0x1 on kernel 6.17.0-1017-oem and
6.17.0-20-generic. The fault does not occur on kernel 6.14.0-1018-oem.
This is an APU (UMA) system — the GPU has no discrete VRAM; all memory is shared
LPDDR5. The regression is 100% reproducible on every hipMemcpy call with no
workload required.
System Information
| Field | Value |
|---|---|
| OS | Ubuntu 24.04 LTS |
| CPU | AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (Strix Halo, Zen 5, 24 cores) |
| GPU | AMD Radeon 890M, gfx1150 (APU / UMA, no discrete VRAM) |
| VRAM | 16384 MiB (BIOS UMA, shared system memory) |
| System RAM | 64 GiB DDR5 |
| ROCm | 7.1.1 (Docker: rocm/dev-ubuntu-24.04:7.1.1-complete) |
| Working kernel | 6.14.0-1018-oem (6.14.0-1018.18) |
| Broken kernels | 6.17.0-1017-oem (6.17.0-1017.17), 6.17.0-20-generic (6.17.0-20.20~24.04.1) |
KFD Node Properties (on affected 6.17 kernel)
capability 0x2903a280
HMM_BASED 0
XNACK 0
SDMA_QUEUE 0
PCIE_ATOMICS 1
WAVEFRONT_32 1
WAVEFRONT_64 1
rocminfo (GPU agent)
Name: gfx1150
Marketing Name: AMD Radeon 890M
Vendor Name: AMD
Max Clock Freq. (MHz): 2900
Compute Unit: 16
Memory Properties: APU
XNACK enabled: NO
ISA: amdgcn-amd-amdhsa--gfx1150
What Was Tested (All Failed on 6.17)
All of the following were tried on 6.17.0-1017-oem and 6.17.0-20-generic
with no improvement:
| Attempt | Result |
|---|---|
amdgpu.noretry=0 / noretry=1 kernel param |
Still faults |
amdgpu.gttsize=32768 (expand GTT) |
Still faults |
iommu=pt kernel param |
Still faults (no IOMMU/IVRS table present on this board) |
amdgpu.vm_update_mode=3 |
Still faults |
HSA_XNACK=1 env var |
Still faults |
HSA_ENABLE_SDMA=0 / =1 |
Still faults |
hipHostMalloc with pinned source buffer |
Still faults |
mmap with MAP_LOCKED |
Still faults |
Docker --privileged flag |
Still faults |
| BIOS UMA VRAM size changes (32 GiB → 512 MiB → 16 GiB → Auto) | Still faults |
ROCm 7.12 native install (amdrocm-core-sdk-gfx1150) |
Still faults |
hipMallocManaged (SVM) read/write |
Works — GPU accessible via SVM |
The fact that hipMallocManaged works confirms the GPU is functional and
accessible; only the device memory copy paths (hipMemcpy, hipMalloc + copy)
are broken. This points specifically to KFD GPU VM page table management for
regular host pages.
What Solved It
Booting into 6.14.0-1018-oem (the AMD-recommended OEM kernel for
gfx1150 ROCm workloads) fixes the issue entirely. All hipMemcpy calls succeed
immediately with no other changes.
Benchmark results after fix (llama.cpp ROCm, Llama-3.2-3B Q4_K_M):
| model | backend | ngl | test | t/s |
| ---------------------- | ------- | --: | ------: | ---------------: |
| llama 3B Q4_K - Medium | ROCm | 999 | pp256 | 870.75 ± 0.39 |
| llama 3B Q4_K - Medium | ROCm | 999 | tg128 | 31.02 ± 0.12 |
Additional Information
- Vulkan (via RADV) works correctly on all kernels including 6.17 — this is
strictly a KFD/ROCm issue. - Ollama v0.21.0 (Vulkan backend) is unaffected throughout.
- No IOMMU is active on this board (
dmesgshows no IVRS table); IOMMU-related
parameters have no effect. - The issue is fully reproducible in a clean Docker container, ruling out
native ROCm install state.
Operating System
Ubuntu 24.04 LTS
CPU
AMD Ryzen AI 9 HX PRO 370 w/ Radeon 890M (Strix Halo, Zen 5, 24 cores)
GPU
AMD Radeon 890M, gfx1150 (APU / UMA, no discrete VRAM)
ROCm Version
7.1.1 (Docker: rocm/dev-ubuntu-24.04:7.1.1-complete)
ROCm Component
No response
Steps to Reproduce
Minimal Reproducer
The following test was run inside the official ROCm Docker container to isolate
from any native install differences:
docker run --rm \
--device=/dev/kfd --device=/dev/dri \
--security-opt seccomp=unconfined \
--group-add video \
--ipc=host --shm-size=16g \
rocm/dev-ubuntu-24.04:7.1.1-complete bash -lc '
cat > /tmp/test.cpp << "EOF"
#include <hip/hip_runtime.h>
#include <stdio.h>
#include <stdlib.h>
#define CHECK(cmd) { \
hipError_t e = (cmd); \
if (e != hipSuccess) { \
printf("FAIL %s: %s\n", #cmd, hipGetErrorString(e)); \
exit(1); \
} \
}
int main() {
float *h = (float*)malloc(4096);
h[0] = 42.0f;
float *d;
CHECK(hipMalloc(&d, 4096));
CHECK(hipMemcpy(d, h, 4096, hipMemcpyHostToDevice)); // <-- faults here
CHECK(hipMemcpy(h, d, 4096, hipMemcpyDeviceToHost));
printf("PASS result=%g\n", h[0]);
return 0;
}
EOF
hipcc /tmp/test.cpp -o /tmp/test && /tmp/test'
Result on 6.17.0-1017-oem / 6.17.0-20-generic (FAIL)
FAIL hipMemcpy: Memory access fault by GPU node-1 (Agent handle: ...) on address 0x...
Corresponding dmesg output:
amdgpu 0000:c4:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:0 vmid:... pasid:...)
amdgpu 0000:c4:00.0: amdgpu: Process test pid ... thread test pid ...
amdgpu 0000:c4:00.0: amdgpu: in page starting at address 0x... from client ...
amdgpu 0000:c4:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS: ...
amdgpu 0000:c4:00.0: amdgpu: WALKER_ERROR: 0x1
amdgpu 0000:c4:00.0: amdgpu: MAPPING_ERROR: 0x1
amdgpu 0000:c4:00.0: amdgpu: PERMISSION_FAULTS: 0x0
WALKER_ERROR=1 means the GPU page table walker itself failed — the GPU cannot
walk the page tables for the host address at all, not a permission issue.
Result on 6.14.0-1018-oem (PASS)
PASS result=42
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.