Solved Radeon RX 6600 stopped working after recent updates

tankist02 · Feb 18, 2024

FreeBSD 14.0 RELEASE-p5
Latest packages fully updated.

Used to work just fine, now startx gives "Segmenation fault at address 0x2"
Checking dmesg, loaded modules, xorg config - everything looks fine.

What's going on with this card support?

shkhln · Feb 20, 2024

If you installed mesa-devel, remove it.

nxjoseph · Feb 20, 2024

I was thinking to ditch my game console and buy an AMD card, like RX 6600 to do GPU Passthrough with bhyve. I would be appreciated if you let me know how does it do on FreeBSD.

shkhln said:
If you installed mesa-devel, remove it.

What was the reason why you suggested it?

shkhln · Feb 21, 2024

nxjoseph said:
What was the reason why you suggested it?

What an odd question.

tankist02 · Feb 21, 2024

shkhln said:
If you installed mesa-devel, remove it.

Did not help. Xorg fails with the message that cannot load amdpgu since it does not exist. While kldstat clearly shows this module is loaded. dmesg shows that correct AMD firmware modules are also loaded.
According to Bugzilla there are problems with drm-515-kmod which are being fixed. I guess I'll have to wait.

shkhln · Feb 21, 2024

tankist02 said:
Xorg fails with the message that cannot load amdpgu since it does not exist. While kldstat clearly shows this module is loaded.

The kernel doesn't have a monopoly on the word "module". (What happened to "0x2"?)

tankist02 · Feb 21, 2024

shkhln said:
The kernel doesn't have a monopoly on the word "module". (What happened to "0x2"?)

The crash at 0x2 is gone, but it seems it was kind of intermittent before. While playing with installing/reinstalling AMD related packages I remember I had 2 errors: either the fault at 0x2 or failure to load amdgpu.

astyle · Feb 22, 2024

tankist02 said:
The crash at 0x2 is gone, but it seems it was kind of intermittent before. While playing with installing/reinstalling AMD related packages I remember I had 2 errors: either the fault at 0x2 or failure to load amdgpu.

When you reinstall amdgpu, it's a good idea to check that /boot/modules/amdgpu or/boot/kernel/amdgpu actually exists with an ls -l ... if it looks suspiciously small, that's a problem.

astyle · Feb 22, 2024

nxjoseph said:
What was the reason why you suggested it?

Well, graphics/mesa-devel is not needed in this case, and can potentially interfere.

Sometimes, a package has -devel in the name, that usually suggests header files, libs, and templates to set up your own copy of the project to hack on. Sometimes it means alpha or beta quality work that is aimed at devs, rather than regular users. Precise meaning of that term has been rather inconsistent from one project to another (which is an unfortunate reality of Open Source), so keep your eyes peeled.

tankist02 · Feb 22, 2024

astyle said:
When you reinstall amdgpu, it's a good idea to check that /boot/modules/amdgpu or/boot/kernel/amdgpu actually exists with an ls -l ... if it looks suspiciously small, that's a problem.

Look normal?

Code:

andrew@obama:~$ ll /boot/modules/amd*
-r-xr-xr-x  1 root wheel 8581752 Jan  1 00:17 /boot/modules/amdgpu.ko
-rw-r--r--  1 root wheel 8621776 Feb 18 10:41 /boot/modules/amdgpu.ko-built
-r-xr-xr-x  1 root wheel  275976 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_ce_bin.ko
-r-xr-xr-x  1 root wheel  125496 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_dmcub_bin.ko
-r-xr-xr-x  1 root wheel  276104 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_me_bin.ko
-r-xr-xr-x  1 root wheel  281440 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_mec2_bin.ko
-r-xr-xr-x  1 root wheel  281424 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_mec_bin.ko
-r-xr-xr-x  1 root wheel  276128 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_pfp_bin.ko
-r-xr-xr-x  1 root wheel  149936 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_rlc_bin.ko
-r-xr-xr-x  1 root wheel   46768 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_sdma_bin.ko
-r-xr-xr-x  1 root wheel  257608 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_smc_bin.ko
-r-xr-xr-x  1 root wheel  223120 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_sos_bin.ko
-r-xr-xr-x  1 root wheel  231048 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_ta_bin.ko
-r-xr-xr-x  1 root wheel  592272 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_vcn_bin.ko
andrew@obama:~$ ll /boot/kernel/amd*
-r-xr-xr-x  2 root wheel 18928 Jan  4 17:18 /boot/kernel/amd_ecc_inject.ko
-r-xr-xr-x  2 root wheel 31336 Jan  4 17:18 /boot/kernel/amdgpio.ko
-r-xr-xr-x  2 root wheel 26456 Jan  4 17:18 /boot/kernel/amdpm.ko
-r-xr-xr-x  2 root wheel 23688 Jan  4 17:18 /boot/kernel/amdsbwd.ko
-r-xr-xr-x  2 root wheel 21544 Jan  4 17:18 /boot/kernel/amdsmb.ko
-r-xr-xr-x  2 root wheel 18272 Jan  4 17:18 /boot/kernel/amdsmn.ko
-r-xr-xr-x  2 root wheel 31392 Jan  4 17:18 /boot/kernel/amdtemp.ko

I think this discussion on Bugzilla might be relevant

I'd like to try the 515-lts-focal branch, but do not know what exactly I build and how I deploy the binaries? If I build just amdgpu.ko and copy it over then the system freezes when booting.

tankist02 · Feb 22, 2024

I cloned the repo https://github.com/wulf7/drm-kmod.git, switched to the branch 515-lts-focal, built from the root and got a bunch of *.ko files:

andrew@obama:drm-kmod$ find . -name \*.ko
./ttm/ttm.ko
./i915/i915kms.ko
./dmabuf/dmabuf.ko
./amd/amdgpu/amdgpu.ko
./radeon/radeonkms.ko
./drm/drm.ko

Do I just copy them over to /boot/modules? What about a bunch of amdgpu_dimgrey_cavefish*.ko files I have in /boot/modules?

astyle · Feb 22, 2024

tankist02 said:
-rw-r--r-- 1 root wheel 8621776 Feb 18 10:41 /boot/modules/amdgpu.ko-built

This part, I'd question the need for it to be in there at all, especially alongside plain amdgpu.ko... An educated guess on my part, it's probably the thing that's messing up your setup.

File sizes look OK. And yeah, it's /boot/modules/ where you want to look.

If you want to build and deploy the resulting binaries, then start in /usr/ports/graphics/drm-515-kmod/, but don't do any manual copying or renaming - that will mess things up for you.

graphics/gpu-firmware-amd-kmod will get installed as a dependency, I think. If not, go to that dir, as well, and run make && make install...

Check out my thread about sienna_cichlid driver: Thread sienna_cichlid-driver.86670 . It uses the same logic, but pay attention to filenames and look for dimgrey_cavefish on your setup.

tankist02 said:
I think this discussion on Bugzilla might be relevant

Check that link, maybe?

astyle · Feb 22, 2024

tankist02 said:
I cloned the repo https://github.com/wulf7/drm-kmod.git, switched to the branch 515-lts-focal, built from the root and got a bunch of *.ko files:

andrew@obama:drm-kmod$ find . -name \*.ko
./ttm/ttm.ko
./i915/i915kms.ko
./dmabuf/dmabuf.ko
./amd/amdgpu/amdgpu.ko
./radeon/radeonkms.ko
./drm/drm.ko

Do I just copy them over to /boot/modules? What about a bunch of amdgpu_dimgrey_cavefish*.ko files I have in /boot/modules?

Just use official FreeBSD mirror at cgit.freebsd.org... get a fresh ports tarball, put it into /usr/ports, and go from there with simple make config, make && make install... no need to compile stuff on the side in your /home directory, it's a LOT of work to stuff THAT into into the system and getting it to work correctly.

tankist02 · Feb 22, 2024

astyle said:
This part, I'd question the need for it to be in there at all, especially alongside plain amdgpu.ko... An educated guess on my part, it's probably the thing that's messing up your setup.

That was my failed experiment, will delete.

astyle said:
File sizes look OK. And yeah, it's /boot/modules/ where you want to look.

If you want to build and deploy the resulting binaries, then start in /usr/ports/graphics/drm-515-kmod/, but don't do any manual copying or renaming - that will mess things up for you.

Good idea, I'll try to use the normal ports procedures.

astyle said:
graphics/gpu-firmware-amd-kmod will get installed as a dependency, I think. If not, go to that dir, as well, and run make && make install...

Check out my thread about sienna_cichlid driver: Thread sienna_cichlid-driver.8667 . It uses the same logic, but pay attention to filenames and look for dimgrey_cavefish on your setup.

The link doesn't work

astyle said:
Check that link, maybe?

nxjoseph · Feb 22, 2024

tankist02 said:
The link doesn't work

If you did mean the mentioned thread, here it is.
I don't know why your bugzilla link is invisible.

astyle · Feb 22, 2024

tankist02 said:
That was my failed experiment, will delete.

Good idea, I'll try to use the normal ports procedures.

The link doesn't work

Fixed link to my thread...

As for bugzilla link: This is what the URL is: (I used the noparse tags to show it) --> http://look%20normal/?%20I%20think%20this%20discussion%20is%20relevant:

tankist02 · Feb 22, 2024

Update: tried the official port drm-515-kmod and lts-focal branch, in both cases got this error from X11:

Code:

...
[    41.095] (II) LoadModule: "amdgpu"
[    41.095] (WW) Warning, couldn't open module amdgpu
[    41.095] (EE) Failed to load module "amdgpu" (module does not exist, 0)
[    41.095] (EE) No drivers available.
...

astyle · Feb 23, 2024

If it's Xorg complaining, then check /boot/modules/ directory for existence of amdgpu.ko AND related dimgrey_cavefish modules...

After that, what's the output of cat /etc/rc.conf | grep amd ? Mine is kld_list="amdgpu fusefs"

After that, what's the output of kldstat | grep amd?
This is mine (Well, my graphics are Green Sardine):

Code:

$ kldstat | grep amd
 5    1 0xffffffff83400000   413220 amdgpu.ko
11    1 0xffffffff83388000     64d8 amdgpu_green_sardine_sdma_bin.ko
12    1 0xffffffff8338f000    2c2d8 amdgpu_green_sardine_asd_bin.ko
13    1 0xffffffff833bc000    16fd8 amdgpu_green_sardine_pfp_bin.ko
14    1 0xffffffff833d3000    12fd8 amdgpu_green_sardine_me_bin.ko
15    1 0xffffffff833e6000     afd8 amdgpu_green_sardine_ce_bin.ko
16    1 0xffffffff833f1000     bcd0 amdgpu_green_sardine_rlc_bin.ko
17    1 0xffffffff83814000    437e8 amdgpu_green_sardine_mec_bin.ko
18    1 0xffffffff83858000    437e8 amdgpu_green_sardine_mec2_bin.ko
19    1 0xffffffff8389c000    1fb60 amdgpu_green_sardine_dmcub_bin.ko
20    1 0xffffffff838bc000    64298 amdgpu_green_sardine_vcn_bin.ko

If your kldstat output doesn't look like mine, do a kldunload amdgpu.ko, then kldload amdgpu.ko . After that, try startx again.

tankist02 · Feb 23, 2024

astyle said:
If it's Xorg complaining, then check /boot/modules/ directory for existence of amdgpu.ko AND related dimgrey_cavefish modules...

Code:

andrew@obama:~$ ll /boot/modules/amdgpu.ko
-r-xr-xr-x  1 root wheel 8581752 Feb 22 15:42 /boot/modules/amdgpu.ko

andrew@obama:~$ ll /boot/modules/*dimgrey*
-r-xr-xr-x  1 root wheel 275976 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_ce_bin.ko
-r-xr-xr-x  1 root wheel 125496 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_dmcub_bin.ko
-r-xr-xr-x  1 root wheel 276104 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_me_bin.ko
-r-xr-xr-x  1 root wheel 281440 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_mec2_bin.ko
-r-xr-xr-x  1 root wheel 281424 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_mec_bin.ko
-r-xr-xr-x  1 root wheel 276128 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_pfp_bin.ko
-r-xr-xr-x  1 root wheel 149936 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_rlc_bin.ko
-r-xr-xr-x  1 root wheel  46768 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_sdma_bin.ko
-r-xr-xr-x  1 root wheel 257608 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_smc_bin.ko
-r-xr-xr-x  1 root wheel 223120 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_sos_bin.ko
-r-xr-xr-x  1 root wheel 231048 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_ta_bin.ko
-r-xr-xr-x  1 root wheel 592272 Jan 12 17:21 /boot/modules/amdgpu_dimgrey_cavefish_vcn_bin.ko

astyle said:
After that, what's the output of cat /etc/rc.conf | grep amd ? Mine is kld_list="amdgpu fusefs"

Code:

andrew@obama:~$ grep amd /etc/rc.conf
kld_list="amdgpu linux"

astyle said:

After that, what's the output of kldstat | grep amd?
This is mine (Well, my graphics are Green Sardine):

Code:

$ kldstat | grep amd
 5    1 0xffffffff83400000   413220 amdgpu.ko
11    1 0xffffffff83388000     64d8 amdgpu_green_sardine_sdma_bin.ko
12    1 0xffffffff8338f000    2c2d8 amdgpu_green_sardine_asd_bin.ko
13    1 0xffffffff833bc000    16fd8 amdgpu_green_sardine_pfp_bin.ko
14    1 0xffffffff833d3000    12fd8 amdgpu_green_sardine_me_bin.ko
15    1 0xffffffff833e6000     afd8 amdgpu_green_sardine_ce_bin.ko
16    1 0xffffffff833f1000     bcd0 amdgpu_green_sardine_rlc_bin.ko
17    1 0xffffffff83814000    437e8 amdgpu_green_sardine_mec_bin.ko
18    1 0xffffffff83858000    437e8 amdgpu_green_sardine_mec2_bin.ko
19    1 0xffffffff8389c000    1fb60 amdgpu_green_sardine_dmcub_bin.ko
20    1 0xffffffff838bc000    64298 amdgpu_green_sardine_vcn_bin.ko

If your kldstat output doesn't look like mine, do a kldunload amdgpu.ko, then kldload amdgpu.ko . After that, try startx again.

Code:

andrew@obama:~$ kldstat | grep amd
 8    1 0xffffffff83000000   502958 amdgpu.ko
15    1 0xffffffff82ebf000    356d0 amdgpu_dimgrey_cavefish_sos_bin.ko
16    1 0xffffffff82ef5000    375e0 amdgpu_dimgrey_cavefish_ta_bin.ko
17    1 0xffffffff82f2d000    3dd88 amdgpu_dimgrey_cavefish_smc_bin.ko
18    1 0xffffffff82f6b000    1d958 amdgpu_dimgrey_cavefish_dmcub_bin.ko
19    1 0xffffffff82f89000    425e0 amdgpu_dimgrey_cavefish_pfp_bin.ko
20    1 0xffffffff83503000    425e0 amdgpu_dimgrey_cavefish_me_bin.ko
21    1 0xffffffff83546000    42560 amdgpu_dimgrey_cavefish_ce_bin.ko
22    1 0xffffffff82fcc000    238f0 amdgpu_dimgrey_cavefish_rlc_bin.ko
23    1 0xffffffff83589000    43a90 amdgpu_dimgrey_cavefish_mec_bin.ko
24    1 0xffffffff835cd000    43a90 amdgpu_dimgrey_cavefish_mec2_bin.ko
25    1 0xffffffff82ff0000     a5e0 amdgpu_dimgrey_cavefish_sdma_bin.ko
26    1 0xffffffff83611000    8f8d0 amdgpu_dimgrey_cavefish_vcn_bin.ko

Everything looks good, but still does not work.

astyle · Feb 23, 2024

OK, next up is making sure your regular user is in the following groups: wheel, operator, video.

The video group is especially important here.

Group membership is best done at fresh install.

what's the output of groups for you?

tankist02 · Feb 23, 2024

astyle said:
OK, next up is making sure your regular user is in the following groups: wheel, operator, video.

The video group is especially important here.

Group membership is best done at fresh install.

what's the output of groups for you?

Code:

# groups andrew
andrew wheel operator video

astyle · Feb 23, 2024

Dunno what to say at this point... Rebooting your rig might work, but it's a 50-50 proposition. :/

I'm seeing lots of threads on these Forums that complain about freebsd-update(8) breaking something. Sometimes, the process (outlined in the Handbook's ch. 26) was not followed correctly, sometimes packages break...

Re-reading my own thread, there's little nugget/reminder:

Code:

# sysctl hw.syscons.disable=1

That tip really should be in the Handbook at this point, but it's not. And it's difficult to spot even in the wikis...

I frankly recommend setting that tunable in /etc/sysctl.conf or /boot/loader.conf so that it survives reboots.

I checked the wikis mentioned in my thread - the URL is alive, but the contents of the page have been updated (and technical correctness screwed up, too), so small wonder people are getting confused!

tankist02 · Feb 23, 2024

astyle said:
Dunno what to say at this point... Rebooting your rig might work, but it's a 50-50 proposition. :/

I'm seeing lots of threads on these Forums that complain about freebsd-update(8) breaking something. Sometimes, the process (outlined in the Handbook's ch. 26) was not followed correctly, sometimes packages break...

Re-reading my own thread, there's little nugget/reminder:

Code:

# sysctl hw.syscons.disable=1

That tip really should be in the Handbook at this point, but it's not. And it's difficult to spot even in the wikis...

I frankly recommend setting that tunable in /etc/sysctl.conf or /boot/loader.conf so that it survives reboots.

I checked the wikis mentioned in my thread - the URL is alive, but the contents of the page have been updated (and technical correctness screwed up, too), so small wonder people are getting confused!

Thank you for trying to help. Of course I rebooted many times while tinkering with this problem. I think this particular card is not (yet) supported by updated drm-515-kmod. I'll wait for fixes, the developer seems to be active on Bugzilla.

astyle · Feb 23, 2024

tankist02 said:
Thank you for trying to help. Of course I rebooted many times while tinkering with this problem. I think this particular card is not (yet) supported by updated drm-515-kmod. I'll wait for fixes, the developer seems to be active on Bugzilla.

have you tried drm-510-kmod ? That one is known to work, and is still in ports. 515 is for freebsd 14 and later, but it looks like it's got issues...

tankist02 · Feb 24, 2024

astyle said:
have you tried drm-510-kmod ? That one is known to work, and is still in ports. 515 is for freebsd 14 and later, but it looks like it's got issues...

I’m running 14 release