kernel: drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg

[Per Hedeland]

On 2019-12-30 18:35, Polytropon wrote:
> On Mon, 30 Dec 2019 11:49:45 +0100, Per Hedeland wrote:
>> On 2019-12-30 10:08, Victor Sudakov wrote:
>>> Polytropon wrote:
>>>>>>>> On Mon, 30 Dec 2019 11:57:40 +0700, Victor Sudakov wrote:
>>>>>>>>> On an "HP ProBook 6560b" notebook running FreeBSD 12.1, I've installed
>>>>>>>>> graphics/drm-kmod and loaded it via
>>>>>>>>> kld_list="/boot/modules/radeonkms.ko" in rc.conf. The X server even works OK.
>>>>>>>>>
>>>>>>>>> # pkg which "/boot/modules/radeonkms.ko"
>>>>>>>>> /boot/modules/radeonkms.ko was installed by
>>>>>>>>> package drm-fbsd12.0-kmod-4.16.g20191120
>>>>>>>>>
>>>>>>>>> However, the kernel complains:
>>>>>>>>>
>>>>>>>>> "kernel: drmn0: This code is obsolete abandonware.
>>>>>>>>> Install the graphics/drm-legacy-kmod pkg"
>>>>>>>>>
>>>>>>>>> Is this some kind of bug?
>>
>> The message is from the in-kernel drm version, not the one installed
>> by the package - from a 12.1-RELEASE +
>> drm-fbsd12.0-kmod-4.16.g20191120 (built from the port) install:
>>
>> $ strings -f /boot/kernel/drm*.ko | grep obsolete
>> /boot/kernel/drm.ko: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg
>> /boot/kernel/drm2.ko: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg
>>
>> $ strings -f /boot/modules/drm*.ko | grep obsolete
>>
>> When you load one of the hardware-specific modules from the package
>> (as you do with the recommended kld_list setting in rc.conf), it will
>> in turn load /boot/modules/drm.ko (from the package) - at least that
>> happens with i915kms.ko that I'm using.
> 
> Very strange. I'm also using the explicit loading method for
> i915kms.ko (installed via pkg) and still get the abandonware
> message. I did not install drm-legacy-kmod, but drm-kmod, and
> per your definition (and my now grown understanding, thanks)
> this should have installed and loaded (!) drm.ko from the
> package, not the OS one.

Well, what can I say - "it works for me":-) (and actually for at least
some other users). And I believe it should be expected to work. Are
you sure you don't have an explicit "load instruction" somewhere that
ends up loading /boot/kernel/drm.ko? I guess it could also be a
"secondary/dependent" load - e.g. if you load i915kms without path
somewhere, it will (attempt to) load /boot/kernel/i915kms.ko, and
presumably pull in /boot/kernel/drm.ko.

>> Are you loading a drm module explicitly somehow? E.g. 'kld_load drm'
>> or equivalent loads the in-kernel version by default, based on:
>>
>> $ sysctl kern.module_path
>> kern.module_path: /boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays
> 
> Is it suggested to "manually" load drm.ko with the kld_list=
> setting in /etc/rc.conf, in addition to the graphics driver
> fitting the hardware?

I have not seen such a suggestion from the maintainers of the "new
drm". In a past discussion, not sure if it was here or in x11@,
someone ("a") did suggest it, someone else ("b") pointed out that it
wasn't necessary, and "a" reported back that it worked without.

I guess it may be considered a matter of taste - personally I prefer
to tell the kernel as little as possible about which modules to load,
and have it figure things out from the existing hardware and inter-
module dependencies, except for the cases where that just
doesn't/can't work. Wanting to have "absolute control" and spell
everything out is also a valid approach, but it seems to me that it
has a higher risk of breaking due to updates.

>>>>>>>> No, it's intended. You'll also see such warnings during
>>>>>>>> the boot process and in the system message log file.
>>>>>>>>
>>>>>>>
>>>>>>> It cannot be intended with graphics/drm-kmod installed which is by
>>>>>>> definition not "legacy" or "obsolete". Quite the opposite, it should be
>>>>>>> the newer driver.
>>
>> Correct, see above.
> 
> In that case, the description shown on FreshPorts (see quotes
> in my previous replies) is misleading, isn't it?

Here is the initial part again (it's also in
graphics/drm-kmod/pkg-descr):

    amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS
    components on amd64, i915 and radeonkms DRM modules from the former
    base DRM component on other architectures.

It's not entirely trivial to parse, but after a reading it a few times
(and double-checking the port's Makefile:-), I believe it is saying:

For amd64:

    amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS
    components

For other architectures:

    i915 and radeonkms DRM modules from the former base DRM component

I.e. the "really" new stuff is only for amd64, for other architectures
you get a "forward-port" of the old stuff.

>>>>>> Not really. From the description:
>>>>>>
>>>>>> 	amdgpu, i915, and radeon DRM modules for the
>>>>>> 	linuxkpi-based KMS components on amd64, i915
>>>>>> 	and radeonkms DRM modules from the former
>>>>>> 	base DRM component on other architectures.
>>>>>>
>>>>>> 	Metaport for different versions of Linux
>>>>>> 	DRM based on the FreeBSD version in use.
>>>>>>
>>>>>> This port is a meta-port of the drivers previously contained
>>>>>
>>>>> Which "this port", graphics/drm-legacy-kmod (which I don't have
>>>>> installed) or graphics/drm-kmod (which I have installed)?
>>>>
>>>> The graphics/drm-kmod (installed) = "old drivers" at the
>>>> moment;
>>
>> No - as mentioned this is a meta-port, which will actually install the
>> current version of graphics/drm-fbsd12.0-kmod if you are running 12.x.
> 
> Does graphics/drm-kmod do more than install graphics/drm-fbsd12.0-kmod?
> If no - why is there a meta-port installing just one other port?

I believe the idea is that drm-kmod should figure out *which* other
port to install (based on amd64 arch or not, as well as based on
FreeBSD version for amd64 - see the Makefile), to save the user the
trouble.

In yet another discussion, it was suggested that using a meta-port for
this was a Bad Idea(tm) - I'm not sure whether it is, at least when
installing it seems very convenient to me. There are some strange
behaviors for e.g. 'delete' and 'reinstall', but it seems to me that
they are a general consequence of how meta-ports are implemented
(i.e. all meta-ports "suffer" from those).

--Per