| Bug ID | 107898 |
|---|---|
| Summary | "kfd: Failed to resume IOMMU for device 1002:15dd" = on Raven Ridge |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | major |
| Priority | medium |
| Component | DRM/amdkfd |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | marvin.damschen@gullz.de |
Created attachment 141520 [details]
dmesg 4.19-rc3
Hey,
I wanted to try the newly-added support for Raven Ridge in amdkfd, but
initialization fails at:
"kfd: Failed to resume IOMMU for device 1002:15dd" on AMD Ryzen 5=
2500U (Lenovo
E485) with 4.19-rc3. IOMMU itself seems to initialize fine (As I understand=
, I
can ignore the "AMD-Vi: Unable to write to IOMMU perf counter." m=
sg). Full log
is attached.
Best regards
Marvin
| What | Removed | Added |
|---|---|---|
| Attachment #141520 mime type | text/x-log | text/plain |
The AMD-Vi messages in the log look OK. I'm seeing the same on= my Raven system (Ryzen 5 2400G desktop). I'm currently running a 4.19-rc1+ kernel from Alex Deucher's drm-next-4.20-= wip branch. I haven't tried rc3 from the master branch yet. I'll try it tonight= and see if I can reproduce the issue.
I'm not seeing this problem on my Raven system with 4.19-rc3+ = ($ git describe v4.19-rc3-21-g5e335542de83). The most likely explanation is that on your system IOMMUv2 is not enabled. = That may be a BIOS setting. If your system BIOS setup doesn't allow you to enable the IOMMUv2, then you may be out of luck. I'll attach a patch that adds some extra error messages that should confirm that or point to a different sourc= e of the problem.
Created attachmen= t 141532 [details] [review] Add iommu init instrumentation
Output with patch applied: Sep 12 12:08:20 zen kernel: kfd kfd: Allocated 3969056 bytes on gart Sep 12 12:08:20 zen kernel: Topology: Add APU node [0x15dd:0x1002] Sep 12 12:08:20 zen kernel: Failed to attache to group Sep 12 12:08:20 zen kernel: amd_iommu_init_device failed: -22 Sep 12 12:08:20 zen kernel: kfd kfd: Failed to resume IOMMU for device 1002:15dd Sep 12 12:08:20 zen kernel: Creating topology SYSFS entries Sep 12 12:08:20 zen kernel: kfd kfd: device 1002:15dd NOT added due to erro= rs Full log attached. Thank you Marvin
| What | Removed | Added |
|---|---|---|
| Attachment #141520 is obsolete | 1 |
Created attachment 141533 [detail=
s]
dmesg 4.19-rc3 with iommu init instrumentation
Good timing. We were just given a laptop that has similar prob= lems and found a partial workaround: Try adding "iommu=3Dpt" to your kernel comman= d line. This may at least get you through the KFD initialization, but there are likely more problems down the line. The problems are due to BIOS bugs. We're looking into more workarounds to ignore or patch incorrect information in the CRAT ACPI table that describes= the compute devices for KFD.
KFD initializes without errors using "iommu=3Dpt". I= will see whether I can get ROCm running on top of that. Unfortunately, the BIOS has been terrible so far on the raven-based Lenovo= =20 laptops. I am happy to try any patches or workarounds you have, just let me know.
ROCm 1.9 runs OpenCL on GPU on top of mainline kfd and seems s= table. However: - CPU is not detected as a compute device (rocminfo attached) - Performance, at least in darktable, is quite low (the "bench.SRW&quo= t; benchmark in OpenCL on GPU takes more than 3 times longer than on CPU without OpenCL). The problem could be that memory buffers are too small, clinfo reports: "Max memory allocation 268435456 (256MiB)&qu= ot; which seems quite small to me (?). Are these problems a result of incorrect information in CRAT? Best regards Marvin
Created attachment 141=
657 [details]
ROCm 1.9 info on 4.19-rc4
rocminfo reports both the CPU and the GPU. If OpenCL can't use the CPU as a compute device, that's probably a limitati= on of the OpenCL implementation. The max memory allocation size is strange. rocminfo reports a single 16GB memory pool attached to the CPU. That's system memory from the CRAT table a= nd looks reasonable. It should be possible to use at least 3/8 of that with the upstream KFD. If CLinfo is reporting something different I'm wondering if i= t's an OpenCL limitation rather than a ROCm limitation. If you're interested in the raw information reported by KFD to user mode, checkout /sys/class/kfd/kfd/topology/nodes. On an APU there should be only = one node (0). Underneath that you'll find node properties as well as memory properties that may be interesting.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | NOTOURBUG |
Thanks a lot for the info. /sys/class/kfd/kfd/topology/nodes/0/mem_banks/0/properties correctly reports 16GB of RAM. As the issues seem to come from BIOS/OpenCL (not from kfd) and kfd successf= ully initializes with "iommu=3Dpt", I will close this bug report as re= solved. Best regards Marvin
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | REOPENED |
| Resolution | NOTOURBUG | --- |
I have the same issue on Dell Latitude 5495 with Linux kernel = 4.19.1 and iommu=3Dpt is a workaround here too. But as AMD is working around other BIOS bugs[1] (rather than getting them f= ixed quickly with their business partners), I think this bug report should be le= ft open for now. [1] https://git.kerne= l.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3D44d8cc6f1a90= 5e4bb1d4221a898abb0d7e9d100a
| What | Removed | Added |
|---|---|---|
| Resolution | --- | MOVED |
| Status | REOPENED | RESOLVED |
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this = link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/4.