... kld_list="/boot/modules/radeonkms.ko" is the line to use in /etc/rc.conf...
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.
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.
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:
... and here is the section showing the abnormal load sequence:
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:
Code:
[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:
Code:
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.
