drm/i915: fix FreeBSD Arc A770 load blockers#468
Open
ryanfahy314 wants to merge 2 commits into
Open
Conversation
added 2 commits
June 5, 2026 01:12
Found that in the LinuxKPI scatterlist.h, there is a preproscessor macro that aliases sg_dma_len(sg) with sg->length In the i915_scatterlist.c, there are two instances of the pattern: sg->length += len sg_dma_len(sg) += len Which causes the variable to double increment on FreeBSD and causes the i915kms driver to cause a kernel panic on load. In the observed crash, sg->length was 0x20000 while the related object size was 0x10000 Update i915_rsgt_from_mm_node() and i915_rsgt_from_buddy_resource() so that on FreeBSD, only sg_dma_len(sg) is incremented to avoid the double increment. Built and tested on FreeBSD 15.1-STABLE and this change allows the i915kms driver to load with enable_guc=1. Signed-off-by: Ryan Fahy <ryan@rfahy.com>
On FreeBSD, CPU visible memory needs to be registered as fictitious vm_page_t metadata so PFN lookups can resolve. The current i915 implementation only registers the fbdev framebuffer range. On Intel Arc DG2 GPUs, mappings outside of the fbdev range can touch PFNs that do not thave corresponding metadata because the CPU-vibile LMEM BAR aperture exceeds the framebuffer registered range This patch registers the full CPU-visible LMEM aperture range during LMEM initialization using mem->io.start and resource_size(&mem->io) Because the i915 driver already included logic to initalize the framebuffer range, preserve that behavior as a fallback. Added a fictitious_range_registered bool to both the intel_memory_region struct and the intel_fbdev struct. Each bool tracks whether or not a fictitious range was registered by lmem or by fbdev. The intended behavior is: 1) LMEM Initialization -> If ddev->fictitious_range_registerd is false, proceed to register the CPU visible LMEM aperture and set intel_memory_region->fictitious_range_registered true 2) FBDEV Initialization -> If ddev->fictitious_range_registered is false, meaning LMEM didn't initialize anything, initialize just the small framebuffer memory region and set intel_fbdev->fictitious_range_registered to true 3) On FBDEV cleanup, check intel_fbdev->fictitious_range_registered to see whether fbdev was the one to register the range. If so, call the unregister function 4) On LMEM cleanup, check intel_memory_region->fictitious_range_registered to establish whether LMEM was the one to register the range. If so, call the unregister function. Also modify drm_os_freebsd so that unregister_fictitious_range() clears ddev->fictitious_range_registered. register_fictitious_range() also now only sets ddev->fictitious_range_registered if the range was registered succesfully. If registration fails, clean up with vt_unfreeze_main_vd() and return the error status Tested on FreeBSD 15.1-STABLE with an Intel Arc A770/DG2. i915kms loads, DMC and GuC load, /dev/dri/card0 and /dev/dri/renderD128 appear, Xorg is able to use the modesetting driver, and SDDM and Plasma work with AccelMethod none. Hardware acceleration still appears to be unstable on DG2, but does not appear to be caused by this patch. Signed-off-by: Ryan Fahy <ryan@rfahy.com>
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
1 participant
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.
Related to #315.
Summary
This PR contains two i915 fixes found while debugging Intel Arc A770 / DG2 support on 15.1-STABLE.
Changes
In the LinuxKPI
scatterlist.h, there is a preprocessor macro that aliasessg_dma_len(sg)as(sg)->length.In
linuxkpi/common/include/linux/scatterlist.h:However, in
drivers/gpu/drm/i915/i915_scatterlist.c, there are two instances with the pattern:On FreeBSD, this was causing the
sg->lengthto increment twice, leading to a kernel panic onkldload i915kmsThe existing i915 FreeBSD fbdev handling registers a small framebuffer range.
On DG2, the CPU-visible aperture is larger than the fbdev range, so mappings can touch PFNs that do not have corresponding
vm_page_tmetadata.This patch registers the CPU-visible LMEM BAR aperture during LMEM initialization, and also preserves fbdev registration as a fallback. LMEM and fbdev now each track whether they own the fictitious range, and cleanup only unregisters from the path that registers it.
I tried to follow the precedent set by the amdgpu driver for calling the
register_fictitious_range()andunregister_fictitious_range()helpers. The i915 case needed some additional ownership handling logic because the fbdev path can register a small framebuffer range (on my system it was about 8 MiB).Testing
i915kmsloads.hw.i915kms.enable_guc=1./dev/dri/card0and/dev/dri/renderD128are created.AccelMethod "none".Known Limitations
These changes appear to be stable on my system with
AccelMethod "none".Using hardware acceleration works initially, but I experienced two crashes with hardware acceleration enabled, one after about an hour of uptime and the other after about 5 minutes of uptime. After the crash, dmesg reports the following:
I'm currently not sure what's causing the instability, but my current assumption is that it is a failure further in the hardware acceleration pipeline. However, I thought it was best to disclose in case it is relevant to review.
Waking from sleep also appears to fail at the moment
Contributor Note
For transparency, AI assistance was used in a limited scope during discovery and debugging. This included debugging, source navigation guidance, log/crashdump analysis, and temporary instrumentation of certain functions to gather information (all temporary instrumentation was reverted). Any behavioral code was written manually. All code changes were written, reviewed, built, and tested by me. Documentation, PR body and commit text, and code comments were all written manually by me with AI review for accuracy.