Following the advice of drm-kmod pkg leads to unbootable system

D

donallen

I just installed FreeBSD v13 on a 10-year-old machine with an AMD processor and Radeon gpu.

First of all, I'd like to mention that the documentation in the Handbook in the X configuration section on how to deal with KMS and the various available driver modules is simply incomprehensible, at least to me, and I have a *lot* of experience in OS development and Unix/Linux system administration.

But the problem I want to discuss is that after installing drm-kmod (using pkg install, not building the port, because that port does not build correctly, another issue; I will file a bug report on that one, as well as the primary issue I'm discussing here), the post-install comments printed by the package suggest adding KLD_LIST=radeonkms to /etc/rc.conf. If you follow that advice, the next time you try to reboot the system, it won't. The boot process hangs at about the point where you expect the switch to higher resolution text. I probably could have saved the situation with either the bootable installer system or a rescue system, and eliminated the KLD_LIST line from rc.conf, but my ZFS knowledge needs work (getting the right stuff mounted in order to access files in /etc , so I just re-installed.

With the re-installed system, before running 'startx', I manually ran 'kldload radeonkms'. That worked fine and resolution after startx is correct, which is not the case if radeonkms is not loaded.

So the question is how to load radeonkms at boot-time in a way that doesn't lead to disaster?

/Don Allen
 
My advice would be, first, remove any radeon settings out of /boot/loader.conf & /etc/rc.conf.
If your system boot fine install the packages or ports,
Code: 
drm-fbsd13-kmod
drm-kmod
drm_info
This will install kmod files in the /boot directory which are essential.


Now don't touch /boot/loader.conf !, but add simply to /etc/rc.conf ,
Code: 
kld_list="drm radeonkms acpi_video"

(Note : If you did not install the right radeon kernel drivers the system will crash on boot reading rc.conf)
 
First, quick ZFS Boot Environment (BE) trick:
bectl mount is your friend (man bectl)

You may have been able to boot single user, start ZFS and been able to get to the /etc/rc.conf file.

drm-kmod:
do find /boot -name "*radeonkms*" -print and see how many there are/where they are. In some versions of FreeBSD, there was a set of "legacy" drm kmods that worked for some, but then the drm-kmod "lastest" moved to ports tree and installed in a different directory. The legacy ones MAY have been removed in FreeBSD-13.0 (I'm too lazy to check commit messages right now) so there should only be one.
Basically the check is to make sure it's picking up the correct one.

The fact that if you do it by hand everything works, implies that there is something else going on, maybe it just needs to be loaded later.
 
mer said:
First, quick ZFS Boot Environment (BE) trick:
bectl mount is your friend (man bectl)

You may have been able to boot single user, start ZFS and been able to get to the /etc/rc.conf file.

drm-kmod:
do find /boot -name "*radeonkms*" -print and see how many there are/where they are. In some versions of FreeBSD, there was a set of "legacy" drm kmods that worked for some, but then the drm-kmod "lastest" moved to ports tree and installed in a different directory. The legacy ones MAY have been removed in FreeBSD-13.0 (I'm too lazy to check commit messages right now) so there should only be one.
Basically the check is to make sure it's picking up the correct one.
Click to expand...
/boot/modules/radeonkms.ko is the only file with name 'radeon*' in the file-system. I did the find from /.
mer said:
The fact that if you do it by hand everything works, implies that there is something else going on, maybe it just needs to be loaded later.
Click to expand...
I think "it just needs to be loaded later" is correct.
 
astyle said:
Make sure your card is the right one for radeonkms.ko - for newer stuff, you're supposed to use amdgpu.ko. And, go here for detailed instructions on how to get it all going.
Click to expand...
As I said in my original post, if I load radeonkms manually, X works correctly. If I don't, it doesn't (I get much lower resolution, probably using the vga driver). That, plus the
fact that I know from previous experience with this machine that the radeon driver is the correct one, resolves that question.

The link you provided is mostly not applicable, since it discusses amdgpu. But it may have a clue to resolving this. Maybe my

kld_list=radeonkms
needs to be

kld_list=/boot/modules/radeonkms.ko
I will give it a try and report back.
 
mer said:
First, quick ZFS Boot Environment (BE) trick:
bectl mount is your friend (man bectl)

You may have been able to boot single user, start ZFS and been able to get to the /etc/rc.conf file.
Click to expand...

And thanks for the help with mounting the zfs file-system to get at the rc.conf file.
mer said:
drm-kmod:
do find /boot -name "*radeonkms*" -print and see how many there are/where they are. In some versions of FreeBSD, there was a set of "legacy" drm kmods that worked for some, but then the drm-kmod "lastest" moved to ports tree and installed in a different directory. The legacy ones MAY have been removed in FreeBSD-13.0 (I'm too lazy to check commit messages right now) so there should only be one.
Basically the check is to make sure it's picking up the correct one.

The fact that if you do it by hand everything works, implies that there is something else going on, maybe it just needs to be loaded later.
Click to expand...
 
In 13 I have.
Code: 
/boot/kernel/radeonkms.ko
/boot/modules/radeonkms.ko
The last one comes with the package drm-fbsd13-kmod-5.4.92.g20210419.
I installed the package drm-fbsd13-kmod but load the first one, which comes with the kernel. The choise can be dependent on the exact type of video-card. And one might indeed give better results than the other.
 
Ahh... which card does OP even have? that's a make or break for radeonkms.ko... FWIW, my card is a Radeon... Radeon RX 550 4GB. That's the kind of info that makes or breaks the whole thing, and makes a difference in whether you use radeonkms or amdgpu.

Alain De Vos : radeonkms.ko always gets installed to /boot/modules. Did you symlink from /boot/kernel ? Sorry, but not the best idea.
 
donallen said:
I just installed FreeBSD v13 on a 10-year-old machine with an AMD processor and Radeon gpu.
...
So the question is how to load radeonkms at boot-time in a way that doesn't lead to disaster?
Click to expand...
I have 13.0-RELEASE-p2 on a Lenovo laptop, and dmesg -a reports that I have "AMD A6-6310 APU with AMD Radeon R4 Graphics." I do not have any references to "amdgpu" or "radeonkms" in either /boot/loader.conf or /etc/rc.conf.

When I initially installed FreeBSD on this box, I ran pkg install drm-kmod and put kld_list="radeonkms" in /etc/rc.conf, but it caused my system to thrash with no usable graphics, so I took that line out. Then, following some advice I learned on this forum, I ran pkg install xf86-video-ati. The disaster was over and all my problems went away. The boot process initially loads "VT(efifb): resolution 1366x768" and doesn't switch to the radeon driver until xorg starts graphics, using either startx or lightdm, and I have clean, smooth graphics with no noticable thrashing of the machine.
 
astyle said:
Ahh... which card does OP even have? that's a make or break for radeonkms.ko... FWIW, my card is a Radeon... Radeon RX 550 4GB. That's the kind of info that makes or breaks the whole thing, and makes a difference in whether you use radeonkms or amdgpu.

Alain De Vos : radeonkms.ko always gets installed to /boot/modules. Did you symlink from /boot/kernel ? Sorry, but not the best idea.
Click to expand...
No symlinks at all the the .ko files have a different source.
The first one comes when I compile the kernel in /usr/src.
The second one comes when I compile the port in /usr/ports/graphics/drm-fbsd13-kmod
 
astyle That is the result of what I was talking about. I think that in FreeBSD-12 the legacy/older version of the kmods live, then if you install from ports/pkgs they wind up in /boot/modules. I vaguely recall a message on the mailing lists (probably -hackers) about removing the legacy stuff for FreeBSD-13.
Since Alain De Vos says the first one shows up from building the kernel, I'm guessing there's a knob to disable the building that may need to be tweaked.

donallen you shouldn't have to put an explicit path to the ko unless there are multiple ones that may be different. The module load path is partly baked in and maybe also specified in the rc.d script.

The fact that it works when you hand load it implies a dependency somewhere that may be missing. What would be interesting (at least to me in the interest of figuring it out) is the output of the following sequence of commands:

reboot and don't autoload the module
kldstat > preload.txt
handload the module
kldstat > postload.txt
diff -u preload.txt postload.txt

You may simply need to add another module to kld_list before radeonkms (the rc script loads them in order).
 
Alain De Vos said:
No symlinks at all the the .ko files have a different source.
The first one comes when I compile the kernel in /usr/src.
The second one comes when I compile the port in /usr/ports/graphics/drm-fbsd13-kmod
Click to expand...
Now that has me a little lost... If there's radeonkms.ko in /boot/kernel/ AND an identically-named file in /boot/modules/, that would make it dangerous to just put # sysrc kld_list+=radeonkms out there - exactly which one gets loaded? What happens if both try to get loaded? I'd expect a module conflict where neither is loaded. I'd have to recompile my stock 13-RELEASE kernel to verify that radeonkms.ko does in fact appear in /boot/kernel/ first - but then there'd be no point to having the DRM port.
 
sysrc kld_list+=radeonkms loads the kernel one.
For the ports one you need to put the full path to be certain.
The drm port contains the following files,
Code: 
/boot/modules/amdgpu.ko
/boot/modules/drm.ko
/boot/modules/i915kms.ko
/boot/modules/linuxkpi_gplv2.ko
/boot/modules/radeonkms.ko
/boot/modules/ttm.ko
 
Alain De Vos said:
sysrc kld_list+=radeonkms loads the kernel one.
For the ports one you need to put the full path to be certain.
Click to expand...
If that were the case, then wayland devs have it wrong.. ADG's directions say to first install drm-kmod, and then do sysrc kld_list+... in either case, /bin/kldload gets called, and it doesn't care where it looks. If it doesn't find anything in /boot/kernel/, it will look in /boot/modules/.
 
When you have the module both in /boot/kernel and in /boot/modules , and as /boot/kernel is searched first you need to specify the full path if you want to load the /boot/modules one.
The order of execution of sysrc kldlist+ and install of drm-kmod is independent.
sysrc kldlist changes the rc.conf file and pkg install drm-kmod does not touch the rc.conf file.
Offcourse it is best practice to first install the module before adding it to the rc.conf
 
Alain De Vos said:
sysrc kld_list+=radeonkms loads the kernel one.
For the ports one you need to put the full path to be certain.
The drm port contains the following files,
Code: 
/boot/modules/amdgpu.ko
/boot/modules/drm.ko
/boot/modules/i915kms.ko
/boot/modules/linuxkpi_gplv2.ko
/boot/modules/radeonkms.ko
/boot/modules/ttm.ko
Click to expand...
I'm surprised that identical stuff would be included in the kernel sources... drm-kmod doesn't get updated that often, but even so, that's rather unusual for FreeBSD. And even if amdgpu sources were in fact included in kernel sources, I would expect more recent stuff to appear in ports.
Alain De Vos said:
When you have the module both in /boot/kernel and in /boot/modules , and as /boot/kernel is searched first you need to specify the full path if you want to load the /boot/modules one.
The order of execution of sysrc kldlist+ and install of drm-kmod is independent.
sysrc kldlist changes the rc.conf file and pkg install drm-kmod does not touch the rc.conf file.
Click to expand...
sysrc kldlist has to be run AFTER pkg install drm-kmod... otherwise you can run kldload all you want, if the .ko file is not installed, nothing will get loaded.
 
astyle and Alain De Vos the ones in /boot/kernel that show up from building kernel from source are what I've been calling the "legacy" ones. They lag behind the port (obviously) and use older versions of the linuxkpi.

I believe the official builds of FreeBSD-13 and -current have a make.conf knob that disables the building of them.
 
mer said:
astyle and Alain De Vos the ones in /boot/kernel that show up from building kernel from source are what I've been calling the "legacy" ones. They lag behind the port (obviously) and use older versions of the linuxkpi.

I believe the official builds of FreeBSD-13 and -current have a make.conf knob that disables the building of them.
Click to expand...
Hold on.. I seem to recall that you normally use /boot/loader.conf to load .ko files from /boot/kernel using syntax like zfs_enable=YES... I think you'd have to follow that logic to load anything from/boot/kernel/ directory, while rc.conf or sysrc kld_list+= radeonkms will load from /boot/modules/. Probably a better practice anyway.
 
It's a bad idea to load video drivers in /boot/loader.conf
It makes recovery more difficult when the system crashes during the boot phase then when the crash happens during the read of the rc.conf file ( i.e. after the init got started).
 
Loading modules from /boot/loader.conf is supposed to be for "modules that are needed to get your system to single user mode". If you are running ZFS-root system, you need to load zfs.ko in loader.conf or you won't boot. If you aren't running ZFS on root, but you are running a GEOM based mirrored UFS system, you need to use loader.conf to load gmirror.ko.

sysctl kern.module_path defines the path to look for modules, works the same way as PATH does for your shell.

sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays

In the loader, it may only look in /boot/kernel (I haven't checked loader source) so it keeps modules and kernel consistent. It is possible that the module path is defaulted to what I show above, so even the loader may look on the path.

kld_list in /etc/rc.conf is used by /etc/rc.d/kld by calling load_kld which is defined in /etc/rc.subr which simply calls kldload.
kldload uses kern.module_path, looks down the path in the order specified, so /boot/kernel first, then /boot/modules.

The modules created when you build kernel source wind up installed into /boot/kernel, it looks like the convention for ports or modules not built as part of a kernel build wind up installing in /boot/modules.

Alain De Vos said he built his kernel from source, that is why he has a radeonkms.ko in /boot/kernel. He also installed the drm-kmod package, that put one in /boot/modules. Because of kern.module_path he needed to specify the full path to the desired radeonkms.ko. If he did not specify the full path, it would try to load the one from /boot/kernel: depending on where the source for that comes from, it may or may not work. That would be an experiment for him to try: modify kld_list to not have the full path for radeonkms.ko and see if it works. Of course if it didn't work, he'd likely come back yelling at me for it :)

donallen did the find command I suggested and only found one in /boot/modules since he installed the package but did not build kernel from source. I have not built kernel from source and only have a single copy in /boot/modules.
 
Alain De Vos said:
It's a bad idea to load video drivers in /boot/loader.conf
It makes recovery more difficult when the system crashes during the boot phase then when the crash happens during the read of the rc.conf file ( i.e. after the init got started).
Click to expand...
try stringing a few things together:
  • /boot/loader.conf-> /boot/kernel/zfs.ko using zfs_enable=YES
  • /etc/rc.conf-> /boot/modules/radeonkms.ko using # sysrc kld_list+=radeonkms
First one talks about ZFS, second one talks about radeonkms...
 
Any module loaded from loader.conf that crashes makes recovery difficult :)
If there is an issue with the video driver (drm-kmod) loading it from loader.conf can make it difficult to recover mostly because you lose your console and can't debug anything. If it were perfect, it should be ok.

I think of it like "do I boot to a CLI, login, startx" or "boot directly to an X environment". In the past I've been burned by bad Xorg config files, so you'd effectively loop on trying to startX. PITA to debug, so I choose to boot to CLI, login and then startx. Makes it easier for me to debug bad things with X.

find /boot -name zfs.ko -print shows only one in /boot/kernel.
If there was another one in /boot/modules, you'd likely have to specify full path if you wanted to use the one in /boot/modules, even in loader.conf.

Hopefully I haven't added too much confusion and Sorry OP if I hijacked things a little bit.
 
mer said:
I think of it like "do I boot to a CLI, login, startx" or "boot directly to an X environment". In the past I've been burned by bad Xorg config files, so you'd effectively loop on trying to startX. PITA to debug, so I choose to boot to CLI, login and then startx
Click to expand...
BTW, this is how things stand with Wayland and KDE right now... install the packages, boot to CLI, run startplasma-wayland.sh... no .conf files to really speak of in that case.
 
You must log in or register to reply here.
Back
Top