Can't log in with graphics/drm-515-kmod

J

jasmineitg

Today is my first day with FreeBSD, so forgive me if I've missed something or am misunderstanding the distinction of these packages graphics/drm-510-kmod and graphics/drm-515-kmod. I assumed that would be better

For reference, I've just installed 14.1-RELEASE on my Dell Precision T3610. This computer is fully stock except for the presence of an AMD Oland GPU (Radeon R7 430). I followed these guides to get GNOME working from a fresh install.

Code: 
pkg update
pkg install gnome xorg 
sysrc gnome_enable="YES" && sysrc gdm_enable="YES" && sysrc dbus_enable="YES"
echo "exec gnome-session" > ~/.xinitrc

After this, the system could start into GNOME with no problem.

Then I tried replacing graphics/drm-510-kmod with graphics/drm-515-kmod, and the system would panic, so I had to boot into single user mode to disable the xinitrc code. After replacing graphics/drm-515-kmod with graphics/drm-510-kmod, everything was working again.
 
There's a meta port graphics/drm-kmod that depends on the recommended version of drm modules for your FreeBSD release. Unless you experience graphics problems, I would go with that. As a bonus, it updates when the recommended drm version changes, e.g. on system upgrade.

Is ~/.xinitrc really needed when using gdm login manager? Other login managers don't require that, but I'm not familiar with gdm.
 
noise said:
There's a meta port graphics/drm-kmod that depends on the recommended version of drm modules for your FreeBSD release. Unless you experience graphics problems, I would go with that. As a bonus, it updates when the recommended drm version changes, e.g. on system upgrade.

Is ~/.xinitrc really needed when using gdm login manager? Other login managers don't require that, but I'm not familiar with gdm.
Click to expand...
1. I didn't have any luck getting X to start until I had already installed graphics/drm-510-kmod when following the other thread, but I think the exact rc.conf line from https://forums.freebsd.org/threads/does-freebsd-13-1-support-radeon-r7-m265.85882/post-576850 was what I needed to get working. I'll try removing 510, re-install the meta port, and see if it keeps working.

2. I have not tried without the xinitrc file.
 
jasmineitg said:
hen I tried replacing graphics/drm-510-kmod with graphics/drm-515-kmod, and the system would panic,
Click to expand...
The system panics because of kernel module and kernel version mismatch.

Those kmod packages provide video driver kernel modules. Those modules are build against the systems kernel version. For the time being official packages are build against version 14.0 until it reaches end-of-life in September.

14.1 kmods need to be build from ports with the 14.1 system source code installed.
 
It's possible (not 100% sure) that drm-515 does not include firmware package for gpus, whereas drm-510 does include them. It was a change iirc when 515 was release. if you run

# pkg search gpu-firmware

It will list the available packages and you would need to install the one for your gpu, but I don't remember how to find that out, as I had a linux liveusb at the time and I got the info from that.
 
T-Daemon said:
The system panics because of kernel module and kernel version mismatch.

Those kmod packages provide video driver kernel modules. Those modules are build against the systems kernel version. For the time being official packages are build against version 14.0 until it reaches end-of-life in September.

14.1 kmods need to be build from ports with the 14.1 system source code installed.
Click to expand...
About building drm-?-kmod from ports should be in handbook or in installation instruction.
Users including myself which using package expected that is drm-515-kmod build on 14.1 version of FreeBSD.
 
jasmineitg said:
1. I didn't have any luck getting X to start until I had already installed graphics/drm-510-kmod when following the other thread, but I think the exact rc.conf line from https://forums.freebsd.org/threads/does-freebsd-13-1-support-radeon-r7-m265.85882/post-576850 was what I needed to get working. I'll try removing 510, re-install the meta port, and see if it keeps working.
Click to expand...

Regarding that other thread, as was noted there kld_list="amdgpu" should be fully sufficient. The x11-drivers/xf86-video-amdgpu package is unnecessary. And I stand corrected here, the most reliable method for the drm kernel modules is to install the graphics/drm-kmod from ports, or to build a package on a machine with the same kernel version.

T-Daemon said:
The system panics because of kernel module and kernel version mismatch.

Those kmod packages provide video driver kernel modules. Those modules are build against the systems kernel version. For the time being official packages are build against version 14.0 until it reaches end-of-life in September.

14.1 kmods need to be build from ports with the 14.1 system source code installed.
Click to expand...

You're right. Funny enough, the graphics/drm-61-kmod as the recommended drm module for 14.1 doesn't even get built because the package builder is still on 14.0 - same goes for the graphics/drm-kmod meta package which still depends on the 14.0 recommended graphics/drm-515-kmod.

I hope this unfortunate situation gets tackled when we get the base system in package form.
 
T-Daemon said:
The system panics because of kernel module and kernel version mismatch.

Those kmod packages provide video driver kernel modules. Those modules are build against the systems kernel version. For the time being official packages are build against version 14.0 until it reaches end-of-life in September.

14.1 kmods need to be build from ports with the 14.1 system source code installed.
Click to expand...

noise said:
Regarding that other thread, as was noted there kld_list="amdgpu" should be fully sufficient. The x11-drivers/xf86-video-amdgpu package is unnecessary. And I stand corrected here, the most reliable method for the drm kernel modules is to install the graphics/drm-kmod from ports, or to build a package on a machine with the same kernel version.



You're right. Funny enough, the graphics/drm-61-kmod as the recommended drm module for 14.1 doesn't even get built because the package builder is still on 14.0 - same goes for the graphics/drm-kmod meta package which still depends on the 14.0 recommended graphics/drm-515-kmod.

I hope this unfortunate situation gets tackled when we get the base system in package form.
Click to expand...
Thanks to all for the assistance. :)

One thing I may be misunderstanding though, shouldn't I be avoiding use of the meta package if it's not providing the correct driver for my 14.1-RELEASE kernel?

From what I understand drm-61-kmod should work though so I will try it and report back.
 
fmc000 said:
Unless the amdgpu situation is different than i915kms this is not true as I'm running 14.1 with 61 compiled from ports.
Click to expand...
You misunderstood noise. What he meant was that there is no drm-61-kmod package build on the official package build server for 14.1.

The package is excluded from build for all supported versions due to missing kernel support, except 14.1-RELEASE, 14.1-STABLE and 15-CURRENT.

ports/graphics/drm-61-kmod/Makefile
Rich (BB code): 
29 .if ${OPSYS} == FreeBSD && !( ${OSVERSION} >= 1500008 || ( ,${OSVERSION} >= 1400508 && ${OSVERSION} < 1500000 ))
30 IGNORE=         not supported on older than 14-STABLE 1400508, no kernel support
(OSVERSION above 1400508 is support. 14.1-p1 is at 1401000, 14.0p8 at 1400097. Check your kernel version with uname -K)

Packages for the 14 branch are build on the official build server for the least supported version, 14.0 in this case. That's why there is no package for 14.1 for the time being, until 14.0 reaches end-of-life on Semptember 30. After that date all 14 branch packages are build for 14.1.

Currently only 15.0-CURRENT gets a package built.
 
T-Daemon said:
You misunderstood noise. What he meant was that there is no drm-61-kmod package build on the official package build server for 14.1.

The package is excluded from build for all supported versions due to missing kernel support, except 14.1-RELEASE, 14.1-STABLE and 15-CURRENT.

ports/graphics/drm-61-kmod/Makefile
Rich (BB code): 
29 .if ${OPSYS} == FreeBSD && !( ${OSVERSION} >= 1500008 || ( ,${OSVERSION} >= 1400508 && ${OSVERSION} < 1500000 ))
30 IGNORE=         not supported on older than 14-STABLE 1400508, no kernel support
(OSVERSION above 1400508 is support. 14.1-p1 is at 1401000, 14.0p8 at 1400097. Check your kernel version with uname -K)

Packages for the 14 branch are build on the official build server for the least supported version, 14.0 in this case. That's why there is no package for 14.1 for the time being, until 14.0 reaches end-of-life on Semptember 30. After that date all 14 branch packages are build for 14.1.

Currently only 15.0-CURRENT gets a package built.
Click to expand...
Understood, thanks for taking the time to explain it so thoroughly. I'm in my third week of using FreeBSD and I have of course a lot to learn about it.
 
T-Daemon said:
Even with pkgbase there will be a 3 month periode between a branches major upgrade introduction and end-of-life of the lesser version.
Click to expand...
I think that is probably true, but I'm lacking further info on pkgbase in this particular kernel API area where graphics drivers are concerned.

It could be that that those packages are "pulled into" the base-install once again (and therefore will be removed from the ports tree). That would create a possibility for better management of those particular kernel modules that have a dependence on a (relatively) highly changing graphics shim layer in the kernel because FreeBSD has to chase the changes of its LINUX graphics KAPI counterpart. Again, that's speculative on my part because I have no idea what will be chosen by pkgbase in this matter.

IMO the "3 month package problem"* could be solved by Optional sub-indexing by minor version for packages when those graphics drivers remain in the ports tree; perhaps even a (temporary) FLAVOR-ed version, one for 14.0 and one for 14.1, could help. I find the current situation rather unsatisfactory: it is not documented in the Handbook and users depending on these (admittedly very few packages) must resort to building the packages from ports. The latter is something that isn't the general inclination of the FreeBSD Handbook that tends to favor pkg package management and advises not to mix ports and packages (a very good rule for all those not needing the possible hassle of version dependency management for that mix).

* This may also, rightly or wrongly, deter users from upgrading their system to the most recent supported minor version and wait until the 3 month overlap period (of two supported minor versions of the same major version) has come to an end.
 
jasmineitg said:
One thing I may be misunderstanding though, shouldn't I be avoiding use of the meta package if it's not providing the correct driver for my 14.1-RELEASE kernel?

From what I understand drm-61-kmod should work though so I will try it and report back.
Click to expand...

The meta port does the right thing for the machine it is built on. With packages from the official repos, the problem is that they are built on a machine with 14.0-RELEASE kernel. Means if you install the meta port through pkg install drm-kmod from the official repo, not only will it depend on drm-515-kmod (recommended for 14.0-RELEASE) instead of drm-61-kmod (recommended for 14.1-RELEASE), the drm-515-kmod will be built against the wrong kernel sources. And you won't find drm-61-kmod in the offical repo, because it cannot be built on 14.0-RELEASE.

So currently you have to build the port yourself as described in the handbook. Going with the graphics/drm-kmod just saves you from looking up the currently recommended drm version - don't forget to rebuild when you upgrade to a newer FreeBSD release in the future.

Well, congrats, you just found one of the weakest spots of FreeBSD packaging at first attempt ;)

T-Daemon said:
Even with pkgbase there will be a 3 month periode between a branches major upgrade introduction and end-of-life of the lesser version. That means packages still will be build for the lesser version.
Click to expand...

I'm not up to date on current efforts, but from your wiki link it looks like there's separate repos for different FreeBSD releases. We could just move kernel module packages to these repos, at least the most important ones that don't drag in a lot of dependencies. That would tie them to the base packages effectively.
 
I know there should be very, very, very strong objections, but with current framework, any kmod ports including GPU ones should not be provided as pkg and forcing installation from ports is the only reliable way to go.

Considering restructuring the framework, there could be another way.

Adding logic to forcibly add FLAVORs for latest patchlevel of ALL supported releases (such as 14.0-p1, 13.2-p3 and so on, applicable at the moment) in, for example, /usr/ports/Mk/Uses/kmod.mk and build pkg for all flavors.

Yes, applying the policy to all ports should require almost nonsense build resources, so the service should be limited for kmod ports only, on Tier1 (and Tier2 if possible) archs.

Most important thing is not requesting maintainers of kmod ports to test all combinations. They are usually a part time volunteers. Let them test on arch and version they actually using themselves only.
 
T-Aoki said:
Adding logic to forcibly add FLAVORs for latest patchlevel of ALL supported releases (such as 14.0-p1, 13.2-p3 and so on, applicable at the moment) in, for example, /usr/ports/Mk/Uses/kmod.mk and build pkg for all flavors.
Click to expand...
Just to be clear, is this a suggestion for the direction of FreeBSD or something I should be doing in my local machine?
 
jasmineitg said:
Just to be clear, is this a suggestion for the direction of FreeBSD or something I should be doing in my local machine?
Click to expand...
The former. There seems to be too many screams with kmods on almost all releases except the exact one that official pkgs are built with.
 
So having pkg drm-kmod I expect it to break after the move from 14.0-RELEASE to 14.1-RELEASE as soon as it gets an update? And then I will have to make install from ports to repair?
 
Short answer: yes.

When the overlap period of 14.0-R & 14.1-R ends, packages, in particulair those "kmod" ones, will be build on the remote package servers for 14.1-RELEASE; from then on forward you can switch back to using pkg install ... for those "kmod-s".

mro said:
So having pkg drm-kmod I expect it to break after the move from 14.0-RELEASE to 14.1-RELEASE as soon as it gets an update?
Click to expand...
Sooner, I expect. graphics/drm-515-kmod (this is what I'm expecting you to have what the meta port drm-kmod actually installed on your 14.0-R) will most likely already be broken after having upgraded to 14.1-RELEASE. EDIT: A pkg upgrade on 14.1-R will try to get graphics/drm-61-kmod as this is the default for 14.1-RELEASE and it will fail*, because; see the explanation of dependencies in message #24
There aren't any packages of graphics/drm-61-kmod available at the moment for 14.1-RELEASE, as can be seen at Packages - drm-61-kmod

* just as an explict pkg install drm-61-kmod will fail.
 
To be clear, I already am on 14.1-RELEASE since ~4 days:

Code: 
$ freebsd-version -kru ; uname -aKU
14.1-RELEASE
14.1-RELEASE
14.1-RELEASE-p2
FreeBSD mx250.local 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 1401000 1401000

and have drm-kmod still humming along
Code: 
$ pkg show drm-kmod
drm-kmod-20220907_3
Name           : drm-kmod
Version        : 20220907_3
Installed on   : Sat Apr 13 21:19:16 2024 CEST
Origin         : graphics/drm-kmod
Architecture   : FreeBSD:14:*
Prefix         : /usr/local
Categories     : graphics
Licenses       : NA
Maintainer     : x11@FreeBSD.org
WWW            : https://github.com/freebsd/drm-kmod
Comment        : Metaport of DRM modules for the linuxkpi-based KMS components
Annotations    :
    build_timestamp: 2024-04-10T14:34:55+0000
    built_by       : poudriere-git-3.4.1-1-g1e9f97d6
    port_checkout_unclean: no
    port_git_hash  : b3aa1ea86
    ports_top_checkout_unclean: no
    ports_top_git_hash: c5cd82114
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 243B
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 encompasses the recommendations of the FreeBSDDesktop team
of DRM versions for FreeBSD versions based on the last update to the LinuxKPI
in that code base. In general, the most recent supported stable DRM for a give
FreeBSD version will be installed. CURRENT receives the most recent development
DRM.
This port does not however hinder the expert user to make other decisions and
continue to install DRM ports directly.
Locked         : no

And hardware acceleration active
Code: 
$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Intel(R) HD Graphics 5500 (BDW GT2) (0x1616)
    Version: 24.0.9
    Accelerated: yes
    Video memory: 8192MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) HD Graphics 5500 (BDW GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.9
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.9
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.0.9
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

I feel very lucky :)
 
mro said:
So having pkg drm-kmod I expect it to break after the move from 14.0-RELEASE to 14.1-RELEASE as soon as it gets an update? And then I will have to make install from ports to repair?
Click to expand...

I'm not 100% sure whether a pkg upgrade would replace the locally built drm-kmod, as that comes from a different "repo" source. You may want to pkg-lock() the locally built drm-kmod for safety. Don't forget to unlock it before you update it from a locally built port.

Also when following the handbook procedure to upgrade the FreeBSD version: Disable the kernel modules first, do the FreeBSD upgrade, rebuild and reinstall the kernel modules, and then enable them again. This implies to disable the graphical login too while doing a FreeBSD upgrade.

Erichans said:
A pkg upgrade on 14.1-R will try to get graphics/drm-61-kmod as this is the default for 14.1-RELEASE and it will fail*, because there aren't any packages of graphics/drm-61-kmod available at the moment for 14.1-RELEASE, as can be seen at Packages - drm-61-kmod
Click to expand...

No. The dependency of the drm-kmod package is determined at build time. For the package builder machine of the official repo which currently runs 14.0-RELEASE, this results in:

Code: 
New packages to be INSTALLED:
        drm-515-kmod: 5.15.160
        drm-kmod: 20220907_3
        ...

It doesn't fail to install on 14.1-RELEASE, unfortunately, even though it's the wrong drm version built against the wrong kernel source. It's really kind of a trap for new users to step into.
 
You must log in or register to reply here.
Back
Top