i915: avoid register_fictitious_range on meteorlake

[amshafer]

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.

[wulf7]

What is the value of hw.intel_graphics_stolen_size and hw.intel_graphics_stolen_base sysctls on your system? If it is zero than update sys/x86/pci/pci_early_quirks.[ch] files with your IDS

[emaste]

it is zero than update sys/x86/pci/pci_early_quirks.[ch] files with your IDS

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?

[amshafer]

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.

[dumbbell]

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.

[dumbbell]

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?

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.