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

M

MasterOne

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

Code: 
# 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:

Code: 
# 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?
 
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.
Click to expand...
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.
 
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.
Click to expand...
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.
 
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.
 
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.
Click to expand...
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 :)
 
  • Like
Reactions: mer
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.
Click to expand...

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.
Click to expand...
 
MasterOne said:
So it will get interesting again with the upgrade from 13.0-RELEASE to 13.1-RELEASE?
Click to expand...
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).
 
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:
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top