No support for drm via HEAD drm-kmod for Meteor Lake?

Hey folks, I got a new laptop because my interest in FreeBSD has grown big enough that using an old beater laptop won't work.

I'm after S3 when lid close and a graphics driver for Wayland/X, but I can't get a driver for my Meteor Lake system to work. I'm thinking the sources aren't able to support this relatively new hadware?

I've tried building the module from 15.0-CURRENT source and from building from the separate drm-kmod project. When kldloaded these modules turn the screen black. Keyboard still functional (I can type 'reboot' :)).

I was grasping at straws and the logfile is pretty negative. I can use the laptop to do console stuff (and that's great!). But I'd like to have a sharper VT console and...eventually wayland/Xorg. Has anyone gotten this working/am I missing something -- or do i just need to wait? Here's the logfile for reference.

Code:
May 12 14:30:55 zenbsd kernel: [drm] Got Intel graphics stolen memory base 0x0, size 0x0
May 12 14:30:55 zenbsd kernel: drmn0: <drmn> on vgapci0
May 12 14:30:55 zenbsd kernel: drmn0: Force probing unsupported Device ID 7dd5, tainting kernel
May 12 14:30:55 zenbsd kernel: vgapci0: child drmn0 requested pci_enable_io
May 12 14:30:55 zenbsd syslogd: last message repeated 1 times
May 12 14:30:55 zenbsd kernel: drmn0: [drm] No GSC FW selected, disabling GSC CS and media C6
May 12 14:30:55 zenbsd kernel: drmn0: [drm] *ERROR* Unexpected child device config size 40 (expected 39 for VBT version 256)
May 12 14:30:55 zenbsd kernel: drmn0: successfully loaded firmware image 'i915/mtl_dmc.bin'
May 12 14:30:55 zenbsd kernel: drmn0: [drm] Finished loading DMC firmware i915/mtl_dmc.bin (v2.23)
May 12 14:30:55 zenbsd kernel: lkpi_iic0: <LinuxKPI I2C> on drmn0
May 12 14:30:55 zenbsd kernel: iicbus2: <Philips I2C bus> on lkpi_iic0
May 12 14:30:55 zenbsd kernel: iic2: <I2C generic I/O> on iicbus2
May 12 14:30:55 zenbsd kernel: lkpi_iic1: <LinuxKPI I2C> on drmn0
May 12 14:30:55 zenbsd kernel: iicbus3: <Philips I2C bus> on lkpi_iic1
May 12 14:30:55 zenbsd kernel: iic3: <I2C generic I/O> on iicbus3
May 12 14:30:55 zenbsd kernel: lkpi_iic2: <LinuxKPI I2C> on drmn0
May 12 14:30:55 zenbsd kernel: iicbus4: <Philips I2C bus> on lkpi_iic2
May 12 14:30:55 zenbsd kernel: iic4: <I2C generic I/O> on iicbus4
May 12 14:30:55 zenbsd kernel: lkpi_iic3: <LinuxKPI I2C> on drmn0
May 12 14:30:55 zenbsd kernel: iicbus5: <Philips I2C bus> on lkpi_iic3
May 12 14:30:55 zenbsd kernel: iic5: <I2C generic I/O> on iicbus5
May 12 14:30:55 zenbsd kernel: lkpi_iic4: <LinuxKPI I2C> on drmn0
May 12 14:30:55 zenbsd kernel: iicbus6: <Philips I2C bus> on lkpi_iic4
May 12 14:30:55 zenbsd kernel: iic6: <I2C generic I/O> on iicbus6
May 12 14:30:55 zenbsd kernel: lkpi_iic5: <LinuxKPI I2C> on drmn0
May 12 14:30:55 zenbsd kernel: iicbus7: <Philips I2C bus> on lkpi_iic5
May 12 14:30:55 zenbsd kernel: iic7: <I2C generic I/O> on iicbus7
May 12 14:30:55 zenbsd kernel: lkpi_iic6: <LinuxKPI I2C> on drmn0
May 12 14:30:55 zenbsd kernel: iicbus8: <Philips I2C bus> on lkpi_iic6
May 12 14:30:55 zenbsd kernel: iic8: <I2C generic I/O> on iicbus8
May 12 14:30:55 zenbsd kernel: lkpi_iic7: <LinuxKPI I2C> on drmn0
May 12 14:30:55 zenbsd kernel: iicbus9: <Philips I2C bus> on lkpi_iic7
May 12 14:30:55 zenbsd kernel: iic9: <I2C generic I/O> on iicbus9
May 12 14:30:55 zenbsd kernel: lkpi_iic8: <LinuxKPI I2C> on drmn0
May 12 14:30:55 zenbsd kernel: iicbus10: <Philips I2C bus> on lkpi_iic8
May 12 14:30:55 zenbsd kernel: iic10: <I2C generic I/O> on iicbus10
May 12 14:30:55 zenbsd kernel: drmn0: [drm] *ERROR* GT0: Enabling uc failed (-5)
May 12 14:30:55 zenbsd kernel: drmn0: [drm] *ERROR* GT0: Failed to initialize GPU, declaring it wedged!
May 12 14:30:55 zenbsd kernel: drmn0: [drm:0xffffffff83932480s] 0xfffffe0127c617f8V
 
14.2+drm-*-kmod from sources (I compiled from the quarterly branch).
66th version only for 15th.
Then we lock the drm-*-kmod package, load it manually (if you didn't make BE in advance).
 
I’m sorry but I don’t quite follow but i think this says:

Look in the quarterly branch
Find 14.2+drm-*-kmod
Since I’m on 15x, only compile the 66 module

Is that right?

The next part I’m not sure of how to lock a version. I am loading my 15x OS in a BE. I think you’re advising that if I don’t put the load in rc.conf, I’ll have to do it manually?

I don’t follow the idea of locking. Can you explain?
 
14.2+drm-*-kmod from sources
It's not likely that drm-61-kmod on 14.2 has Meteor Lake support (drm-66-kmd with modified Makefile was reported to work on 14.2, but the user reverted to 6.1 because 6.6 produced "lots of errors ).

According to https://en.wikipedia.org/wiki/Linux_kernel_version_history#Releases_6.x.y Meteor Lake was declared stable on Linux 6.7.

I've tried building the module from 15.0-CURRENT source and from building from the separate drm-kmod project.
From those drm-kmod projects you have tried does it include dumbbell/drm-kmod linuxkpi 6.8? There is a "How to test" guide from the "Update to Linux 6.8 drivers" drm-kmod pull request.

I believe you don't need to use the dumbbell/freebsd-src . Several linuxkpi related changes have been committed, including dumpbell source latest commit "linuxkpi: Add folio and folio_batch APIs" have been committed to main.

Edit: On second thought, better stick to dumbbell/src. "drm-related-linuxkpi-changes" branch to make sure to use where linuxkpi 6.8 was tested on, then, eventually test on main official.

I don't know if the commits have an improving effect, even with Linux 6.8 there are instability reports, including panicking with Meteor Lake(-P) back a month ago (see comments).
 
First, T-Daemon, thank you (as ever) for the thoughtful reply with an action plan. And thank you to fmc000 for hope and USerID for more context. Here's where we ended up.

Code:
May 13 15:41:32 zenbsd kernel: drmn0: <drmn> on vgapci0
May 13 15:41:32 zenbsd kernel: drmn0: [drm] GT0: Incompatible option enable_guc=-1 - undocumented flag
May 13 15:41:32 zenbsd kernel: drmn0: [drm] GT1: Incompatible option enable_guc=-1 - undocumented flag
May 13 15:41:32 zenbsd kernel: drmn0: [drm] *ERROR* Unexpected child device config size 40 (expected 39 for VBT version 256)
May 13 15:41:32 zenbsd kernel: drmn0: successfully loaded firmware image 'i915/mtl_dmc.bin'
May 13 15:41:32 zenbsd kernel: drmn0: [drm] Finished loading DMC firmware i915/mtl_dmc.bin (v2.23)
May 13 15:41:32 zenbsd kernel: drmn0: successfully loaded firmware image 'i915/mtl_guc_70.bin'
May 13 15:41:32 zenbsd kernel: drmn0: successfully loaded firmware image 'i915/mtl_huc_gsc.bin'
May 13 15:41:32 zenbsd kernel: drmn0: successfully loaded firmware image 'i915/mtl_gsc_1.bin'
May 13 15:41:32 zenbsd kernel: drmn0: [drm] GT0: GuC firmware i915/mtl_guc_70.bin version 70.44.1
May 13 15:41:32 zenbsd kernel: drmn0: [drm] GT0: GUC: submission enabled
May 13 15:41:32 zenbsd kernel: drmn0: [drm] GT0: GUC: SLPC enabled
May 13 15:41:32 zenbsd kernel: drmn0: [drm] GT0: GUC: RC enabled
May 13 15:41:39 zenbsd kernel: drmn0: [drm] GPU HANG: ecode 12:0:00000000

Further content at GitHub (https://github.com/freebsd/drm-kmod/pull/344#issuecomment-2879174973)

I'm thinking the enable_guc calls aren't fatal given that we load the firmware below. I'm going to try to debug from the HANG line, but I feel like we're close...but not quite there.
 
Back
Top