# graphics/drm-kmod port or pkg installation, drm/MTRR errors & missing DMC firmware



## MasterOne (Jan 14, 2022)

A fresh 13.0-RELEASE-p6 installation with graphics/drm-kmod added as a package:


```
# dmesg | grep drm
drmn0: <drmn> on vgapci0
[drm] i915.alpha_support is deprecated, use i915.force_probe=9a49 instead
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
[drm] Got stolen memory base 0x0, size 0x0
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
drmn0: could not load firmware image 'i915/tgl_dmc_ver2_04.bin'
drmn0: Failed to load DMC firmware i915/tgl_dmc_ver2_04.bin. Disabling runtime power management.
drmn0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915<6>
[drm] Connector eDP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.eDP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] Initialized i915 1.6.0 20190822 for drmn0 on minor 0
name=drmn0 flags=0x0 stride=7680 bpp=32
drmn0: fb0: i915drmfb frame buffer device

# dmesg | grep -i mtrr
Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
Failed to add WC MTRR for [0x4000000000-0x4007ffffff]: -22; performance may suffer
```

What is it with the shown error messages:

i915.alpha_support is deprecated, use i915.force_probe=9a49 instead
Unable to create a private tmpfs mount, hugepage support will be disabled
Failed to load DMC firmware i915/tgl_dmc_ver2_04.bin. Disabling runtime power management.
Failed to add WC MTRR for [0x4000000000-0x4007ffffff]: -22; performance may suffer
I have tried adding `i915.force_probe="9a49"` and `tmpfs_load="YES"` to loader.conf(5), but that did not change anything.

The missing DMC firmware indeed can not be found in `/boot/modules` although graphics/gpu-firmware-kmod has been installed as a dependency and freebsd / drm-kmod-firmware on Github lets assume that it should have been included:


```
# ll /boot/modules | grep i915
-r-xr-xr-x  1 root  wheel    20952 Nov  4 16:42 i915_bxt_dmc_ver1_07_bin.ko*
-r-xr-xr-x  1 root  wheel   153480 Nov  4 16:42 i915_bxt_guc_ver8_7_bin.ko*
-r-xr-xr-x  1 root  wheel   167016 Nov  4 16:42 i915_bxt_huc_ver01_07_bin.ko*
-r-xr-xr-x  1 root  wheel    23792 Nov  4 16:42 i915_cnl_dmc_ver1_06_bin.ko*
-r-xr-xr-x  1 root  wheel    21368 Nov  4 16:42 i915_glk_dmc_ver1_04_bin.ko*
-r-xr-xr-x  1 root  wheel    21184 Nov  4 16:42 i915_kbl_dmc_ver1_01_bin.ko*
-r-xr-xr-x  1 root  wheel    21408 Nov  4 16:42 i915_kbl_dmc_ver1_04_bin.ko*
-r-xr-xr-x  1 root  wheel   155224 Nov  4 16:42 i915_kbl_guc_ver9_14_bin.ko*
-r-xr-xr-x  1 root  wheel   231272 Nov  4 16:42 i915_kbl_huc_ver02_00_bin.ko*
-r-xr-xr-x  1 root  wheel    21496 Nov  4 16:42 i915_skl_dmc_ver1_26_bin.ko*
-r-xr-xr-x  1 root  wheel    21496 Nov  4 16:42 i915_skl_dmc_ver1_27_bin.ko*
-r-xr-xr-x  1 root  wheel   141576 Nov  4 16:42 i915_skl_guc_ver6_1_bin.ko*
-r-xr-xr-x  1 root  wheel   160088 Nov  4 16:42 i915_skl_guc_ver9_33_bin.ko*
-r-xr-xr-x  1 root  wheel   153576 Nov  4 16:42 i915_skl_huc_ver01_07_bin.ko*
-r-xr-xr-x  1 root  wheel  2380640 Nov  4 19:02 i915kms.ko*
```

So where is the module `i915_tgl_dmc_ver2_04.bin.ko` supposed to come from?

And last but not least:

Is it still recommended to build graphics/drm-kmod from ports instead of using the package, as it is mentioned in chapter 5.4.5. Video Cards of the handbook (though why is there a package then after all)?

And if using the package, will it break again (as it happened in the past) with the upgrade from 13.0-RELEASE to 13.1-RELEASE?


----------



## SirDice (Jan 14, 2022)

MasterOne said:


> Is it still recommended to build graphics/drm-kmod from ports instead of using the package


No. As long as you stick to a -RELEASE the package will be fine.


----------



## MasterOne (Jan 14, 2022)

SirDice said:


> No. As long as you stick to a -RELEASE the package will be fine.



Are you sure about that? The manual still tells otherwise and I can remember my previous tries when the upgrade from 12.0-RELEASE to 12.1-RELEASE broke because of that, making the system unbootable.


----------



## zirias@ (Jan 14, 2022)

MasterOne said:


> Are you sure about that? The manual still tells otherwise and I can remember my previous tries when the upgrade from 12.0-RELEASE to 12.1-RELEASE broke because of that, making the system unbootable.


The problem with binary packages here can only occur when two releases of the same major version (from the same -STABLE branch) are supported at the same time. This only ever happens for a short period of time.

Binary package repositories exist per major version number. This works fine for almost all packages because the userspace ABI of FreeBSD never changes on a -STABLE branch. It can only fail for packages with kernel modules: _Inside_ the kernel, things can change even between minor releases.

So, for your case, there's currently only one FreeBSD 13 release, the binary package will work well.


----------



## SirDice (Jan 14, 2022)

MasterOne said:


> and I can remember my previous tries when the upgrade from 12.0-RELEASE to 12.1-RELEASE broke because of that, making the system unbootable.


Entirely different issue. That was because of changes in the ABI between 12.1 and 12.0 and packages being built for 12.0, which would crash on 12.1. That issue got automatically resolved when 12.0 was EoL and packages started getting built for 12.1. There's a 3 month 'grace' period when a new minor version is released, in that period packages are still being build for the lowest version.


----------



## shkhln (Jan 14, 2022)

Well, part of the issue is that the kernel ABI is supposed to be stable between minor releases and _formally it still is_, so in the typical FreeBSD bureaucratic fashion the people running the Ports are not particularly concerned about this.


----------



## zirias@ (Jan 14, 2022)

shkhln said:


> Well, part of the issue is that the kernell ABI is supposed to be stable between minor releases and _formally it still is_, so in the typical FreeBSD bureaucratic fashion the people running the Ports are not particularly concerned about this.


I think there's no such guarantee about the _in-kernel_ ABI, so this will be a recurring problem with binary packages containing kernel modules...

The ABI towards userspace _is_ stable


----------



## MasterOne (Jan 14, 2022)

shkhln said:


> Well, part of the issue is that the kernell ABI is supposed to be stable between minor releases and _formally it still is_, so in the typical FreeBSD bureaucratic fashion the people running the Ports are not particularly concerned about this.



So it will get interesting again with the upgrade from 13.0-RELEASE to 13.1-RELEASE? I can only guess that's why it is still recommended in the manual to build graphics/drm-kmod from ports:



> If you run GENERIC and use freebsd-update, you can just build the graphics/drm-kmod or x11/nvidia-driver port after each `freebsd-update install` invocation.


----------



## shkhln (Jan 14, 2022)

Zirias said:


> I think there's no such guarantee about the _in-kernel_ ABI, so this will be a recurring problem with binary packages containing kernel modules...


Here is one mention: https://markmail.org/message/bbri5puhnyinxklx.


----------



## SirDice (Jan 14, 2022)

MasterOne said:


> So it will get interesting again with the upgrade from 13.0-RELEASE to 13.1-RELEASE?


Maybe, maybe not. We'll have to wait and see. 



MasterOne said:


> I can only guess that's why it is still recommended in the manual to build graphics/drm-kmod from ports:


Because that's guaranteed to always work, on any -RELEASE, any -STABLE and any -CURRENT version.


----------



## zirias@ (Jan 14, 2022)

MasterOne said:


> So it will get interesting again with the upgrade from 13.0-RELEASE to 13.1-RELEASE?


This doesn't have to happen, but it's possible (and, IMHO kind of likely).

Either you wait with the upgrade to 13.1 until EOL of 13.0 (then the binary package will work fine), or you build the port from source for some time (3 months).


----------



## zirias@ (Jan 14, 2022)

shkhln said:


> Here is one mention: https://markmail.org/message/bbri5puhnyinxklx.


That's quite old. Maybe this has been given up meanwhile? Or there's some defined "module ABI" set that's kept stable, but something as complex as the linuxkpi module can't restrict itself to?


----------



## shkhln (Jan 14, 2022)

Zirias said:


> That's quite old. Maybe this has been given up meanwhile? Or there's some defined "module ABI" set that's kept stable, but something as complex as the linuxkpi module can't restrict itself to?


I found https://reviews.freebsd.org/rD53619, which doesn't really clarify it. But, yes, pretty much given up on linuxkpi or, at least, on the DRM video driver kmods.


----------



## grahamperrin@ (Jan 14, 2022)

> … one mention: https://markmail.org/message/bbri5puhnyinxklx.



A few hours ago I couldn't use the most recent drm-devel-kmod with a kernel from mid-November. There's more to it, but I didn't take details at the time.


----------



## MasterOne (Jan 14, 2022)

No hint about the shown error messages and missing firmware?


----------



## grahamperrin@ (Mar 3, 2022)

MasterOne said:


> No hint about the shown error messages and missing firmware?



Is it much the same with the more recent system, and more recent packages?


----------



## mer (Mar 3, 2022)

MasterOne said:


> So it will get interesting again with the upgrade from 13.0-RELEASE to 13.1-RELEASE? I can only guess that's why it is still recommended in the manual to build graphics/drm-kmod from ports:


I think it's better to say "It May get interesting, but it may not".  The 12.0 12.1 issue was the drm bits needed new kernel functionality to work, that was added for 12.1 and as explained above by SirDice binary packages are built for the lowest common denominator of a release.  So drm-kmod was expecting KABI changes that were in 12.1, but packages built against 12.0 didn't have that, so bad things happened.
So one can do what Zirias suggests or be prepared to simply build drm-kmod from source after upgrading to 13.1.  But there is usually information on the mailing lists that help tell you.

One can also develop a plan/process when doing upgrades across versions.  If you are using ZFS, create new boot environment, upgrade into that or chroot whatever you want, boot single user or to a console so you can manually load/test drm kmod, rebuild as needed.


----------

