i915: avoid register_fictitious_range on meteorlake#324
Open
amshafer wants to merge 2 commits into
Open
Conversation
Contributor
|
What is the value of |
31 tasks
Member
On my Framework 13" Ultra 1 these are indeed zero. Maybe torvalds/linux@dbb2ffb. (Other than drm-kmod currently being in ports) is there a reason we couldn't use the upstream logic directly? |
Contributor
Author
|
Yes I saw that as well. I've been waiting for the in-progress 6.7 update to complete so I can test with that commit. That commit alone did not apply cleanly on 6.6. |
Member
|
I made a change in #332 (the Linux 6.7 update) to use the same address and size that is used by vt(4). I don’t have the issue with my Intel 12th gen CPU/GPU, so I have no idea if it solves the issue. Could you please try it? You will need a kernel from my freebsd-src branch (see #332 description) from tonight as well. Edit: The change in question is independant of the 6.7 update by the way. It was just simpler for me to implement and test. If it fixes the actual problem, I will open a dedicated pull request. |
Member
This logic is already in for a few patches (though the code changed since the linked commit). If I understand the code correctly, the computed address and size are used to reserve the memory range. If this fails, the i915 driver aborts the initialization. The amdgpu doesn’t appear to do the same reservation. Anyway, this reservation in the i915 driver is commented out on FreeBSD. linuxkpi doesn not have the called API yet. I’m not sure what it should call in FreeBSD. |
On my meteorlake system the info->aperture_base and size fields are not filled out. This seems to have something to do with my GPU having support for device local memory which doesn't get tracked in gmadr.start and mappable_end. This passes zeroes in and makes register_fictitious_range panic. This change works around this by simply not registering a fict range at all if the aperture tracking is invalid. This does have the not great side effect of garbling the framebuffer slightly but it prevents the panic and lets desktop usage happen. This workaround can be kept until we figure out what is going wrong with the framebuffer registering.
Member
|
I committed the workaround that resolves the color corruption issue. As for the fictitious memory range, is this still a problem for yor? |
Contributor
Author
|
I think it still is an issue as the memory range appears valid for me but doesn't work. This might be a MTL issue though. Your recent fixes did drastically simplify the workarounds I have to carry in my tree though so definitely an improvement. |
amshafer
added a commit
to amshafer/drm-kmod
that referenced
this pull request
Feb 25, 2026
This fixes issues with the smem_start being nonzero but invalid, which caused panics on meteorlake. The problem is that the GMADR was not getting initialized on mtl which we need in order to use shmem framebuffers. We are falling back to shmem framebuffers on freebsd because the Wa_22018444074 mtl hardware workaround disabled using stolen memory on mtl. We end up trying to use shmem but due to Wa_22018444074 GMADR is not valid so we end up with a value such as 0x2000 instead of a valid pointer. This change initializes GMADR on meteorlake. Linux has likely not run into this as they do not actually consume the physical address in smem_start like we do when we pass it to register_fictitious_range. See freebsd#324
emaste
pushed a commit
to emaste/drm-kmod
that referenced
this pull request
Apr 9, 2026
This fixes issues with the smem_start being nonzero but invalid, which caused panics on meteorlake. The problem is that the GMADR was not getting initialized on mtl which we need in order to use shmem framebuffers. We are falling back to shmem framebuffers on freebsd because the Wa_22018444074 mtl hardware workaround disabled using stolen memory on mtl. We end up trying to use shmem but due to Wa_22018444074 GMADR is not valid so we end up with a value such as 0x2000 instead of a valid pointer. This change initializes GMADR on meteorlake. Linux has likely not run into this as they do not actually consume the physical address in smem_start like we do when we pass it to register_fictitious_range. See freebsd#324
emaste
pushed a commit
to emaste/drm-kmod
that referenced
this pull request
May 4, 2026
This fixes issues with the smem_start being nonzero but invalid, which caused panics on meteorlake. The problem is that the GMADR was not getting initialized on mtl which we need in order to use shmem framebuffers. We are falling back to shmem framebuffers on freebsd because the Wa_22018444074 mtl hardware workaround disabled using stolen memory on mtl. We end up trying to use shmem but due to Wa_22018444074 GMADR is not valid so we end up with a value such as 0x2000 instead of a valid pointer. This change initializes GMADR on meteorlake. Linux has likely not run into this as they do not actually consume the physical address in smem_start like we do when we pass it to register_fictitious_range. See freebsd#324
amshafer
added a commit
to amshafer/drm-kmod
that referenced
this pull request
May 6, 2026
This fixes issues with the smem_start being nonzero but invalid, which caused panics on meteorlake. The problem is that the GMADR was not getting initialized on mtl which we need in order to use shmem framebuffers. We are falling back to shmem framebuffers on freebsd because the Wa_22018444074 mtl hardware workaround disabled using stolen memory on mtl. We end up trying to use shmem but due to Wa_22018444074 GMADR is not valid so we end up with a value such as 0x2000 instead of a valid pointer. This change initializes GMADR on meteorlake. Linux has likely not run into this as they do not actually consume the physical address in smem_start like we do when we pass it to register_fictitious_range. See freebsd#324
amshafer
added a commit
to amshafer/drm-kmod
that referenced
this pull request
May 8, 2026
This fixes issues with the smem_start being nonzero but invalid, which caused panics on meteorlake. The problem is that the GMADR was not getting initialized on mtl which we need in order to use shmem framebuffers. We are falling back to shmem framebuffers on freebsd because the Wa_22018444074 mtl hardware workaround disabled using stolen memory on mtl. We end up trying to use shmem but due to Wa_22018444074 GMADR is not valid so we end up with a value such as 0x2000 instead of a valid pointer. This change initializes GMADR on meteorlake. Linux has likely not run into this as they do not actually consume the physical address in smem_start like we do when we pass it to register_fictitious_range. See freebsd#324
amshafer
added a commit
to amshafer/drm-kmod
that referenced
this pull request
May 8, 2026
This fixes issues with the smem_start being nonzero but invalid, which caused panics on meteorlake. The problem is that the GMADR was not getting initialized on mtl which we need in order to use shmem framebuffers. We are falling back to shmem framebuffers on freebsd because the Wa_22018444074 mtl hardware workaround disabled using stolen memory on mtl. We end up trying to use shmem but due to Wa_22018444074 GMADR is not valid so we end up with a value such as 0x2000 instead of a valid pointer. This change initializes GMADR on meteorlake. Linux has likely not run into this as they do not actually consume the physical address in smem_start like we do when we pass it to register_fictitious_range. See freebsd#324
dumbbell
pushed a commit
that referenced
this pull request
May 11, 2026
This fixes issues with the smem_start being nonzero but invalid, which caused panics on meteorlake. The problem is that the GMADR was not getting initialized on mtl which we need in order to use shmem framebuffers. We are falling back to shmem framebuffers on freebsd because the Wa_22018444074 mtl hardware workaround disabled using stolen memory on mtl. We end up trying to use shmem but due to Wa_22018444074 GMADR is not valid so we end up with a value such as 0x2000 instead of a valid pointer. This change initializes GMADR on meteorlake. Linux has likely not run into this as they do not actually consume the physical address in smem_start like we do when we pass it to register_fictitious_range. See #324
emaste
pushed a commit
to emaste/drm-kmod
that referenced
this pull request
May 11, 2026
This fixes issues with the smem_start being nonzero but invalid, which caused panics on meteorlake. The problem is that the GMADR was not getting initialized on mtl which we need in order to use shmem framebuffers. We are falling back to shmem framebuffers on freebsd because the Wa_22018444074 mtl hardware workaround disabled using stolen memory on mtl. We end up trying to use shmem but due to Wa_22018444074 GMADR is not valid so we end up with a value such as 0x2000 instead of a valid pointer. This change initializes GMADR on meteorlake. Linux has likely not run into this as they do not actually consume the physical address in smem_start like we do when we pass it to register_fictitious_range. See freebsd#324
dumbbell
pushed a commit
that referenced
this pull request
May 11, 2026
This fixes issues with the smem_start being nonzero but invalid, which caused panics on meteorlake. The problem is that the GMADR was not getting initialized on mtl which we need in order to use shmem framebuffers. We are falling back to shmem framebuffers on freebsd because the Wa_22018444074 mtl hardware workaround disabled using stolen memory on mtl. We end up trying to use shmem but due to Wa_22018444074 GMADR is not valid so we end up with a value such as 0x2000 instead of a valid pointer. This change initializes GMADR on meteorlake. Linux has likely not run into this as they do not actually consume the physical address in smem_start like we do when we pass it to register_fictitious_range. See #324 (cherry picked from commit 52e96e1)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On my meteorlake system the info->aperture_base and size fields are not filled out. This seems to have something to do with my GPU having support for device local memory which doesn't get tracked in gmadr.start and mappable_end. This passes zeroes in and makes
register_fictitious_range panic.
This change works around this by simply not registering a fict range at all if the aperture tracking is invalid. This does have the not great side effect of garbling the framebuffer slightly but it prevents the panic and lets desktop usage happen. This workaround can be kept until we figure out what is going wrong with the framebuffer registering.