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

[Alain De Vos]

My boot partition with /boot/loader is different than the partition which holds my kernel and does not have /boot/loader file. How would this work for modules I wonder.

 

[donallen]

What I am getting from this discussion is that this area is really more than a bit of a mess. One of the reasons for my interest in the BSDs is my skepticism about the Linux Wild West development model, as evidenced by the current state of the Linux audio system, both its actual architecture (or lack thereof) and documentation (or lack thereof). I'm disappointed to see similar problems, both apparently architectural and with the documentation, in the theoretically more tightly controlled FreeBSD system.

Just look back at this thread, where people who sound like they know their stuff, are disagreeing about how to do something really fundamental -- make X work correctly with a member of a large class of gpus. This points directly at the documentation in the Handbook, which I characterized as incomprehensible in my original post. It seems clear, pun intended, that all of you are having the same issue. If the X configuration were well-written and accurate, we wouldn't be having this discussion.

 

[astyle]

What I am getting from this discussion is that this area is really more than a bit of a mess. One of the reasons for my interest in the BSDs is my skepticism about the Linux Wild West development model, as evidenced by the current state of the Linux audio system, both its actual architecture (or lack thereof) and documentation (or lack thereof). I'm disappointed to see similar problems, both apparently architectural and with the documentation, in the theoretically more tightly controlled FreeBSD system.

Just look back at this thread, where people who sound like they know their stuff, are disagreeing about how to do something really fundamental -- make X work correctly with a member of a large class of gpus. This points directly at the documentation in the Handbook, which I characterized as incomprehensible in my original post. It seems clear, pun intended, that all of you are having the same issue. If the X configuration were well-written and accurate, we wouldn't be having this discussion.

Yeah, that's a good point coming from OP, and a bit of a head-scratcher for me - I followed the Handbook step-by-step from the very beginning, and adjusted for my hardware where needed - and never really had a problem with Xorg on FreeBSD. I personally think that Handbook is quite useful, and that a large number of GPU's would in fact be compatible with FreeBSD and Xorg - but you still gotta do your homework on the compatibility.

I thought I learned the process from the Handbook - but then I see the description of another user's experience, and something is just not quite adding up for me. So I drill in, and discover - Uhhh, THAT was the diff... Like Alain De Vos having legacy drivers in the kernel's source. I'm personally still skeptical that FreeBSD would actually do it, but I'm not dismissing that out of hand. I just never really noticed the makefile options for the kernel to build those legacy drivers or to turn that off. Somebody else with skills and attention on these forums is always welcome to point those options out to me.

 

[mer]

I've been doing this for so long I remember when you had to pay attention to modelines in xorg.conf
Worst I had was forgetting to rebuild the drm-kmod after upgrading (like from 11 to 12 etc).
It has always boiled down to paying attention and doing some research on the hardware you have/want. And yes it can be confusing.
I'm not minimizing anyone's experience, just that I've been able to mitigate it as much as possible. Pick hardware "1 generation back from current latest" seems to work and keep in mind that most hardware manufacturers want big money for documentation and may restrict open source usage.

 

[donallen]

Another wrinkle to add to this: this morning I booted my system with nothing regarding the gpu in rc.conf. When booting finished and the login prompt appeared on the console tty, my intention was to log in as myself there. But before doing so, I switched to tty 2, logged in as root, and ran 'kldload radeonkms'. Dead -- blank screen, completely unresponsive. So I rebooted (reset button) and this time logged in as myself on the console tty and su-ed. In the root shell, 'kldload radeonkms' worked. With only these two data points, I don't know if what I am reporting is consistent behavior or not. It could be or it could be some sort non-deterministic behavior.

So at this point, I have no definitive documentation to guide me how to properly set up this system to load the radeon driver automatically at boot time and I'm not sure if doing it manually from the console tty will work reliably. I'm seriously considering installing something else on this system (I use this system for OS evaluation; it's not my primary system, which runs Slackware without any problems; installing FreeBSD was motivated by ZFS and a sane sound architecture). Before bailing, I'll try rebooting to get more data on the manual load of the driver via the console tty. If that seems reliable, then I can try adding a sudo entry to allow me to do the kldload from my .profile at login time.

 

[Alain De Vos]

This is very inconsistent behaviour. I think it could be a matter of trial and error.
You could try to load the module in rc.conf.
If the kernel crashes you have to reboot in single user mode and remove the line manually.

 

[donallen]

I just rebooted twice. First time, I logged in as root on the console tty. kldload radeonkms killed the system (as I said before, it's unresponsive, but I should add that I can't ping it from another machine on the same LAN). I reset the system and rebooted and tried again, this time logging in as myself and su-ing. Same result. So it looks like this is a non-deterministic bug. This system is unusable for me and I will install something else on the machine.

Thanks to all for trying to help.

 

[Vull]

My partial and very incomplete understanding, derived mostly from the following linked thread, in summary goes something like this: "radeonkms" is a kernel mode-setting driver, whereas "radeon" is an xorg video driver included in xf86-video-ati. Using the radeonkms kernel driver by itself is not enough, you also need a video driver, which, depending on your specific graphics card, might be the radeon driver, or the amdgpu driver (which, I'm only assuming, is probably included in xf86-video-amdgpu), or the default modesetting driver from x11-servers/xorg-server.

Linked thread: Thread problems-with-radeon.79189

These drivers continue to evolve, faster than the documentation which supports them. That is hardly an unusual situation. Yesterday's solutions may not work so well, or at all, today or tomorrow. Yes the documentation could be more complete, but it's still pretty amazing for something which is totally FREE, so I don't complain much about the free stuff I get at absolutely no cost other than a little effort on my part. FreeBSD is not for those who want it all dished out for them on a silver platter. Windows 10 has great hardware support, unless your machine is too old, or underpowered, whereas FreeBSD still supports a wide range of older and newer hardware.

 

[astyle]

I'm beginning to think that OP has no greeter like sddm or gdm installed. The Handbook clearly says you gotta install one and enable it. It's OK to install and configure drm-kmod before or after. But both have to be installed and enabled in /etc/rc.conf before rebooting. There is a sequence of chores you gotta do to make sure everything works. Doing stuff out of sequence invites a broken FreeBSD system that is difficult to troubleshoot. This is why Handbook is your friend.

 

[Beastie7]

Without logs, and/or a a full spec out of what you have. This thread will be a shooting-in-the-air contest and extend to 20 pages.

 

[Vull]

This thread should die soon since the OP has already abandoned the effort.

 

[Alain De Vos]

I would like to add there are chipsets known to work fine. There are chipset known to not work.
Sometimes there are also chipsets which might work , a bit , good or bad. I think the OP has one of these.
Then it's trial and error. And when the kernel keeps crashes, giving up is a wise decision.
[When you compiled the drivers with the correct kernel source offcourse]

 

[grahamperrin]

donallen symptoms are very familiar to me.

KLD_LIST=radeonkms

Instead, try:

kld_list="drm"

NB lowercase, quotation marks, drm instead of radeonkms

(Also: I do have x11-drivers/xf86-video-ati installed, can't recall what happens without it. <https://bsd-hardware.info/?computer=8f084339058d>)

 

[donallen]

I'm beginning to think that OP has no greeter like sddm or gdm installed. The Handbook clearly says you gotta install one and enable it. It's OK to install and configure drm-kmod before or after. But both have to be installed and enabled in /etc/rc.conf before rebooting. There is a sequence of chores you gotta do to make sure everything works. Doing stuff out of sequence invites a broken FreeBSD system that is difficult to troubleshoot. This is why Handbook is your friend.

I'd appreciate your showing us where the Handbook says that.

For example, direct quote from the Handbook:

"The Xorg configuration process is now complete. Xorg may be now started with the startx(1) utility. The Xorg server may also be started with the use of xdm(1)."

I run my systems with just X and a window manager (dwm), no desktop. You are right -- I have no gdm or xdm-like thingy installed. I log in and run startx from the shell, just like the Handbook says above. Slackware Linux and every other system I've tested (OpenBSD, DragonFly, NetBSD and older versions of FreeBSD, the most recent being 12.1) work just fine this way, with the appropriate .xinitrc.

 

[donallen]

My partial and very incomplete understanding, derived mostly from the following linked thread, in summary goes something like this: "radeonkms" is a kernel mode-setting driver, whereas "radeon" is an xorg video driver included in xf86-video-ati. Using the radeonkms kernel driver by itself is not enough, you also need a video driver, which, depending on your specific graphics card, might be the radeon driver, or the amdgpu driver (which, I'm only assuming, is probably included in xf86-video-amdgpu), or the default modesetting driver from x11-servers/xorg-server.

Linked thread: Thread problems-with-radeon.79189

These drivers continue to evolve, faster than the documentation which supports them. That is hardly an unusual situation. Yesterday's solutions may not work so well, or at all, today or tomorrow. Yes the documentation could be more complete, but it's still pretty amazing for something which is totally FREE, so I don't complain much about the free stuff I get at absolutely no cost other than a little effort on my part. FreeBSD is not for those who want it all dished out for them on a silver platter. Windows 10 has great hardware support, unless your machine is too old, or underpowered, whereas FreeBSD still supports a wide range of older and newer hardware.

The drivers don't seem to evolve faster than OpenBSD's documentation, or Slackware Linux's, or ArchLinux's or Dragonfly's or NetBSD's. All of those system have been tested by me on the same hardware that we've been discussing here and I've had zero problems with X setup and its documentation. Expecting documentation of even FREE software to be comprehensible and accurate is hardly silver platter territory. The competition all do it better than FreeBSD., at least in this very important area.

 

[kpedersen]

The competition all do it better than FreeBSD., at least in this very important area.

They do. FreeBSD's use of Linux drivers is weak in this area. I am not convinced that having these drivers as ports serves a good purpose when it is dependent on the kernel version anyway. The handbook is also lacking in this area due to this fragile design. FreeBSD should be doing better here and it stems from odd decisions rather than technical or man power.

So first you need to add these external video drivers. I would say lets test it with amdgpu as well as radeonkms. The docs (and vendor info) are too awkward to explain which one is suitable for your version of the card. If you do:

# pkg install drm-kmod

It should pull in drm-fbsd13-kmod and gpu-firmware-kmod packages. Hopefully these are now installed? Do confirm this because in the past I have seen this meta package install without correctly pulling in the required packages.

Now you need to load the driver. The /boot/loader.conf stuff doesn't seem to work consistently for all these drivers, so instead use the kld_list in the /etc/rc.conf:

kld_list="amdgpu"
or
kld_list="radeonkms"

This should have resulted the same as doing kldload amdgpu or kldload radeonkms) manually. You should see the screen flicker and make a mess (you should now have a semi-blank console window with the rest of the content trailing down at the bottom).

Now, you shouldn't need an xorg.conf these days unless you are using an nvidia card. For some reason this favours the nv driver instead. So do make sure you remove this if you created one whilst trying to get it all to work previously.

So as a normal user, just run startx and you should see something.

(I find the amdgpu a little less stable than intel but installing it simpler. There was a time when there were 3 different intel drivers all with the same name but stored in different locations

So try with both and then if it still fails, if you can attach a /var/log/Xorg.0.log I am sure we can work it out. Unlike some other platforms, FreeBSD does have the benefit of being transparent if things go wrong. Also, don't use any login managers for now (xdm, gdm, etc). They are annoying. They also make this specific task more awkward.

Bonus bedtime reading:
https://wiki.freebsd.org/Graphics
https://docs.freebsd.org/en/books/handbook/x11/#x-install
https://freebsddesktop.github.io/2018/12/08/drm-kmod-primer.html

 

[donallen]

They do. FreeBSD's use of Linux drivers is weak in this area. I am not convinced that having these drivers as ports serves a good purpose when it is dependent on the kernel version anyway. The handbook is also lacking in this area due to this fragile design. FreeBSD should be doing better here and it stems from odd decisions rather than technical or man power.

Thanks for the explanation of how FreeBSD got to this point. I've focused on the weakness of the documentation, but it sounds like there are serious problems with what the project has done with the code.

So first you need to add these external video drivers. If you do:

# pkg install drm-kmod

It should pull in drm-fbsd13-kmod, gpu-firmware-kmod. Hopefully these are now installed? Do confirm this because in the past I have seen this meta package install without correctly pulling in the required packages.

Now you need to load the driver. The /boot/loader.conf stuff doesn't seem to work consistently for all these drivers, so instead use the kld_list in the rc.conf:

kld_list="amdgpu"

My gpu needs the radeon stuff, not amdgpu. Go back through this thread and you'll see that I did essentially what you recommend (substituting radeon for amdgpu) and what installing drm-kmod recommends (adding the kld_list line to rc.conf). The result was an unbootable system, which was why I started this thread.

 

[monwarez]

...
I have a *lot* of experience in OS development and Unix/Linux system administration.
...

So you have a *lot* of experience in OS development, but no experience on giving some logs, it is like shooting in the dark.
How are you expecting people to give you answer without any logs ?

As some people says: logs or it didn't happened.

PS: I cannot found which gpu you are using... (amd is not sufficient)

 

[kpedersen]

Yep, as monwarez mentioned, if you can provide those logs that would be great. It *should* be an easy one to solve, many people here are using older radeon cards with good results.

Also, just to clarify, if you comment out the kld_list part in the /etc/rc.conf and just do kldload radeonkms what happens? Does the screen turn black and you get nothing?

 

[grahamperrin]

… My gpu needs the radeon stuff, …

As does mine, and radeonkms in /etc/rc.conf is problematic for me, so I found a workaround.

… I think "it just needs to be loaded later" is correct.

▶ <https://forums.FreeBSD.org/threads/81015/post-519149> – do please try what's suggested.

… drm-fbsd13-kmod and gpu-firmware-kmod packages. Hopefully these are now installed? …

We can be certain of this because (from the opening post):

…I manually ran 'kldload radeonkms'. That worked …

 

[ralphbsz]

... Dead -- blank screen, completely unresponsive.

You obviously have the machine connected to a network? Does it respond to network packets? How about watching the ethernet lights blink? How about logging in from a second machine, and in a ssh session looking at the dmesg output? Are you actually sure the machine is "completely unresponsive"? My educated guess is that the video subsystem has just been turned off as a side-effect, but that the kernel itself and user processes are otherwise working just perfectly.

If the machine is actually unresponsive, given that you have experience, it's time to attach a second machine via serial port, and run the kernel debugger.

 

[kpedersen]

We can be certain of this because (from the opening post):

Sometimes it is useful to start from a blank canvas. Especially if someone has been trying different approaches since their original post there is no telling what sort of state their system is.

I don't typically expect them to remove everything and start again but I do just want them to check they haven't subsequently removed those packages whilst trying something else.

The typo was bad though! Will fix that.

 

[astyle]

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,

/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

Sorry, just not the case. I verified that by re-installing 13-RELEASE and recompiling the kernel (with default options) BEFORE installing anything, even the ports tree. Then I ran updatedb.

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.

Running locate radeonkms and locate amdgpu after recompiling the kernel with default options (and I did the updatedb, too), turned up nothing. Conclusion - drm.ko is NOT included in kernel sources, so no way you'd have /boot/kernel/amdgpu.ko unless you messed with make.conf or makefile flags earlier. This is why we have the drm port.

 

[Alain De Vos]

After compiling kernel I have

/boot/kernel/radeonkms.ko

 

[astyle]

After compiling kernel I have

/boot/kernel/radeonkms.ko

When you compiled the kernel, you already had the DRM port installed. I compiled mine with absolutely nothing installed, not even the ports tree or any packages whatsoever. runnling #updatedb and # locate radeonkms after that, I came up empty.