i915: GPU hang under Vulkan stress test on Meteor Lake-P (0x7d45) with amshafer:mtl patches applied

[ocochard]

Describe the bug

After applying the patches from amshafer:mtl to drm-kmod master HEAD, the i915 driver loads cleanly and brings up the display on Meteor Lake-P, but the GPU wedges (and eventually locks the entire system, including keyboard input) when running the Vulkan test suite graphics/crucible (it works great with vkcube, vlc, chromium).

The cosmetic init errors are gone (no more "Enabling uc failed (-5)"), the Skipping GT1 message confirms patch 2 is active, and GuC firmware loads in HuC-auth-only mode (enable_guc=2). 2D/desktop usage looks fine. The hang only triggers under sustained Vulkan compute/render load.

FreeBSD version

• FreeBSD 16.0-CURRENT, kernel main-n285626-9c18d55a768a built 2026-05-01
• drm-kmod master a72c05b22dc21e4a68b0146d85d1ec0be4470931
• Plus 2 cherry-picks from amshafer:mtl:
  • a2ca1d5 intel: initialize GMADR on meteorlake and newer on freebsd
  • 0872ce4 intel: disable GT1 (Media chip) on FreeBSD
• gpu-firmware-intel-kmod-meteorlake 20260501
  • /boot/loader.conf: hw.i915kms.enable_guc=2
  • Test runner: graphics/crucible (Vulkan CTS-style)

PCI Info

pciconf -lv

vgapci0@pci0:0:2:0:     class=0x030000 rev=0x08 hdr=0x00 vendor=0x8086 device=0x7d45 subvendor=0x17aa subdevice=0x231e
    vendor     = 'Intel Corporation'
    device     = 'Meteor Lake-P [Intel Graphics]'
    class      = display
    subclass   = VGA

DRM KMOD version
Builded myself:

drm-latest-kmod 6.12.1600018_2

Module load great (hw.i915kms.enable_guc=2 in /boot/loader.conf)

drmn0: <drmn> on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
drmn0: [drm] Found METEORLAKE (device ID 7d45) display versio
drmn0: successfully loaded firmware image 'i915/mtl_dmc.bin'
drmn0: [drm] Finished loading DMC firmware i915/mtl_dmc.bin (v2.23)
drmn0: successfully loaded firmware image 'i915/mtl_guc_70.bin'
drmn0: [drm] GT0: GuC firmware i915/mtl_guc_70.bin version 70.53.0
drmn0: [drm] GT0: GUC: submission disabled
drmn0: [drm] GT0: GUC: SLPC disabled
[drm] Initialized i915 1.6.0 for drmn0 on minor 0
VT: Replacing driver "efifb" with new "drmfb".
start FB_INFO:
height=1800 width=2880 depth=32
pbase=0x90800000 vbase=0xfffff80090800000
name=drmn0 id=i915drmfb flags=0x0 stride=11520
end FB_INFO

To Reproduce
Steps to reproduce the behavior:

pkg install crucible
crucible run

[emaste]

I am testing on TigerLake-LP with 6.12-lts (0840ef2) plus the changes in #418 and experience somewhat regular GPU wedging, generally during just regular browser use. (I have not tested 6.12-lts w/o #418 changes.)

[27414.760579] drmn0: [drm] GPU HANG: ecode 12:1:85dfffff, in MainThread [101573]
[27414.846949] drmn0: [drm] Resetting rcs0 for preemption time out
[27414.847059] drmn0: [drm] Xorg[101573] context reset due to GPU hang
[27422.375248] drmn0: [drm] GPU HANG: ecode 12:1:85dfbfff, in Renderer [101649]
[27422.453880] drmn0: [drm] Resetting rcs0 for preemption time out
[27422.453983] drmn0: [drm] Renderer[101649] context reset due to GPU hang
[27427.242126] Fence expiration time out i915-drmn0:Renderer[101649]:5f18a!
[27429.239127] Fence expiration time out i915-drmn0:Renderer[101649]:5f18c!
[27429.972399] drmn0: [drm] GPU HANG: ecode 12:1:85dfffff, in MainThread [101573]
[27430.058882] drmn0: [drm] Resetting rcs0 for preemption time out
[27430.059007] drmn0: [drm] MainThread[101573] context reset due to GPU hang
[27437.653736] drmn0: [drm] GPU HANG: ecode 12:1:859ffffb, in MainThread [101573]
[27437.738885] drmn0: [drm] Resetting rcs0 for preemption time out
[27437.739008] drmn0: [drm] MainThread[101573] context reset due to GPU hang
[27446.802786] drmn0: [drm] Resetting rcs0 for preemption time out
[27446.802915] drmn0: [drm] Renderer[101649] context reset due to GPU hang
[27446.827460] drmn0: [drm] GPU HANG: ecode 12:1:85dffffb, in Renderer [101649]
[27454.534741] drmn0: [drm] Resetting rcs0 for preemption time out
[27454.557951] drmn0: [drm] GPU HANG: ecode 12:1:84dffefa, in Renderer [101649]
[27467.007856] Fence expiration time out i915-drmn0:Renderer<101649>:2!
[27467.070786] Fence expiration time out i915-drmn0:Renderer[101649]:4!
[27467.089501] Fence expiration time out i915-drmn0:Renderer[101649]:6!
[27467.104521] Fence expiration time out i915-drmn0:Renderer[101649]:8!
[27467.130124] Fence expiration time out i915-drmn0:Renderer[101649]:a!
[27467.317610] Fence expiration time out i915-drmn0:Renderer[101649]:c!

[amshafer]

@emaste on tigerlake you should be able to disable and rule out GuC since it's not required on that arch afaict. I'd be curious if you still see wedging if you revert commit a72c05b. I wonder if that exposed some new (bad) behavior.

[emaste]

It seems GuC is disabled already, in dmesg I see [4.558729] drmn0: __confirm_options: GT0: enable_guc=0 (guc:no submission:no huc:no slpc:no)

My branch also has 8898179 drm/i915: Increase I915_PARAM_MMAP_GTT_VERSION version to indicate support for partial mmaps.

I will try with both reverted, back to i915_gem_mmap_gtt_version returning 3.

[emaste]

@amshafer yes with 8898179 and a72c05b reverted the GPU hangs do not occur.

That is, i915_gem_mmap_gtt_version is back to just

int i915_gem_mmap_gtt_version(void)
{
#ifdef __FreeBSD__not_yet
        return 4;
#else
        return 3;
#endif
}