Solved How to install and load AMD drivers for RX 580 on stable 12.2?

inf3rno said:
I don't want to mix pkg and ports if not necessary.
Click to expand...
This is NO problem at all if done only for single ports and from the same source (so, if you use quarterly packages, use quarterly ports tree, same for latest), and it will stop being necessary as soon as 12.1 is EOL.
inf3rno said:
Btw. I was able to start it by removing the xorg config file.
Click to expand...
There's almost NEVER a reason to have an xorg config file.
 
Zirias said:
This is NO problem at all if done only for single ports and from the same source (so, if you use quarterly packages, use quarterly ports tree, same for latest), and it will stop being necessary as soon as 12.1 is EOL.

There's almost NEVER a reason to have an xorg config file.
Click to expand...
I need Option "VariableRefresh", I don't think it is turned on by default.
 
Okay, I tried out with 12.2-RELEASE. It did not work from pkg as expected so I removed that and tried a make install clean for drm-kmod port. With that it boots, I still have the "ring 10 error", it goes past it, but I cannot start the x server. Without a config file it write that "no $DISPLAY" and with the config file it writes "no screen". I installed the Linux display driver with pkg install xf86-video-amdgpu and added an xorg config file that loads the amdgpu driver, still nothing. :S I can copy here the dmesg if that helps, I am out of ideas. In theory it should work, in practice it doesn't. I think the kernel module does not support 12.2 or it cannot ignore this "ring 10 error" as it did by 12.1. I suspect this because I did not have increased screen resolution for the terminal after loading it like I had by 12.1. Interesting that several amdgpu - polaris modules are loaded, but the dmesg writes that too. When I do kldload amdgpu it writes that it is already loaded, so in theory there is no problem with it.

Another issue I have that when I do a pkg update it tries to install the drm-kmod along with the drm-fbsd-12.0-kmod, so mixing ports and pkg has its own problems just as I expected. I hope it is possible to add these modules to some kind of ignore list or I'll have a hard time to keep the system up to date.
 

Attachments

  • dmesg.log.txt
    65.3 KB · Views: 151
  • Xorg.0.log.txt
    4 KB · Views: 145
So, you claim this ever worked with 12.1? This doesn't seem credible. Looks more like a known problem with the Linux 4.16 drm code:

105515 – hw_init of IP block <uvd_v6_0> failed

bugs.freedesktop.org bugs.freedesktop.org

If this gfx chip was already supported in Linux 4.11 drm, you can try to use graphics/drm-fbsd11.2-kmod instead. It builds on 12.x with the following patch:

Code: 
--- graphics/drm-fbsd11.2-kmod/Makefile	(revision 558220)
+++ graphics/drm-fbsd11.2-kmod/Makefile	(working copy)
@@ -25,6 +25,8 @@
 
 USES=		kmod uidfix
 
+CFLAGS+=	-Wno-visibility
+
 USE_GITHUB=	yes
 GH_ACCOUNT=	FreeBSDDesktop
 GH_PROJECT=	kms-drm
@@ -32,10 +34,6 @@
 
 .include <bsd.port.options.mk>
 
-.if ${OPSYS} == FreeBSD && ${OSVERSION} > 1200000
-IGNORE=		only supported on FreeBSD 11.
-.endif
-
 .if ${OPSYS} != FreeBSD
 IGNORE=		not supported on anything but FreeBSD (missing linuxkpi functionality)
 .endif

Otherwise, you could go with the latest drm, but AFAIK this requires running 13-CURRENT.

edit: To get rid of pkg wanting to install official drm packages, just remove the drm-kmod package. It's not needed, it's just a meta package for conveniently installing the correct driver package.
 
Zirias said:
So, you claim this ever worked with 12.1? This doesn't seem credible.
Click to expand...
I had a working KDE with 12.1 yesterday before I installed 12.2 on the same drive. I had a different motherboard when I installed 12.1, and I had the same ring 10 error, but somehow it worked. I'll try it again after I gave up 12.2.
Zirias said:
If this gfx chip was already supported in Linux 4.11 drm, you can try to use graphics/drm-fbsd11.2-kmod instead.
Click to expand...
Ok I'll try it.
 
To run 13-CURRENT on a "production" workstation, the only sensible way is to compile it yourself (to get rid of several debugging features eating CPU cycles like crazy).

I only use it on a little virtual machine for testing poudriere builds and it's reasonably stable there, but it can always happen that something is utterly broken after svn up and rebuild. Without a pressing reason, I'd never recommend to use it for a "production" system.

If you can get your GPU to work with either drm-fbsd12.0-kmod or drm-fbsd11.2-kmod, and this feature isn't crucial, better stick with latest -RELEASE.
 
inf3rno said:
Ohh good to know. But how stable is that? I can live without freesync for a while if 13-CURRENT crashes every 5 mins...
Click to expand...

The driver itself was stable for me, only other applications might have problems. For example, in the past the window manager of mate (marco) always crashed when a window was closed 😄

Also a -CURRENT system have to be maintained from source.
 
Just to mention, to rebuild the metaport graphics/drm-kmod correctly you have to remove the graphics/drm-kmod package with pkg remove drm-kmod then cleanup the run dependencies with pkg autoremove before starting to rebuild it.
 
This discussion is unnecessary, as amdgpu.ko built for 12.1 would just cause a kernel panic on 12.2. So we already know it was built correctly. But again, just get rid of drm-kmod meta-package.
 
Zirias said:
From the attached dmesg, it's obvious the module WAS compiled for 12.2.
Click to expand...

This should not always be relied upon, for example it was possible to use a FreeBSD 12.0 drm on FreeBSD 12.1 with amdgpu (at least with my card) as in the case there was no big mismatch.
 
We already had several reports that amdgpu.ko compiled for 12.1 DOES panic when loading on 12.2, so I think in this case, we can rely on that.
 
Okay, I removed the old stuff with pkg delete and autoremove and now I built only drm-fbsd12.0-kmod The result is the exact same after rebooting. The build log is too big to upload it here and the page does not allow archives. Is there any alternative you can recommend for bigger files than the limit? Or should I check something in the log?
 
An assumed build problem is almost certainly a red herring here.
I'd recommend trying drm-fbsd11.2-kmod (see patch above to have it build) instead. As already stated, the problem you're seeing was reported for Linux 4.16 as well, so there is a (little) chance the Linux 4.11 drm drivers work for your hardware.
 
You must log in or register to reply here.
Back
Top