Solved Obsolete abandonware! drm-legacy-kmod

T

trev

I installed graphics/drm-legacy-kmod-g20190213 which results in a bunch of messages when loading thus:

Code: 
Apr  8 23:54:33 tiger kernel: drmn0: =======================================================
Apr  8 23:54:33 tiger kernel: drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg
Apr  8 23:54:33 tiger kernel: drmn0: =======================================================
Apr  8 23:54:33 tiger kernel: drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers
Apr  8 23:54:33 tiger kernel: drmn0: =======================================================
Apr  8 23:54:33 tiger kernel: drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg
Apr  8 23:54:33 tiger kernel: drmn0: =======================================================
Apr  8 23:54:33 tiger kernel: drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers
Didn't I just install what it is exhorting me to install? What did I miss?
 
My guess is that you have something like kld_list="i915kms" in /etc/rc.conf when it should be kld_list="/boot/modules/i915kms" so that it loads from the pkg and not the base.
 
From /etc/rc.conf:

Code: 
# Intel Graphics
kld_list="/boot/modules/i915kms.ko"

-r-xr-xr-x 1 root wheel 724428 6 Apr 11:08 /boot/kernel/i915kms.ko
-r-xr-xr-x 1 root wheel 659756 8 Apr 22:09 /boot/modules/i915kms.ko

So I'm loading the correct module.

kldstat produces:

Code: 
Id Refs Address        Size Name
 1   36   0x800000  1aec014 kernel
 2    1  0x22ee000     71b4 uhid.ko
 3    1  0x22f6000     49fc coretemp.ko
 4    1  0x22fb000    13e60 asmc.ko
 5    1 0x19c00000    93000 i915kms.ko
 6    1 0x19c93000    4e000 drm2.ko
 7    4 0x19ce1000     7000 iicbus.ko
 8    1 0x19ce8000     5000 iic.ko
 9    1 0x19ced000     7000 iicbb.ko
10    1 0x19cf4000     9000 ums.ko
11    1 0x19cfd000     4000 mac_ntpd.ko

Maybe the culprit is the drm2.ko module from base which was dragged in by i915kms.ko ... so I added to /etc/rc.conf:

Code: 
# Intel Graphics
kld_list="/boot/modules/drm2.ko"
kld_list="/boot/modules/i915kms.ko"

But still get the warnings :(
 
I have had a similar issue and yes... the problem is that drm2 module is called as a dependency by default from the base.
This is not specifically a bug

First solution :

graphics/drm-legacy-kmod is in fact THE SAME as the default modules built into the default kernel

(to not confuse with graphics-drm-kmod which is a full port of Linux DRM Kmod driver (for intel and AMD chipset) superseding xorg drivers. Legacy FreeBSD Kmod is a specific and limited implementation of DRM-Kmod to get high resolution VT console. For "X" operations, the regular video xorg driver is required)

So, perhaps it is useless to build this port (with FreeBSD 11 & 12), just use the embedded kernel modules

Second solution

Anyway, if you want to take some benefit of "possible updates" of port version, the most elegant solution is to build a custom kernel excluding DRM modules.

In /etc/make.conf we add the line

Code: 
WITHOUT_MODULES=drm drm2

And we build a custom kernel.

It is planned for FreeBSD 13 to definitively remove DRM, KMS modules from base kernel to move them definitively to port.
This is in fact a wise solution as "kms" could initiate some unstability and should be loaded only on user request.

I never understood why, developping KMS they integrated it in base kernel as I remember that at first it was quite unstable.
Also, as FreeBSD can also be used in embedded systems without screen, there is no use to overload the kernel with "kms" which is more a "desktop" features.

We can specify drm as the only exclusion. As drm is a dependency of drm2, drm2 would be automatically excluded in any case, but stating it verbosly is much more clear. Also, note that i915kms, radeonkms... will be automatically removed as they also need drm


What you have done is a very very bad example.

One should never modify the GENERIC kernel. It can raise issue on security update (most likely "drm2" will be restablished on further updates if it doesn't break at all the update process), and "playing" with a GENERIC kernel could lead in an unbootable machine. GENERIC kernel should be kept "as it is" as a fallback kernel, alongside with a custom kernel, in case of issue with this custom kernel

This kind of behaviour is typically a behaviour of Windows users for which we find on internet tons of awfull advices in every kind of forum.

With *nix systems, one should adopt a more "professional" behaviour and moreover with FreeBSD which lets you do every kind of things.... good and bad, and bad things could make the system spin out of control.

Modifying a Linux system is more difficult as Linux is generally shipped as a distribution with standard settings.

Modifying a FreeBSD system is much more easy because this is not a distribution. FreeBSD delivers a standard base system which is not an equivalent of a distribution. Further setups are done by the user.... for the best or.... the worst. FreeBSD is expected to be used by experienced people who are "disciplined", "rigorous"... if not, the best become the worst, and such people should better revert to Linux or Windows.

You are many people who are unconsciously modifying by hand the GENERIC kernel.... don't do that !!!!!!!!!
 
Wozzeck.Live said:
graphics/drm-legacy-kmod is in fact THE SAME as the default modules built into the default kernel

So, perhaps it is useless to build this port (with FreeBSD 11 & 12), just use the embedded kernel modules
Click to expand...

In which case it would be more sensible to remove the warnings and advice to install it from the boot messages.

However, it is indeed "intended" because if you look at the relevant meta Makefile there are tests for the FreeBSD version.

What you have done is a very very bad example.
Click to expand...

I would instead suggest that the current setup for drm-legacy-kmod is a very very bad example.

You are many people who are unconsciously modifying by hand the GENERIC kernel.... don't do that !!!!!!!!!
Click to expand...

It was a deliberate and conscious act to rename the miscreant module and eliminate the warnings spamming my logs with exhortations to install what I had in fact already installed. Again, I suggest that that was the real issue and is why I lodged a PR.

Thank you for your suggested alternative workaround (the compilation of a custom kernel) which is something I will incorporate when slimming the kernel down from its current generic size.
 
Code: 
# Intel Graphics
kld_list="/boot/modules/drm2.ko"
kld_list="/boot/modules/i915kms.ko"
Click to expand...

Since rc.conf is really just shell the duplicate kld_list the second's value is used: /boot/modules/i915kms.ko.

Setting kld_list to a space separated list of .ko files you can load /boot/modules/drm2.ko.

Code: 
kld_list="/boot/modules/drm2.ko /boot/modules/i915kms.ko"
Bash: 
$ kldstat -v | fgrep -e drm2.ko -e i915kms.ko
 7    2 0xffffffff82a73000    3dc30 drm2.ko (/boot/modules/drm2.ko)
 9    1 0xffffffff82ab4000    7ad40 i915kms.ko (/boot/modules/i915kms.ko)

No obsolete messages.

So maybe PR 237127 should be updated to change graphics/drm-legacy-kmod's pkg-message to include the extra .ko file?

It seems that the loader should be a little smarter with picking .ko files. Talking to kevans91 on Freenode #freebsd it's not as simple as changing sysctl kern.module search path. Maybe if loading from /boot/modules/ look there first?
 
You must log in or register to reply here.
Back
Top