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



## donallen (Jun 24, 2021)

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


----------



## Alain De Vos (Jun 24, 2021)

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,

```
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 ,

```
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)


----------



## mer (Jun 24, 2021)

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.


----------



## astyle (Jun 24, 2021)

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.


----------



## donallen (Jun 24, 2021)

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.
> ...


/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.


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


----------



## Alain De Vos (Jun 24, 2021)

I used "/boot/modules/radeonkms.ko" in 12 but had to use " radeonkms" in 13


----------



## donallen (Jun 24, 2021)

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.


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.


----------



## donallen (Jun 24, 2021)

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.



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.


----------



## Alain De Vos (Jun 24, 2021)

In 13  I have.

```
/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.


----------



## astyle (Jun 24, 2021)

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.


----------



## Vull (Jun 24, 2021)

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?


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.


----------



## Alain De Vos (Jun 24, 2021)

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.


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


----------



## mer (Jun 24, 2021)

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).


----------



## astyle (Jun 24, 2021)

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


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.


----------



## Alain De Vos (Jun 24, 2021)

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
```


----------



## astyle (Jun 24, 2021)

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.


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/.


----------



## Alain De Vos (Jun 24, 2021)

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


----------



## astyle (Jun 24, 2021)

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,
> 
> ...


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.


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.


----------



## mer (Jun 24, 2021)

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.


----------



## astyle (Jun 24, 2021)

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.


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.


----------



## Alain De Vos (Jun 24, 2021)

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).


----------



## mer (Jun 24, 2021)

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.


----------



## astyle (Jun 24, 2021)

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).


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...


----------



## mer (Jun 24, 2021)

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.


----------



## astyle (Jun 24, 2021)

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


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.


----------



## Alain De Vos (Jun 24, 2021)

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 (Jun 24, 2021)

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 (Jun 25, 2021)

donallen said:


> 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 (Jun 25, 2021)

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 (Jun 25, 2021)

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 (Jun 25, 2021)

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 (Jun 25, 2021)

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 (Jun 25, 2021)

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 (Jun 25, 2021)

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 (Jun 25, 2021)

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 (Jun 25, 2021)

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


----------



## Alain De Vos (Jun 25, 2021)

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@ (Jun 25, 2021)

donallen symptoms are very familiar to me.



donallen said:


> 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 (Jun 25, 2021)

astyle said:


> 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 (Jun 25, 2021)

Vull said:


> 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 (Jun 25, 2021)

donallen said:


> 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 (Jun 25, 2021)

Vull said:


> kpedersen said:
> 
> 
> > 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.


Vull said:


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


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 (Jun 25, 2021)

donallen said:


> ...
> 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 (Jun 25, 2021)

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@ (Jun 26, 2021)

donallen said:


> … My gpu needs the radeon stuff, …



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



donallen said:


> … 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.



kpedersen said:


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



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



donallen said:


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


----------



## ralphbsz (Jun 26, 2021)

donallen said:


> ... 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 (Jun 26, 2021)

grahamperrin said:


> 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 (Jul 3, 2021)

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,
> 
> ...


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.


astyle said:


> 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 (Jul 3, 2021)

After compiling kernel I have

```
/boot/kernel/radeonkms.ko
```


----------



## astyle (Jul 3, 2021)

Alain De Vos said:


> 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.


----------



## Alain De Vos (Jul 3, 2021)

I think the drm port installs in /boot/modules and not in /boot/kernel. (I'm not sure)


----------



## astyle (Jul 3, 2021)

Alain De Vos said:


> I think the drm port installs in /boot/modules and not in /boot/kernel. (I'm not sure)


You are correct there... the port indeed installs to /boot/modules. After install, looking for the same files in /boot/kernel will come up empty.


----------



## Alain De Vos (Jul 3, 2021)

Yet in /boot/kernel i have:
radeon.ko and drm.ko
These can only come from compiling the kernel I think.
Because normally i delete /boot/kernel before make installkernel.


----------



## Alain De Vos (Jul 3, 2021)

I think radeon needs the following options in the kernel.
COMPAT_FREEBSD32    # Compatible with i386 binaries
COMPAT_FREEBSD11    # Compatible with FreeBSD11
COMPAT_FREEBSD12    # Compatible with FreeBSD12


----------



## astyle (Jul 3, 2021)

Even with that, I fail to see how something that is clearly part of graphics/drm-kmod would be included in FreeBSD's kernel sources (src.txz). These options, best I understand, will allow binary compatibility between the kernel and radeonkms.ko, but they will not pull the radeonkms.ko file in - that is done by the drm-kmod port. My theory on this is that 

graphics/drm-kmod is installed, pulling in radeonkms.ko, which initially gets installed to /boot/modules/ directory.
Apparently enabling compatibility in the kernel's makefile (as described by Alain De Vos ) means checking the /boot/modules/ directory for compatible modules. 
When compiling the kernel (after steps 1 and 2 are done): If a module is indeed compatible, it gets copied over to /boot/kernel/ directory, because it's safe to do that (no memory leaks or other illegal address pointers).
Looks like a kernel dev may need to weigh in and confirm or deny my theory.


----------



## grahamperrin@ (Jul 3, 2021)

```
% uname -KrU
14.0-CURRENT 1400024 1400024
% pkg provides radeonkms.ko
Name    : drm-devel-kmod-5.4.92.g20210526
Desc    : DRM modules for the linuxkpi-based KMS components (development version)
Repo    : FreeBSD
Filename: boot/modules/radeonkms.ko

Name    : drm-current-kmod-5.4.92.g20210526
Desc    : DRM modules for the linuxkpi-based KMS components
Repo    : FreeBSD
Filename: boot/modules/radeonkms.ko
%
```

In my case, the module is installed when I `make installkernel …`


```
% pkg query '%o %v %R' drm-devel-kmod
graphics/drm-devel-kmod 5.4.92.g20210526 unknown-repository
% grep drm-devel-kmod /etc/src.conf
PORTS_MODULES= graphics/drm-devel-kmod graphics/gpu-firmware-kmod
%
```



Alain De Vos said:


> Yet in /boot/kernel i have:
> radeon.ko and drm.ko
> These can only come from compiling the kernel I think.



They're not present for me. 

Does a sorted view offer a clue? 

`ls -hlrt /boot/kernel/`


----------



## astyle (Jul 3, 2021)

Like I said... I only compiled the installed src.txz that was available to me. No ports or packages even bootstrapped. I'm flabbergasted how people miss that, it's a key point.


----------



## Alain De Vos (Jul 3, 2021)

ls -hlrt output,

```
...
-r-xr-xr-x  1 root  wheel    94K Jun 27 19:20 xz.ko
-r-xr-xr-x  1 root  wheel    37M Jun 27 19:20 zfs.ko
-r-xr-xr-x  1 root  wheel   296K Jun 27 19:20 zlib.ko
-r-xr-xr-x  1 root  wheel   1.5M Jun 27 19:20 linuxkpi_gplv2.ko
-r-xr-xr-x  1 root  wheel   1.9M Jun 27 19:20 ttm.ko
-r-xr-xr-x  1 root  wheel    14M Jun 27 19:20 drm.ko
-r-xr-xr-x  1 root  wheel    99M Jun 27 19:20 amdgpu.ko
-r-xr-xr-x  1 root  wheel    33M Jun 27 19:20 radeonkms.ko
-r-xr-xr-x  1 root  wheel    51M Jun 27 19:20 i915kms.ko
-rw-r--r--  1 root  wheel   254K Jun 27 19:20 linker.hints
The end
HOST:x: /boot/kernel >
```


----------



## Alain De Vos (Jul 3, 2021)

Src.conf

```
WITH_BHYVE=yes
WITH_CCACHE_BUILD=yes
WITH_GPIO=yes
WITH_LIB32=yes
WITH_LLVM_TARGET_X86=yes
WITH_NIS=yes
WITH_NTP=yes
WITH_SVN=yes
WITH_ZFS=yes
```
make.conf

```
DISABLE_LICENSES=yes
MAKE_JOBS_UNSAFE=yes
BATCH=yes
CPUTYPE?=core-avx-i
MAKE_JOBS_NUMBER=20
CCACHE_DIR=/ccache
WITH_CCACHE_BUILD=yes
WITHOUT_MANCOMPRESS=YES
```
uname -a

```
FreeBSD  mail.ala
13.0-RELEASE-p2 FreeBSD
13.0-RELEASE-p2 #0
releng/13.0-n244746-b74cdf1ecea: Sat Jul  3 22:00:35 CEST 2021
```
After  a test i confirm radeon is an integer part of the 13 kernel .


----------



## grahamperrin@ (Jul 4, 2021)

Alain De Vos said:


> … After a test i confirm radeon is an integer part of the 13 kernel .



I can't see how; <https://github.com/freebsd/freebsd-src/search?q=radeonkms>


----------



## astyle (Jul 4, 2021)

grahamperrin said:


> I can't see how; <https://github.com/freebsd/freebsd-src/search?q=radeonkms>


Yeah, based on that, I see that radeonkms.ko is actually blacklisted in /boot/loader.conf, as well as amdgpu.ko.  But neither is present  in freebsd-src (the stuff that gets packaged into src.txz that I install and compile before any packages and ports are present on the system). Besides,


Alain De Vos said:


> -r-xr-xr-x 1 root wheel 99M Jun 27 19:20 amdgpu.ko
> -r-xr-xr-x 1 root wheel 33M Jun 27 19:20 radeonkms.ko


With sizes like that, small wonder they're available only as a separate port (graphics/drm-kmod).


----------



## grahamperrin@ (Jul 4, 2021)

astyle said:


> … sizes like that, …



Made me curious.


```
root@mowa219-gjp4-8570p:~ # zfs get compression copperbowl/ROOT
NAME             PROPERTY     VALUE           SOURCE
copperbowl/ROOT  compression  zstd            inherited from copperbowl
root@mowa219-gjp4-8570p:~ # du -h /boot/modules/radeonkms.ko
677K    /boot/modules/radeonkms.ko
root@mowa219-gjp4-8570p:~ # ls -hl /boot/modules/radeonkms.ko
-r-xr-xr-x  1 root  wheel   2.3M Jun 26 04:51 /boot/modules/radeonkms.ko
root@mowa219-gjp4-8570p:~ # file /boot/modules/radeonkms.ko
/boot/modules/radeonkms.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), BuildID[sha1]=9902e3db94ffdf3a4745c254d39cf0b1e1b5e3ab, not stripped
root@mowa219-gjp4-8570p:~ # du -h /boot/modules
 27M    /boot/modules
root@mowa219-gjp4-8570p:~ # ls -hlS /boot/modules
total 27059
-r-xr-xr-x  1 root  wheel   5.2M Jun 26 04:51 amdgpu.ko
-rwxr-xr-x  1 root  wheel   5.0M Jun 26 08:08 openzfs.ko
-r-xr-xr-x  1 root  wheel   2.3M Jun 26 04:51 i915kms.ko
-r-xr-xr-x  1 root  wheel   2.3M Jun 26 04:51 radeonkms.ko
-r-xr-xr-x  1 root  wheel   886K Jun 26 04:51 drm.ko
-r-xr-xr-x  1 root  wheel   475K Jun 15 11:27 vboxdrv.ko
-r-xr-xr-x  1 root  wheel   459K Jun 26 04:52 amdgpu_renoir_vcn_bin.ko
-r-xr-xr-x  1 root  wheel   396K Jun 26 04:51 amdgpu_navi10_vcn_bin.ko
-r-xr-xr-x  1 root  wheel   396K Jun 26 04:51 amdgpu_navi12_vcn_bin.ko
-r-xr-xr-x  1 root  wheel   396K Jun 26 04:51 amdgpu_navi14_vcn_bin.ko
-r-xr-xr-x  1 root  wheel   387K Jun 26 04:52 amdgpu_vega20_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   384K Jun 26 04:52 amdgpu_vega10_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   384K Jun 26 04:52 amdgpu_vega12_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   379K Jun 26 04:51 amdgpu_polaris10_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   379K Jun 26 04:51 amdgpu_polaris11_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   379K Jun 26 04:51 amdgpu_polaris12_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   379K Jun 26 04:52 amdgpu_vegam_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   367K Jun 26 04:51 amdgpu_picasso_vcn_bin.ko
-r-xr-xr-x  1 root  wheel   367K Jun 26 04:51 amdgpu_raven2_vcn_bin.ko
-r-xr-xr-x  1 root  wheel   367K Jun 26 04:52 amdgpu_raven_vcn_bin.ko
-r-xr-xr-x  1 root  wheel   330K Jun 26 04:52 amdgpu_tonga_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   283K Jun 26 04:52 amdgpu_stoney_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   278K Jun 26 04:51 amdgpu_carrizo_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   275K Jun 26 04:51 amdgpu_navi14_mec2_wks_bin.ko
-r-xr-xr-x  1 root  wheel   275K Jun 26 04:51 amdgpu_navi14_mec_wks_bin.ko
-r-xr-xr-x  1 root  wheel   275K Jun 26 04:51 amdgpu_navi10_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   275K Jun 26 04:51 amdgpu_navi12_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   275K Jun 26 04:51 amdgpu_navi14_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   275K Jun 26 04:51 amdgpu_navi10_mec_bin.ko
-r-xr-xr-x  1 root  wheel   275K Jun 26 04:51 amdgpu_navi12_mec_bin.ko
-r-xr-xr-x  1 root  wheel   275K Jun 26 04:51 amdgpu_navi14_mec_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:51 amdgpu_picasso_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:51 amdgpu_picasso_mec_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:51 amdgpu_raven2_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_renoir_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_vega10_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_vega12_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_vega20_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:51 amdgpu_raven2_mec_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_raven_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_renoir_mec_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_vega10_mec_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_vega12_mec_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_vega20_mec_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:52 amdgpu_raven_mec_bin.ko
-r-xr-xr-x  1 root  wheel   274K Jun 26 04:51 amdgpu_navi10_smc_bin.ko
-r-xr-xr-x  1 root  wheel   273K Jun 26 04:51 amdgpu_fiji_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   271K Jun 26 04:51 amdgpu_navi12_smc_bin.ko
-r-xr-xr-x  1 root  wheel   271K Jun 26 04:51 amdgpu_navi14_smc_bin.ko
-r-xr-xr-x  1 root  wheel   270K Jun 26 04:51 amdgpu_navi14_pfp_wks_bin.ko
-r-xr-xr-x  1 root  wheel   270K Jun 26 04:51 amdgpu_navi14_me_wks_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi10_pfp_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi12_pfp_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi14_pfp_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi10_me_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi12_me_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi14_me_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi14_ce_wks_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi10_ce_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi12_ce_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_navi14_ce_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_vega10_acg_smc_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris10_mec2_2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris11_mec2_2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris12_mec2_2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris10_mec_2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris11_mec_2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris12_mec_2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_vega10_smc_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_vega12_smc_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_vega20_smc_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris10_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris11_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris12_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris10_mec_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris11_mec_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_polaris12_mec_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_carrizo_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_tonga_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_vegam_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_fiji_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_tonga_mec_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_vegam_mec_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_carrizo_mec_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:51 amdgpu_fiji_mec_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_stoney_mec_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_topaz_mec2_bin.ko
-r-xr-xr-x  1 root  wheel   269K Jun 26 04:52 amdgpu_topaz_mec_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:51 amdgpu_bonaire_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:51 amdgpu_mullins_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:52 radeon_bonaire_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:52 radeon_mullins_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:51 amdgpu_hawaii_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:51 amdgpu_kabini_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:51 amdgpu_kaveri_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:52 radeon_hawaii_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:52 radeon_kabini_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   240K Jun 26 04:52 radeon_kaveri_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   239K Jun 26 04:52 radeon_BONAIRE_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   227K Jun 26 04:51 amdgpu_pitcairn_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   227K Jun 26 04:52 amdgpu_tahiti_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   227K Jun 26 04:51 amdgpu_oland_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   227K Jun 26 04:52 amdgpu_verde_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   227K Jun 26 04:52 radeon_TAHITI_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   226K Jun 26 04:51 i915_kbl_huc_ver02_00_bin.ko
-r-xr-xr-x  1 root  wheel   212K Jun 26 04:52 radeon_SUMO_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   204K Jun 26 04:51 amdgpu_navi12_sos_bin.ko
-r-xr-xr-x  1 root  wheel   192K Jun 26 04:51 amdgpu_navi10_sos_bin.ko
-r-xr-xr-x  1 root  wheel   192K Jun 26 04:51 amdgpu_navi14_sos_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:51 amdgpu_picasso_asd_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:51 amdgpu_navi10_asd_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:51 amdgpu_navi12_asd_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:51 amdgpu_navi14_asd_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:51 amdgpu_raven2_asd_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:52 amdgpu_renoir_asd_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:52 amdgpu_vega10_asd_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:52 amdgpu_vega12_asd_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:52 amdgpu_vega20_asd_bin.ko
-r-xr-xr-x  1 root  wheel   189K Jun 26 04:51 amdgpu_raven_asd_bin.ko
-r-xr-xr-x  1 root  wheel   184K Jun 26 04:51 amdgpu_carrizo_vce_bin.ko
-r-xr-xr-x  1 root  wheel   183K Jun 26 04:52 amdgpu_vega20_sos_bin.ko
-r-xr-xr-x  1 root  wheel   182K Jun 26 04:52 amdgpu_vega10_vce_bin.ko
-r-xr-xr-x  1 root  wheel   182K Jun 26 04:52 amdgpu_vega12_vce_bin.ko
-r-xr-xr-x  1 root  wheel   182K Jun 26 04:52 amdgpu_vega20_vce_bin.ko
-r-xr-xr-x  1 root  wheel   175K Jun 26 04:51 amdgpu_polaris10_vce_bin.ko
-r-xr-xr-x  1 root  wheel   175K Jun 26 04:51 amdgpu_polaris11_vce_bin.ko
-r-xr-xr-x  1 root  wheel   175K Jun 26 04:51 amdgpu_polaris12_vce_bin.ko
-r-xr-xr-x  1 root  wheel   175K Jun 26 04:52 amdgpu_stoney_vce_bin.ko
-r-xr-xr-x  1 root  wheel   175K Jun 26 04:52 amdgpu_vega10_sos_bin.ko
-r-xr-xr-x  1 root  wheel   175K Jun 26 04:52 amdgpu_vega12_sos_bin.ko
-r-xr-xr-x  1 root  wheel   175K Jun 26 04:52 amdgpu_vegam_vce_bin.ko
-r-xr-xr-x  1 root  wheel   169K Jun 26 04:52 amdgpu_tonga_vce_bin.ko
-r-xr-xr-x  1 root  wheel   169K Jun 26 04:51 amdgpu_fiji_vce_bin.ko
-r-xr-xr-x  1 root  wheel   163K Jun 26 04:51 i915_bxt_huc_ver01_07_bin.ko
-r-xr-xr-x  1 root  wheel   156K Jun 26 04:51 i915_skl_guc_ver9_33_bin.ko
-r-xr-xr-x  1 root  wheel   152K Jun 26 04:51 i915_kbl_guc_ver9_14_bin.ko
-r-xr-xr-x  1 root  wheel   150K Jun 26 04:51 i915_skl_huc_ver01_07_bin.ko
-r-xr-xr-x  1 root  wheel   150K Jun 26 04:51 i915_bxt_guc_ver8_7_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:52 amdgpu_vegam_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:51 amdgpu_bonaire_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:52 radeon_bonaire_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:51 amdgpu_hawaii_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:52 radeon_hawaii_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:51 amdgpu_bonaire_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:52 radeon_bonaire_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:51 amdgpu_hawaii_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:52 radeon_hawaii_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:52 radeon_BONAIRE_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:52 radeon_HAWAII_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:51 amdgpu_polaris12_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:52 amdgpu_tonga_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:51 amdgpu_polaris12_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:52 amdgpu_tonga_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:51 amdgpu_polaris10_k2_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:51 amdgpu_polaris10_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel   140K Jun 26 04:51 amdgpu_polaris11_k2_smc_bin.ko
-r-xr-xr-x  1 root  wheel   139K Jun 26 04:51 amdgpu_polaris11_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel   139K Jun 26 04:51 amdgpu_polaris10_smc_sk_bin.ko
-r-xr-xr-x  1 root  wheel   139K Jun 26 04:51 amdgpu_polaris11_smc_sk_bin.ko
-r-xr-xr-x  1 root  wheel   139K Jun 26 04:51 amdgpu_polaris10_smc_bin.ko
-r-xr-xr-x  1 root  wheel   139K Jun 26 04:51 amdgpu_polaris11_smc_bin.ko
-r-xr-xr-x  1 root  wheel   139K Jun 26 04:51 amdgpu_fiji_smc_bin.ko
-r-xr-xr-x  1 root  wheel   138K Jun 26 04:51 i915_skl_guc_ver6_1_bin.ko
-r-xr-xr-x  1 root  wheel   128K Jun 26 04:52 amdgpu_renoir_dmcub_bin.ko
-r-xr-xr-x  1 root  wheel   126K Jun 26 04:52 radeon_RV710_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   125K Jun 26 04:52 radeon_CYPRESS_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:51 amdgpu_bonaire_vce_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:51 amdgpu_mullins_vce_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:52 radeon_bonaire_vce_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:52 radeon_mullins_vce_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:51 amdgpu_hawaii_vce_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:51 amdgpu_kabini_vce_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:51 amdgpu_kaveri_vce_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:52 radeon_hawaii_vce_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:52 radeon_kabini_vce_bin.ko
-r-xr-xr-x  1 root  wheel   111K Jun 26 04:52 radeon_kaveri_vce_bin.ko
-r-xr-xr-x  1 root  wheel   109K Jun 26 04:51 ttm.ko
-r-xr-xr-x  1 root  wheel   101K Jun 26 04:52 radeon_RV770_uvd_bin.ko
-r-xr-xr-x  1 root  wheel   100K Jun 26 04:52 radeon_RS780_uvd_bin.ko
-r-xr-xr-x  1 root  wheel    95K Jun 26 04:51 linuxkpi_gplv2.ko
-r-xr-xr-x  1 root  wheel    93K Jun 26 04:52 amdgpu_vega20_ta_bin.ko
-r-xr-xr-x  1 root  wheel    91K Jun 26 04:52 amdgpu_topaz_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    91K Jun 26 04:52 amdgpu_topaz_smc_bin.ko
-r-xr-xr-x  1 root  wheel    89K Jun 26 04:52 radeon_BONAIRE_vce_bin.ko
-r-xr-xr-x  1 root  wheel    85K Jun 26 04:52 radeon_R600_uvd_bin.ko
-rw-r--r--  1 root  wheel    79K Jun 28 09:12 linker.hints
-r-xr-xr-x  1 root  wheel    75K Jun 26 04:52 amdgpu_tahiti_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    75K Jun 26 04:52 radeon_tahiti_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    75K Jun 26 04:52 amdgpu_tahiti_smc_bin.ko
-r-xr-xr-x  1 root  wheel    75K Jun 26 04:52 radeon_tahiti_smc_bin.ko
-r-xr-xr-x  1 root  wheel    75K Jun 26 04:52 amdgpu_verde_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    75K Jun 26 04:52 radeon_verde_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:51 amdgpu_oland_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:52 radeon_oland_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:52 radeon_TAHITI_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:51 amdgpu_oland_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:52 radeon_oland_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:51 amdgpu_banks_k_2_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:51 amdgpu_hainan_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:52 radeon_hainan_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:51 amdgpu_pitcairn_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:52 radeon_pitcairn_k_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:52 amdgpu_verde_smc_bin.ko
-r-xr-xr-x  1 root  wheel    73K Jun 26 04:52 radeon_verde_smc_bin.ko
-r-xr-xr-x  1 root  wheel    72K Jun 26 04:51 amdgpu_hainan_smc_bin.ko
-r-xr-xr-x  1 root  wheel    72K Jun 26 04:52 radeon_hainan_smc_bin.ko
-r-xr-xr-x  1 root  wheel    72K Jun 26 04:51 amdgpu_pitcairn_smc_bin.ko
-r-xr-xr-x  1 root  wheel    72K Jun 26 04:52 radeon_pitcairn_smc_bin.ko
-r-xr-xr-x  1 root  wheel    71K Jun 26 04:52 radeon_VERDE_smc_bin.ko
-r-xr-xr-x  1 root  wheel    71K Jun 26 04:52 radeon_PITCAIRN_smc_bin.ko
-r-xr-xr-x  1 root  wheel    70K Jun 26 04:52 radeon_OLAND_smc_bin.ko
-r-xr-xr-x  1 root  wheel    70K Jun 26 04:52 radeon_HAINAN_smc_bin.ko
-r-xr-xr-x  1 root  wheel    61K Jun 26 04:52 amdgpu_vega20_rlc_bin.ko
-r-xr-xr-x  1 root  wheel    60K Jun 26 04:52 radeon_TAHITI_vce_bin.ko
-r-xr-xr-x  1 root  wheel    55K Jun 26 04:51 amdgpu_navi10_rlc_bin.ko
-r-xr-xr-x  1 root  wheel    55K Jun 26 04:51 amdgpu_navi12_rlc_bin.ko
-r-xr-xr-x  1 root  wheel    54K Jun 26 04:51 amdgpu_navi14_rlc_bin.ko
-r-xr-xr-x  1 root  wheel    51K Jun 26 04:51 amdgpu_raven_kicker_rlc_bin.ko
-r-xr-xr-x  1 root  wheel    51K Jun 26 04:51 amdgpu_picasso_rlc_am4_bin.ko
-r-xr-xr-x  1 root  wheel    50K Jun 26 04:51 amdgpu_picasso_rlc_bin.ko
-r-xr-xr-x  1 root  wheel    50K Jun 26 04:52 amdgpu_raven_rlc_bin.ko
-r-xr-xr-x  1 root  wheel    50K Jun 26 04:52 amdgpu_renoir_rlc_bin.ko
-r-xr-xr-x  1 root  wheel    50K Jun 26 04:51 amdgpu_raven2_rlc_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:51 amdgpu_navi10_sdma1_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:51 amdgpu_navi12_sdma1_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:51 amdgpu_navi14_sdma1_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:51 amdgpu_navi10_sdma_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:51 amdgpu_navi12_sdma_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:51 amdgpu_navi14_sdma_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:51 amdgpu_picasso_ta_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:51 amdgpu_raven2_ta_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:52 amdgpu_renoir_ta_bin.ko
-r-xr-xr-x  1 root  wheel    45K Jun 26 04:51 amdgpu_polaris11_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:51 amdgpu_polaris10_k_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:51 amdgpu_polaris11_k_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:51 amdgpu_polaris12_k_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:51 amdgpu_hawaii_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:52 radeon_hawaii_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:51 amdgpu_polaris10_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:51 amdgpu_polaris12_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:52 amdgpu_si58_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:52 radeon_HAWAII_mc2_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:51 amdgpu_bonaire_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:52 radeon_bonaire_mc_bin.ko
-r-xr-xr-x  1 root  wheel    44K Jun 26 04:52 amdgpu_topaz_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 amdgpu_verde_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_verde_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:51 amdgpu_hainan_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_hainan_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:51 amdgpu_oland_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_oland_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_BONAIRE_mc2_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 amdgpu_tahiti_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_tahiti_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_HAWAII_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:51 amdgpu_pitcairn_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_pitcairn_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_VERDE_mc2_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_BONAIRE_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_HAINAN_mc2_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_HAINAN_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_OLAND_mc2_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_OLAND_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 amdgpu_tonga_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_TAHITI_mc2_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_CAYMAN_smc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_PITCAIRN_mc2_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_PITCAIRN_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_TAHITI_mc_bin.ko
-r-xr-xr-x  1 root  wheel    43K Jun 26 04:52 radeon_VERDE_mc_bin.ko
-r-xr-xr-x  1 root  wheel    41K Jun 26 04:51 amdgpu_navi10_ta_bin.ko
-r-xr-xr-x  1 root  wheel    41K Jun 26 04:51 amdgpu_navi12_ta_bin.ko
-r-xr-xr-x  1 root  wheel    41K Jun 26 04:51 amdgpu_navi14_ta_bin.ko
-r-xr-xr-x  1 root  wheel    41K Jun 26 04:52 amdgpu_raven_ta_bin.ko
-r-xr-xr-x  1 root  wheel    40K Jun 26 04:52 amdgpu_vega12_rlc_bin.ko
…
root@mowa219-gjp4-8570p:~ #
```


----------



## Alain De Vos (Jul 4, 2021)

There is also
/usr/src/tools/tools/drm/radeon/firmwares


----------



## astyle (Jul 4, 2021)

Alain De Vos said:


> There is also
> /usr/src/tools/tools/drm/radeon/firmwares


Yeah, that's just tools to handle *imported* firmwares, accoding to the README. This does mean that the firmwares have to be imported first, as in, installed via graphics/drm-kmod. And that, as we know, installs to /boot/modules/ directory. If you don't install graphics/drm-kmod (I did not), those tools have no firmwares to work with, so nothing will get copied to /boot/kernel/ directory.


----------



## Alain De Vos (Jul 4, 2021)

But the files on my computer must come from somewhere.
Maybe you compiled WITHOUT_MODULES ?


----------



## astyle (Jul 4, 2021)

Alain De Vos said:


> But the files on my computer must come from somewhere.
> Maybe you compiled WITHOUT_MODULES ?


Dunno, I did not mess with the makefile at all... just ran `# make buildkernel` in /usr/src/. I did not install any packages or even the ports tree, just compiled the kernel BEFORE doing anything on a cleanly installed system. I think you can find the default makefile in FreeBSD's github repo. Your files clearly came from graphics/drm-kmod... FWIW, I did get the zfs.ko module in my compilation, so it looks like the WITHOUT_MODULES option is not turned on by default.


----------



## Alain De Vos (Jul 4, 2021)

I modified every file, including kernel conf, make conf , src conf etc ... Maybe it's that somewhere.


----------



## astyle (Jul 4, 2021)

Alain De Vos said:


> I modified every file, including kernel conf, make conf , src conf etc ... Maybe it's that somewhere.


Makes me think that you first modified make.conf, compiled a few ports, including graphics/drm-kmod, and afterwards, compiled the kernel. 

Try compiling the kernel with full, complete knowledge that you did *not* install graphics/drm-kmod. 
To verify anything, eliminate uncertainties as much as possible. That is an ironclad rule among engineers.


----------



## grahamperrin@ (Jul 4, 2021)

astyle said:


> … so it looks like the WITHOUT_MODULES option is not turned on by default.



▶ Working with WITHOUT_MODULES and custom kernels | The FreeBSD Forums


----------



## grahamperrin@ (Jul 4, 2021)

Opening poster donallen



grahamperrin said:


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



Please, did you try?


----------



## astyle (Jul 4, 2021)

Good thing I keep a sort of a 'Diary' of what I did under FreeBSD. Complete with action dates, package names, versions, timestamps, hashes, and the order in which I did it. That was a suggestion I picked up way back in 2002 for messing with Linux, but it still helps for working with FreeBSD. With that background, I took a look at my notes.

Turns out that when you compile graphics/drm-kmod, the* port will offer you to install kernel module sources*. Being in the habit of turning on as many options as I can, I would say yes to that. It looks like Alain De Vos said yes to that same option, and afterwards, compiled the kernel. This is how he ended up with those graphics drivers in /boot/kernel/ directory.

The order in which you do stuff on FreeBSD matters to a bigger extent than many realize. It is a headache to do my planning with that in mind, but that's the secret sauce I use.


----------



## Alain De Vos (Jul 4, 2021)

Freshports,
*Configuration Options*: 
No options to configure
*Options name*: 
graphics_drm-kmod


----------



## astyle (Jul 4, 2021)

OK, I guess i will need to post a walk-through:




 Yes, as per freshports.org, there will be 'No options to configure'. But wait - this port will pull in a dependency: graphics/drm-fbsd13-kmod. This is where you get the option to install kernel modules, as shown in next screenshot.


 If you say yes to installing kernel module sources, then the graphics drivers will be added to /usr/src/, which is where kernel sources are supposed to live. If you don't say yes to the SOURCES option, then the graphics drivers will not be added. Alain De Vos said yes there, which is why he ended up with sources for graphics drivers in /usr/src/, they got detected by Make and compiled, and thus deposited into /boot/kernel/ directory.
Surprising what paying attention to the process and connecting the dots will uncover. Less crapshoot troubleshooting in random places.

Oh, and BTW - all this was done AFTER I compiled my kernel.


----------



## Alain De Vos (Jul 4, 2021)

My make.conf explains,

```
OPTIONS_SET+=SOURCE
OPTIONS_SET+=SOURCE_HIGHLIGHT
OPTIONS_SET+=SOURCES
```
Who would have thought ...
Great Sherlock Homes work astyle.


----------



## donallen (Oct 8, 2021)

After a tour of the other BSDs on the machine in question with very mixed results, I changed my mind and decided to revisit this. I've found a workaround that seems to be reliable. I have no idea why it works, but so far, so good (perhaps like the old joke about the guy passing the 50th floor after jumping off the Empire State Building).

Using kld_list in /etc/rc.conf does not work. If you attempt to load radeonkms there, the system will crash when booting. The suggestion (by one of the contributors to this thread) to use "drm" instead of "radeonkms" in kld_list also does not work in my case. The system does not crash, but you get VGA resolution when X is started.

Prior to starting X, logging in as root and doing 'kldload radeonkms' seems to work reliably. I can then log in as myself, startx, and the resolution is correct. So I arranged
for sudo to allow me to do this command without a password and tried adding 'sudo /sbin/kldload radeonkms' to my .xinitrc at the very beginning. This crashes the system after 'startx'. But, if I issue the kldload prior to startx and then do the startx (with the kldload command removed from .xinitrc), it seems to work, though I have very few samples at this point. So there seems to be some sort of timing dependency here.

As I observed earlier, this is really a mess. The documentation is inaccurate and getting the kernel module loaded seems to be fragile. I will try to compose a bug report about this.

Other than this problem, the system seems to work well on this machine, though again, I don't have a lot of data yet.


----------



## Vull (Oct 8, 2021)

donallen said:


> After a tour of the other BSDs on the machine in question with very mixed results, I changed my mind and decided to revisit this. I've found a workaround that seems to be reliable. I have no idea why it works, but so far, so good (perhaps like the old joke about the guy passing the 50th floor after jumping off the Empire State Building).
> 
> Using kld_list in /etc/rc.conf does not work. If you attempt to load radeonkms there, the system will crash when booting. The suggestion (by one of the contributors to this thread) to use "drm" instead of "radeonkms" in kld_list also does not work in my case. The system does not crash, but you get VGA resolution when X is started.
> 
> ...


Have you tried installing x11-drivers/xf86-video-ati yet? My configuration doesn't work without it.

If so, what is the model number of your Radeon device? I have "CPU: AMD A6-6310 APU with AMD Radeon R4 Graphics" (according to `dmesg -a | grep -i radeon`), with xf86-video-ati installed, and kld_list="acpi_video", on FreeBSD-13.0-RELEASE. Everything works just fine, with any of `startx`, x11/sddm, or x11/lightdm having been used, tested, and proven for starting graphics, without using /boot/loader.conf or `kldload` to load any kernel modesetting driver. Instead, X with xf86-video-ati does it automatically right after X starts.


----------



## astyle (Oct 8, 2021)

donallen said:


> Using kld_list in /etc/rc.conf does not work


Y'know, a lot of times, things don't work because of typos.


----------



## donallen (Oct 8, 2021)

Vull said:


> Have you tried installing x11-drivers/xf86-video-ati yet? My configuration doesn't work without it.
> 
> If so, what is the model number of your Radeon device? I have "CPU: AMD A6-6310 APU with AMD Radeon R4 Graphics" (according to `dmesg -a | grep -i radeon`), with xf86-video-ati installed, and kld_list="acpi_video", on FreeBSD-13.0-RELEASE. Everything works just fine, with any of `startx`, x11/sddm, or x11/lightdm having been used, tested, and proven for starting graphics, without using /boot/loader.conf or `kldload` to load any kernel modesetting driver. Instead, X with xf86-video-ati does it automatically right after X starts.


dmesg: CPU: AMD A8-3850 APU with Radeon(tm) HD Graphics (2900.29-MHz K8-class CPU)
Linux lspci: [AMD/ATI] Sumo [Radeon 6550d]

Yes, I tried installing xf86-video-ati. No help.


----------



## astyle (Oct 8, 2021)

donallen said:


> dmesg: CPU: AMD A8-3850 APU with Radeon(tm) HD Graphics (2900.29-MHz K8-class CPU)
> Linux lspci: [AMD/ATI] Sumo [Radeon 6550d]
> 
> Yes, I tried installing xf86-video-ati. No help.


Yeah, this is why `radeonkms.ko` is the correct driver to use. And `kld_list="/boot/modules/radeonkms.ko"` is the line to use in /etc/rc.conf, you can copy-paste that. And pay attention to typos and spaces - those do make a difference in whether things work or not.


----------



## donallen (Oct 8, 2021)

astyle said:


> Y'know, a lot of times, things don't work because of typos.


Really?? After 57 years of writing code, 44 of them professionally, I'm surprised to learn this. I thought you could just type any old thing at it and it would Do What I Mean  

Seriously, I checked this carefully. I'm no youngster but I can still type 'radeonkms' and verify that's what I typed. And I did this more than once -- first at the time of my original post and again yesterday, after a fresh install. Same result -- dead system.

I booted Linux (from a USB key) to get the lspci output I provided in my previous message. When I rebooted FreeBSD, 'sudo kldload radeonkms' killed the system. Rebooting again, it worked. (And yes, typed correctly both times.) So this method isn't completely reliable/deterministic.


----------



## Alain De Vos (Oct 8, 2021)

It is advisable to do a cold-restart , i.e. like pull the power plug when you switch from linux to freebsd or vice-versa.
I had the video card being wrongly initialised with a warm-restart. (could even be bios related)


----------



## astyle (Oct 8, 2021)

donallen said:


> Really?? After 57 years of writing code, 44 of them professionally, I'm surprised to learn this. I thought you could just type any old thing at it and it would Do What I Mean
> 
> Seriously, I checked this carefully. I'm no youngster but I can still type 'radeonkms' and verify that's what I typed. And I did this more than once -- first at the time of my original post and again yesterday, after a fresh install. Same result -- dead system.
> 
> I booted Linux (from a USB key) to get the lspci output I provided in my previous message. When I rebooted FreeBSD, 'sudo kldload radeonkms' killed the system. Rebooting again, it worked. (And yes, typed correctly both times.) So this method isn't completely reliable/deterministic.


Y'know, the reason it's not working is because you keep skipping the* .ko *ending. That's your typo.

Also, don't do sudo on FreeBSD - that's different from Linux. on FreeBSD, the proper way to do it is `su root` first.


----------



## Alain De Vos (Oct 8, 2021)

Tip, when you compile graphics/drm-kmod with explicit kernel modules enabled , you only normally need:
rc.conf

```
Kernel modules to load after local disks are mounted
kld_list="drm radeonkms"
```
(nothing more to do)


----------



## donallen (Oct 8, 2021)

astyle said:


> Y'know, the reason it's not working is because you keep skipping the* .ko *ending. That's your typo.


Wrong. From 'man rc.conf':

"
 kld_list    (str) A whitespace-separated list of kernel modules to load
                 right after the local disks are mounted, without any .ko <<<<<<<<<----------------------
                 extension or path.  Loading modules at this point in the boot
                 process is much faster than doing it via /boot/loader.conf
                 for those modules not necessary for mounting local disks.




astyle said:


> Also, don't do sudo on FreeBSD - that's different from Linux. on FreeBSD, the proper way to do it is `su root` first.



Says who? sudo is available as an installable package and sudo and su are not equivalent. I'm well aware of the security implications of sudo misuse.


----------



## donallen (Oct 8, 2021)

astyle said:


> Yeah, this is why `radeonkms.ko` is the correct driver to use. And `kld_list="/boot/modules/radeonkms.ko"` is the line to use in /etc/rc.conf, you can copy-paste that. And pay attention to typos and spaces - those do make a difference in whether things work or not.


Very interesting. Using the absolute path does work, contrary to what it says in the man page, which I quote again:

 kld_list    (str) A whitespace-separated list of kernel modules to load
                 right after the local disks are mounted, *without any .ko
                 extension or path*.  Loading modules at this point in the boot
                 process is much faster than doing it via /boot/loader.conf
                 for those modules not necessary for mounting local disks.

Emphasis mine. kld_list="radeonkms", which I used based on the man page, does not work. So either this is a bug in the documentation or the code.

There is a closed bug report that relates to this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234248. I will open a new bug report.

I will use your absolute-path workaround. Hopefully it will prove more reliable than manually loading the module. Thanks for the suggestion.


----------



## astyle (Oct 8, 2021)

donallen said:


> Very interesting. Using the absolute path does work, contrary to what it says in the man page, which I quote again:
> 
> kld_list    (str) A whitespace-separated list of kernel modules to load
> right after the local disks are mounted, *without any .ko
> ...


YW. One more thing: On my rig, for some reason, what worked is to have that line be the VERY LAST one in /etc/rc.conf, even though documentation and other forum users said otherwise. I even played with that just to make sure. I'm on 13-RELEASE, BTW.


----------



## donallen (Oct 8, 2021)

astyle said:


> YW. One more thing: On my rig, for some reason, what worked is to have that line be the VERY LAST one in /etc/rc.conf, even though documentation and other forum users said otherwise. I even played with that just to make sure. I'm on 13-RELEASE, BTW.


I'm also running 13.


----------



## Argentum (Oct 8, 2021)

astyle said:


> YW. One more thing: On my rig, for some reason, what worked is to have that line be the VERY LAST one in /etc/rc.conf, even though documentation and other forum users said otherwise. I even played with that just to make sure. I'm on 13-RELEASE, BTW.


This is even more interesting. The position of `kld_list=` in /etc/rc.conf should actually have no impact. I think I have it somewhere on the 14-th line on this system.

`kld_list="amdgpu /boot/kernel/tcp_rack.ko"`
... and both modules get loaded...


----------



## grahamperrin@ (Oct 8, 2021)

`kld_list="radeonkms"` is suitable in the vast majority of _radeonkms_ FreeBSD 13.⋯ situations.

<https://www.freshports.org/graphics/drm-fbsd13-kmod/#message> is correct for FreeBSD 13.⋯.



donallen said:


> … Using the absolute path does work, …



Output, please, from this command (paste as code):

`ls /boot/kernel`



donallen said:


> … there seems to be some sort of timing dependency …



I believe so, for some use cases. From a recent comment by me in GitHub:

"My sense of things is that timely auto-loading of `drm` … with _later_ auto-loading of `radeonkms` is less likely to trigger …"



donallen said:


> … tried adding 'sudo /sbin/kldload radeonkms' to my .xinitrc at the very beginning. This crashes the system after 'startx'. …



By _system crash_, do you mean a kernel panic?



Alain De Vos said:


> `kld_list="drm radeonkms"`



`drm` there is superflous.


----------



## donallen (Oct 8, 2021)

grahamperrin said:


> `kld_list="radeonkms"` is suitable in the vast majority of _radeonkms_ FreeBSD 13.⋯ situations.



Albert Einstein once said "In theory, there's no difference between theory and practice."

Your theory conforms to what the rc.conf man page says. But at least in my practice, it does not work. As I've said multiple times in this thread, the system crashes on boot. And by crash, I mean a freeze. Not ping-able from a nearby Linux system on the same Ethernet and completely unresponsive.  There is no on-screen chatter about a kernel panic.


grahamperrin said:


> <https://www.freshports.org/graphics/drm-fbsd13-kmod/#message> is correct for FreeBSD 13.⋯.
> 
> 
> 
> ...



It's enormous; I'm not going to paste it here. Why don't you just accept my word that I downloaded

FreeBSD-13.0-RELEASE-amd64-mini-memstick.img.xz

yesterday, dd'ed it to a USB key and installed it (UFS, not ZFS). So the /boot/kernel I have is what you get from a vanilla install.



grahamperrin said:


> I believe so, for some use cases. From a recent comment by me in GitHub:
> 
> "My sense of things is that timely auto-loading of `drm` … with _later_ auto-loading of `radeonkms` is less likely to trigger …"
> 
> ...



See above.


grahamperrin said:


> `drm` there is superflous.


----------



## Vull (Oct 8, 2021)

astyle said:


> YW. One more thing: On my rig, for some reason, what worked is to have that line be the VERY LAST one in /etc/rc.conf, even though documentation and other forum users said otherwise. I even played with that just to make sure. I'm on 13-RELEASE, BTW.


I didn't expect that to work, but will give it a try.


----------



## Alexander88207 (Oct 8, 2021)

Hello donallen,

do you like to post a snippet from /var/log/messages where are you trying to load the module which causes a freeze? Maybe there is a message that could help you further.


----------



## astyle (Oct 8, 2021)

Alexander88207 said:


> Hello donallen,
> 
> do you like to post a snippet from /var/log/messages where are you trying to load the module which causes a freeze? Maybe there is a message that could help you further.


Like `cat /var/log/messages | nc termbin.com 9999`? I picked that idea up from SirDice , it's very useful for large output.


----------



## Alexander88207 (Oct 8, 2021)

astyle said:


> Like `cat /var/log/messages | nc termbin.com 9999`? I picked that idea up from SirDice , it's very useful for large output.



Yes, or he can use vesa() as a temporary fallback to have a minimal desktop at least.


----------



## grahamperrin@ (Oct 9, 2021)

donallen said:


> … a freeze. Not ping-able … completely unresponsive. …



Thanks. It's a set of symptoms that I have encountered on countless occasions. Last week, for example.

I have my workaround that involves straying from instructions for `kld_list`; my straying differs from your straying


----------



## Vull (Oct 9, 2021)

astyle said:


> ... `kld_list="/boot/modules/radeonkms.ko"` is the line to use in /etc/rc.conf...





donallen said:


> Very interesting. Using the absolute path does work...
> ... kld_list="radeonkms", which I used based on the man page, does not work...
> 
> ... I will use your absolute-path workaround. Hopefully it will prove more reliable than manually loading the module. Thanks for the suggestion.





astyle said:


> YW. One more thing: On my rig, for some reason, what worked is to have that line be the VERY LAST one in /etc/rc.conf, even though documentation and other forum users said otherwise. I even played with that just to make sure. I'm on 13-RELEASE, BTW





donallen said:


> I'm also running 13.





Vull said:


> I didn't expect that to work, but will give it a try.


So I did give it a try, but it didn't work... _for me._ (I'm also running 13.0-RELEASE.)

Let's summarize. We have uncovered at least 2 non-standard and undocumented workarounds to the problem of when and how to load the Radeon kernel mode-setting driver.


Most people who've reported success at loading radeonkms.ko on this forum modify kld_list as follows:

`kld_list="radeonkms"`


Both astyle and donallen find that doesn't work, and are using this syntax instead:

`kld_list="/boot/modules/radeonkms.ko"`

(Note: astyle might be using amdgpu.ko instead of radeonkms.ko with this syntax, I'm not sure.)


Both grahamperrin and I are leaving the kms driver out of kld_list altogether.

astyle's graphics card ID: Asus Radeon RX 550 4GB

donallen's graphics card ID: AMD A8-3850 APU with Radeon(tm) HD Graphics (2900.29-MHz K8-class CPU)

My graphics card ID: AMD A6-6310 APU with AMD Radeon R4 Graphics (on a Lenovo G50-45 model laptop)


More about my particular results:
If I pre-load the graphics driver via kld_list using either of the above noted syntaxes, my system will begin thrashing and show a black screen. This will happen regardless of whether or not I attempt to start X. If I act quickly enough, I might be able to switch to a virtual terminal using the CTRL-ALT function keys, but if I wait more than a few seconds, the system will freeze up and quickly become unresponsive to any key combination. It will also become inaccessible to ssh, requiring a power off (system halt) and reboot to recover.
I was able to capture output from `dmesg -a` showing sequences of drm messages for both normal and abnormal loading of the radeonkms.ko driver. Here is the relevant section showing a normal load sequence; this sequence is essentially the same whether I start X using `startx` or x11/lightdm:



			https://termbin.com/6tu3
		


... and here is the section showing the abnormal load sequence:



			https://termbin.com/42m6
		


Both sequences look essentially the same, up to the line which reads as follows in the normal sequence:
`Oct  9 02:14:40 mate kernel: Successfully added WC MTRR for [0xe0000000-0xefffff
ff]: 0;`

... that line is not included in the abnormal sequence. The sequences continue to match up to a point where it starts showing timeout errors, which look like this:
	
	



```
[drm ERROR :uvd_v1_0_ib_test] radeon: fence wait timed out.
[drm ERROR :radeon_ib_ring_tests] radeon: failed testing IB on ring 5 (-60).
[drm ERROR :radeon_vce_ib_test] radeon: fence wait timed out.
[drm ERROR :radeon_ib_ring_tests] radeon: failed testing IB on ring 6 (-60).
[drm ERROR :radeon_vce_ib_test] radeon: fence wait timed out.
[drm ERROR :radeon_ib_ring_tests] radeon: failed testing IB on ring 7 (-60).
```
Later in the sequence, it starts repeating "stalled" and "GPU lockup" messages like these:
	
	



```
drmn0: ring 3 stalled for more than 10000msec
drmn0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x000000000
0000003 on ring 3)
drmn0: ring 3 stalled for more than 10801msec
drmn0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x000000000
0000003 on ring 3)
```
The number of milliseconds in the "stalled" messages continues growing until the system eventually locks up.


----------



## donallen (Oct 9, 2021)

I posted a bug report about this yesterday. When writing it, I consulted /var/log/messages. There *is* a panic -- a page-fault in the kernel. A stack trace is included, courtesy the kernel debugger.

But things have changed this morning. I shut my system down last night. I attempted to reboot it this morning It took three tries to get the system up, the first two attempts resulted in crashes. This is with the full path to radeonkms.ko in rc.conf. I was fooled, prematurely drawing conclusions about the syntax of the line in rc.conf being causal from too few samples in a probabilistic situation. I think my experience this morning demonstrates that the syntax used in rc.conf is not the causal factor. There is clearly a timing bug in the process by which the radeonkms driver is installed and initialized. I will amend my bug report with this new information.

Unfortunately, this problem is likely to result in my having to switch back to Linux on this system.


----------



## grahamperrin@ (Oct 9, 2021)

Yeah, the senses of randomness can cause frustration. I empathise.



donallen said:


> Yes, I tried installing xf86-video-ati. No help.



Please retry with the driver installed. Or if it's already present (from an earlier attempt), retry with the driver deleted. Note, this plea is _not_ to doubt your earlier test result(s); it's based on personal experience.

Also try starting once in safe mode, then (if SDDM is enabled and apparent) immediately restart in normal mode.

If SDDM is enabled but not apparent in safe mode, then:

force off the computer
start in single user safe mode
`mount -uw / && service zfs onestart`
edit /etc/rc.conf to disable auto-start of SDDM
`exit` to multi-user safe mode then immediately restart in normal mode and … then maybe retry re-enabling auto-start of SDDM, and so on.
If "and so on" makes you want to scream, I'll understand  I've sort of been there, I nearly abandoned FreeBSD … I don't know when it was (maybe last year), ultimately I was (still am) glad that I stuck with it.



donallen said:


> I posted a bug report



Can you share a link? (If you already did so: apologies, I'm blind to it.)


----------



## donallen (Oct 9, 2021)

grahamperrin said:


> Yeah, the senses of randomness can cause frustration. I empathise.
> 
> 
> 
> ...


I'll try your suggestions. I'd like to find a reliable workaround for this bug, because once it's up, the system works well on this machine.


grahamperrin said:


> Can you share a link? (If you already did so: apologies, I'm blind to it.)


No problem with your eye-sight -- I forgot to include it in my previous message. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259019


----------



## donallen (Oct 9, 2021)

donallen said:


> I'll try your suggestions. I'd like to find a reliable workaround for this bug, because once it's up, the system works well on this machine.
> 
> No problem with your eye-sight -- I forgot to include it in my previous message. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259019


FYI, the xf86-video-ati package was *not* installed on my system during all the thrashing about we've been discussing. I have now installed it. I shut the system down (power off)  after doing so and rebooted. The system came up without incident. Only one data point, but a tiny bit encouraging.

I also then changed the infamous rc.conf line to
kld_list="radeonkms"

and rebooted. The system came up with the radeonkms driver apparently loaded, because the resolution in X is correct. We didn't need it, but this is further proof
that the syntax of that line in rc.conf is not the issue.


----------



## Vull (Oct 9, 2021)

I would tentatively agree that the kld_list syntax in /etc/rc.conf is _probably_ not the real issue, but rather, a _symptom_ of the real problem. It definitely seems to be a problem which involves the _timing and sequencing_ of graphics-related events, at least, on my particular system.

It could be very helpful if more people who report the black-screen problem were more willing to share their own graphics processor identification strings, and message logs. Logs of great size can still be easily accommodated on this forum by running commands such as `dmesg -a | nc termbin.com 9999` and `cat /var/log/messages | nc termbin.com 9999`, and then copying the output links into their posts. For example:
	
	



```
root@mate:~ # cat /var/log/messages | nc termbin.com 9999
https://termbin.com/slfwl
root@mate:~ #
```
And here is the link to provide access to my log. Note that the data of interest here will be prefixed with "Oct  9". These termbin.com links will reportedly persist for only about one month:



			https://termbin.com/slfwl
		


In my previous post I used a text editor to isolate what I considered to be the more pertinent portions of my dmesg logs, but your mileage may vary.

Also perhaps worth noting is the observation that, in my case at least, lightdm and sddm both seem to do a better job of starting graphics on my system than what I observe when using startx. Again, YMMV.


----------



## grahamperrin@ (Oct 9, 2021)

Probed two minutes ago: <https://bsd-hardware.info/?probe=1b48acadd5>

At a glance, nothing of interest in /var/log/dmesg.yesterday or <https://bsd-hardware.info/?probe=1b48acadd5&log=dmesg>.

Things of interest (to me) occurred _two days earlier_:


 

– Thursday 2021-10-07 07:26 BST

At the time of writing (not normally):


```
% date ; uptime
Sat  9 Oct 2021 22:28:36 BST
10:28p.m.  up  6:27, 5 users, load averages: 0.28, 0.48, 0.52
% sysrc kld_list
kld_list: fusefs usbhid radeonkms acpi_video
% pkg info xf86-video-ati
pkg: No package(s) matching xf86-video-ati
%
```

The workaround that I normally use was suspended, for test purposes, _a little more than a few days ago_, in relation to the issue that I raised around a month ago:

The system may fail to start properly – a blackout – if kld_list includes radeonkms (workaround: instead, load drm) · Issue #108 · freebsd/drm-kmod



> … Notes, from before I learnt the `drm` workaround, suggest that the issue was observable as far back as September 2018 (FreeBSD 12.0-ALPHA7 at the time). I never bothered to report the issue because I assumed a peculiarity with my setup.
> 
> Now I'm better prepared to make the issue reproducible, if I can …



I have a gut feeling about what will trigger the next blackout in my case. To not sow seeds of confusion (each person's case may differ): I'll not share details until after the time comes.

Postscript

Photographs added.


----------



## bakul (Oct 9, 2021)

donallen said:


> Very interesting. Using the absolute path does work,


FYI: When you specify an absolute path (with the .ko extension), only that file is tried. When you just specify the module name (without the .ko) extension (for example, "foo"), kldload tries  the following paths _in order_: /boot/kernel/foo, /boot/kernel/foo.ko, /boot/modules/foo, /boot/modules.ko and even paths such as a /boot/dtb{,/overlays}/foo{,ko} (on amd64)! So thing to check for is whether another module of the same name exists in /boot/kernel. Unlikely, but just in case.

If you loaded a kernel from a directory other than /boot/kernel, presumably it will first look for modules in that directory.


----------



## grahamperrin@ (Oct 9, 2021)

bakul said:


> … whether another module of the same name exists in /boot/kernel. Unlikely, …



Please see previous pages, <https://forums.FreeBSD.org/threads/81015/post-535786> in particular. Thanks.


----------



## astyle (Oct 10, 2021)

Vull said:


> So I did give it a try, but it didn't work... _for me._ (I'm also running 13.0-RELEASE.)
> 
> Let's summarize. We have uncovered at least 2 non-standard and undocumented workarounds to the problem of when and how to load the Radeon kernel mode-setting driver.
> 
> ...


Nice analysis... Yeah, I am using amdgpu.ko that is installed in /boot/modules/ by ports. That's what my card (Correctly identified as Asus Radeon RX 550 4GB) requires. But I'm seeing that:

My suggestion for donallen worked the first time (he said so himself). My suggestion is based on the wiki I linked to earlier.
The When Vull tries it on his hardware - it messes things up, and the kernel panic gets confirmed by grahamperrin ...
Argentum commented that it shouldn't matter where in /etc/rc.conf the line of code loading the driver is - last, not last, in the middle...
I guess I'm gonna watch this from the sidelines.


----------



## grahamperrin@ (Oct 10, 2021)

astyle said:


> kernel panic gets confirmed by _*[FONT=monospace]grahamperrin[/FONT]*_



Not confirmed by me.


----------



## astyle (Oct 10, 2021)

grahamperrin said:


> Not confirmed by me.


Looks like I misread something somewhere along the way.


----------



## Vull (Oct 10, 2021)

Re: kernel panic

I didn't see a kernel panic or a system halt. It was I who eventually forced a system halt by holding down the power button, or a system reboot, which, if I was fast enough, I could trigger by keying CTRL-ALT-DEL.

What I did see was the system thrashing in an endless loop between a "ring 3 stall" (or a "ring 0 stall", for a growing number of milliseconds on each iteration of the loop) and a "GPU lockup" event reported at "current fence id 0x0000000000000001 last fence id 0x0000000000000003 on ring 3" (or reported at some other fence ids on ring 0). Sometimes, early on, I might get a "GPU softreset" that looked like this:
	
	



```
Oct  9 01:42:17 mate kernel: drmn0: GPU softreset: 0x00000108
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS=0xA0003028
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS2=0x30000008
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE0=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE1=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE2=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE3=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   SRBM_STATUS=0x20020640
Oct  9 01:42:17 mate kernel: drmn0:   SRBM_STATUS2=0x00000080
Oct  9 01:42:17 mate kernel: drmn0:   SDMA0_STATUS_REG   = 0x46CEE557
Oct  9 01:42:17 mate kernel: drmn0:   SDMA1_STATUS_REG   = 0x46CEE557
Oct  9 01:42:17 mate kernel: drmn0:   CP_STAT = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT1 = 0x00000c00
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT2 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT3 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_BUSY_STAT = 0x584c0282
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_STALLED_STAT1 = 0x00000001
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_STATUS = 0x80008007
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_BUSY_STAT = 0x00000408
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_STALLED_STAT1 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_STATUS = 0xa0000041
Oct  9 01:42:17 mate kernel: drmn0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000
Oct  9 01:42:17 mate kernel: drmn0: Wait for MC idle timedout !
Oct  9 01:42:17 mate kernel: drmn0: GRBM_SOFT_RESET=0x00010001
Oct  9 01:42:17 mate kernel: drmn0: SRBM_SOFT_RESET=0x00000500
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS=0xA0003028
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS2=0x30000008
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE0=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE1=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE2=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   GRBM_STATUS_SE3=0x00000006
Oct  9 01:42:17 mate kernel: drmn0:   SRBM_STATUS=0x20000640
Oct  9 01:42:17 mate kernel: drmn0:   SRBM_STATUS2=0x00000080
Oct  9 01:42:17 mate kernel: drmn0:   SDMA0_STATUS_REG   = 0x46CEE557
Oct  9 01:42:17 mate kernel: drmn0:   SDMA1_STATUS_REG   = 0x46CEE557
Oct  9 01:42:17 mate kernel: drmn0:   CP_STAT = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT1 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT2 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_STALLED_STAT3 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_BUSY_STAT = 0x584c0000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_STALLED_STAT1 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPF_STATUS = 0x80008003
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_BUSY_STAT = 0x00000408
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_STALLED_STAT1 = 0x00000000
Oct  9 01:42:17 mate kernel: drmn0:   CP_CPC_STATUS = 0xa0000041
Oct  9 01:42:17 mate kernel: drmn0: GPU reset succeeded, trying to resume
Oct  9 01:42:17 mate kernel: drmn0: Wait for MC idle timedout !
Oct  9 01:42:17 mate syslogd: last message repeated 1 times
Oct  9 01:42:17 mate kernel: [drm] PCIE GART of 2048M enabled (table at 0x000000000030E000).
Oct  9 01:42:17 mate kernel: drmn0: WB enabled
```
But that would only lead right back to a repeat of the same kind of endless thrashing loop:
	
	



```
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0x0xfffff80007082c00
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 1 use gpu addr 0x0000000040000c04 and cpu addr 0x0xfffff80007082c04
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 2 use gpu addr 0x0000000040000c08 and cpu addr 0x0xfffff80007082c08
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0x0xfffff80007082c0c
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 4 use gpu addr 0x0000000040000c10 and cpu addr 0x0xfffff80007082c10
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 5 use gpu addr 0x0000000000078d30 and cpu addr 0x0xfffff800e0078d30
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 6 use gpu addr 0x0000000040000c18 and cpu addr 0x0xfffff80007082c18
Oct  9 01:42:17 mate kernel: drmn0: fence driver on ring 7 use gpu addr 0x0000000040000c1c and cpu addr 0x0xfffff80007082c1c
Oct  9 01:42:17 mate kernel: [drm ERROR :cik_ring_test] radeon: ring 0 test failed (scratch(0x3010C)=0xCAFEDEAD)
Oct  9 01:42:17 mate kernel: [drm ERROR :cik_resume] cik startup failed on resume
Oct  9 01:42:18 mate kernel: [drm ERROR :radeon_dp_link_train_cr] displayport link status failed
Oct  9 01:42:18 mate kernel: [drm ERROR :radeon_dp_link_train_cr] clock recovery failed
Oct  9 01:42:39 mate kernel: drmn0: ring 0 stalled for more than 10473msec
Oct  9 01:42:39 mate kernel: drmn0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x0000000000000002 on ring 0)
Oct  9 01:42:39 mate kernel: drmn0: ring 0 stalled for more than 10973msec
Oct  9 01:42:39 mate kernel: drmn0: GPU lockup (current fence id 0x0000000000000001 last fence id 0x0000000000000002 on ring 0)
```


----------



## Argentum (Oct 10, 2021)

Vull said:


> root@mate:~ # cat /var/log/messages | nc termbin.com 9999
> 
> 
> https://termbin.com/slfwl
> ...


Little off-topic, but Termbin is *cool*!


----------



## donallen (Oct 10, 2021)

Since installing xf86-video-ati at the suggestion of Vull and GrahamPerrin, I have rebooted my system several times without incident and with correct resolution in X. The radeonkms kernel module is also installed, loaded by kld_list="radeonkms" in rc.conf.

In an early post to this thread, I responded to a question about whether I'd installed xf86-video-ati and said "no help". What I meant was that the X driver by itself did not result in proper resolution when X comes up. At that point, I had not tried installing both that X driver and the radeonkms kernel driver. Unfortunately, I removed the X driver, since it appeared to serve no purpose, which appears to have been a mistake.

Given the crash free performance of my system through multiple reboots, it's beginning to look like you must have xf86-video-ati installed in order to use the radeonkms kernel driver. If true, then the bug is that installation of drm-kmod, either as a port or a package, does not depend upon the corresponding X drivers (xf86-video-intel, -ati, -amd) and should.


----------



## Alain De Vos (Oct 10, 2021)

Please note i don't have any xf86-...  package installed.
And my radeon card works 100% fine under Wayland.
kldstat | grep -i radeon

```
15    1 0xffffffff8233b000   14ec70 radeonkms.ko
17    1 0xffffffff81ddf000     3258 radeon_CAICOS_pfp_bin.ko
18    1 0xffffffff81de3000     3658 radeon_CAICOS_me_bin.ko
19    1 0xffffffff81de7000     2cd8 radeon_BTC_rlc_bin.ko
20    1 0xffffffff81dea000     7ef8 radeon_CAICOS_mc_bin.ko
21    1 0xffffffff81df2000     8098 radeon_CAICOS_smc_bin.ko
22    1 0xffffffff8248a000    341f0 radeon_SUMO_uvd_bin.ko
```
Offcourse different hardware can have different results.


----------



## grahamperrin@ (Oct 10, 2021)

donallen said:


> … it's beginning to look like you must have xf86-video-ati installed in order to use the radeonkms kernel driver. …



Above, for test purposes (ongoing), the `radeonkms` kernel module (from graphics/drm-current-kmod) *without* the x11-drivers/xf86-video-ati driver.

donallen with things now apparently stable for you, you might experimentally *delete* `xf86-video-ati`, restart the OS then – for a few days – refrain from any use of `pkg`, `freebsd-update`, `bectl` or `beadm` (i.e. avoid changing your boot environment). Refraining will be easier said than done


----------



## donallen (Oct 10, 2021)

Alain De Vos said:


> Please note i don't have any xf86-...  package installed.
> And my radeon card works 100% fine under Wayland.
> kldstat | grep -i radeon
> 
> ...


Exactly.


----------



## Vull (Oct 10, 2021)

Alexander88207 said:


> Yes, or he can use vesa() as a temporary fallback to have a minimal desktop at least.


I'm no expert on all this, but I remember some time back, on another thread, you might have mentioned some other kind of mode-setting driver, which I, perhaps incorrectly, speculated was also a video driver, as opposed to a kernel mode-setting driver.

I have only a pieced-together understanding of how all this works, gleaned mostly from reading related threads on this forum, and their associated links, so please don't hesitate to correct me, when and if I'm wrong in my partially-informed speculations.

Would I be correct in assuming that xf86-video-ati, xf86-video-amdgpu, xf86-video-intel, and vesa are all "video drivers" which sort of act as intermediary, or "go-between" drivers, between X and the kernel mode-setting drivers provided by drm-kmod? Namely, the radeonkms.ko, amdgpu.ko, and i915kms.ko drivers, which are packaged with drm-kmod? And would I be correct in also guessing that these three kernel mode-setting drivers are not "stand-alone" drivers, but rather, that they require some sort of video driver in order to function correctly?

Further I've speculated, from reading through my "Xorg.0.log" logs, that X, when starting up on the first time after the boot-up sequence, detects the video devices available, then looks for the correct video driver, or collection of video drivers, which correspond to the video hardware. Then, the video driver interfaces with the appropriate k.m.s. driver, if it's already loaded, or, alternatively, loads the appropriate k.m.s. driver if it's not already loaded.

What seems to be happening on my system is this: if the k.m.s. driver is specified by kld_list, it loads too early in the boot-up sequence, and it loads at a time when the video hardware is rapidly displaying unrelated message strings, which are being output by unrelated boot-up processes. This rapid sequence of unrelated events, in turn, "confuses" the k.m.s. driver, and/or the video hardware, and/or the graphics hardware. Some step or steps in the initialization process then fail, and this leads to the thrashing condition I've tried to describe in my previous posts.

However, if I leave the k.m.s. drivers unloaded until X starts up, there will be no boot-up messages being displayed during the time that the k.m.s. driver is being loaded, so the loading process is able to proceed unhindered, and so it succeeds in being correctly loaded.


----------



## Argentum (Oct 10, 2021)

Vull said:


> I'm no expert on all this, but I remember some time back, on another thread, you might have mentioned some other kind of mode-setting driver, which I, perhaps incorrectly, speculated was also a video driver, as opposed to a kernel mode-setting driver.
> 
> I have only a pieced-together understanding of how all this works, gleaned mostly from reading related threads on this forum, and their associated links, so please don't hesitate to correct me, when and if I'm wrong in my partially-informed speculations.
> 
> Would I be correct in assuming that xf86-video-ati, xf86-video-amdgpu, xf86-video-intel, and vesa are all "video drivers" which sort of act as intermediary, or "go-between" drivers, between X and the kernel mode-setting drivers provided by drm-kmod? Namely, the radeonkms.ko, amdgpu.ko, and i915kms.ko drivers, which are packaged with drm-kmod? And would I be correct in also guessing that these three kernel mode-setting drivers are not "stand-alone" drivers, but rather, that they require some sort of video driver in order to function correctly?


I would say that basically DRM is modesetting. In my boot messages:

```
Sep 20 16:30:53 Tuna2 kernel: [drm] amdgpu kernel modesetting enabled.
Sep 20 16:30:53 Tuna2 kernel: drmn0: <drmn> on vgapci0
Sep 20 16:30:53 Tuna2 kernel: VT: Replacing driver "efifb" with new "dummy".
Sep 20 16:30:53 Tuna2 kernel: vgapci0: child drmn0 requested pci_enable_io
Sep 20 16:30:53 Tuna2 syslogd: last message repeated 1 times
Sep 20 16:30:53 Tuna2 kernel: sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
Sep 20 16:30:53 Tuna2 kernel: [drm] initializing kernel modesetting (POLARIS10 0x1002:0x67DF 0x1043:0x051D 0xEF).
```

With DRM there is no need for Xorg video drivers. DRM can load the correct kernel modules, given an architecture and Xorg automatically recognizes it . Works on Intel, AMD and Radeon chips. The driver can also be used, but is not mandatory. Using driver may speed up a little, but for example in my case with AMD RX-570 using driver vs modesetting gives perhaps 1...2% of better performance. That is in the range of measurement error. So, no visible difference. I am talking only about AMD RX-500 series chips.


----------



## grahamperrin@ (Oct 10, 2021)

Vull said:


> Would I be correct in assuming that …



My limited understanding is that graphics/drm-kmod is intended to cover as many use cases as possible (excluding, for example, NVIDIA-only cases).

It's worth quoting from the current description <https://www.freshports.org/graphics/drm-kmod/#description> (with added emphasis):



> 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.



The WWW line within the description is probably outdated. Instead: <https://github.com/freebsd/drm-kmod/>

<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253524#c1> ▶ <https://gitter.im/FreeBSDDesktop/Lobby/archives/2021/04/15?at=6078d22e55d78266a6496bd5>:



> Rule of thumb, do developers in drm-kmod areas prefer bugs to be raised in GitHub i.e. https://github.com/freebsd/drm-kmod, or in FreeBSD Bugzilla?




My broader understanding of things is somewhat limited by the sparseness of, for example, the package description <https://www.freshports.org/x11-drivers/xf86-video-ati/#description> for *x11-drivers/xf86-video-ati*: 



> This package contains the X.Org xf86-video-ati driver.



*No mention of xf86-video-ati* in the FreeBSD Handbook, which is partly why I tire of people being casually directed to the book as if it might the fount of all wisdom. I mean, read an entire effing chapter about something as technically challenging as X.Org and be left with unanswered questions about drivers and a black screen or whatever. 

Cue: some hole declaring that FreeBSD is not for people like me.


----------



## Alexander88207 (Oct 10, 2021)

Vull​You need a xorg driver to be able to display anything with X. Those are called DDX (device dependent x) drivers, nowadays there is the generic modesetting driver included in the x server that works for modern GPUs.

Xorg drivers like xf86-video-amdgpu offers some additional features over modesetting. For example: FreeSync (VRR)

If you don't miss those features or dont have any other problems, you are fine with modesetting.

Only x11: DRM Driver -> xf86-video-amd/intel/ati or modesetting --> Xorg --> X11 Application

OpenGL: DRM Driver -> OpenGL DRI driver like mesa -> Xorg --> Game (as example)

If the first one is not the case then there is nothing accelerated at all.


----------



## grahamperrin@ (Oct 10, 2021)

Argentum said:


> … With DRM there is no need for Xorg video drivers. …





Alexander88207 said:


> … Xorg drivers like xf86-video-amdgpu offers some additional features over modesetting. …
> 
> If you don't miss those features or dont have any other problems, you are fine with modesetting.



Not recent, but recalling a problem: 

<https://gitter.im/FreeBSDDesktop/Lobby/archives/2020/09/21?at=5f688e2fb468994d0d41ef44> ◀ Thames [Radeon HD 7550M/7570M/7650M]: drm.ko in lieu of radeonkms, with xf86-video-ati (was: need some advice for video output) (2020-11-29) ◀ kld_list="drm" (was: i915kms kernel module causing freezes on FreeBSD 13.0-RELEASE) (2021-05-08)

– in partial response: 





(Ignore the `amdgpu` stuff. Suffice to say, I was clutching at straws.)


----------



## Vull (Oct 10, 2021)

Well in my 2 use cases, Lenovo laptop G50-45 and HP Stream, `pkg install xorg drm-kmod` has not been enough and I need another driver. Oddly, both have similar problems with putting kms drivers in kld_list but work okay without it. I've been using xf86-video-ati for Lenovo/Radeon, and xf86-video-intel for HP Stream/i915 but am open to alternatives.


----------

