[Rant]: RX 5700... a frustrating experience
Page: «17/21»
  Go to:
Tuxee Mar 22, 2020
Aaaand it's the BIOS.
Replacing the most recent BIOS files (2020-02-04) with some "different ones", namely the ones I have on my 18.04 setup results in smooth and speedy booting and not a single amdgpu error, frame rates in my ROTR benchmark are ok. Even the lone
amdgpu: [powerplay] failed send message: SetHardMinByFreq (28)  is gone. I suppose I now have to backtrack which firmware version is the one I am now using. (Which reiterates what I tried to express with this whole thread.)
Tuxee Mar 22, 2020
Quoting: tuubi
Quoting: TuxeeWell, it was nice as long as it lasted. Meanwhile kernel 5.3 on my 18.04 has to soldier on.
Just FYI, Ubuntu's mainline 5.5.9 and 5.5.10 are fine for me on Mint 19.3 (based on Ubuntu 18.04).

What BIOS files are you using? Where did you get them from?
tuubi Mar 22, 2020
Quoting: Tuxee
Quoting: tuubi
Quoting: TuxeeWell, it was nice as long as it lasted. Meanwhile kernel 5.3 on my 18.04 has to soldier on.
Just FYI, Ubuntu's mainline 5.5.9 and 5.5.10 are fine for me on Mint 19.3 (based on Ubuntu 18.04).

What BIOS files are you using? Where did you get them from?
Just whatever is included in the latest linux-firmware package from bionic. The firmware is likely to be far from the latest and greatest, but I don't care as long as everything works as intended. In fact, according to the package changelog the navi10 firmware hasn't been updated since it was initially included in linux-firmware 1.173.12.

You could try bisecting the problematic version of the file from the git repo if you want to report your problem. I'd be interested in the result as well.
Tuxee Mar 22, 2020
Turns out I also have the "original" Navi10 firmware, which according to the changelog (http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-firmware/linux-firmware_1.173.16/changelog) ended up in the repository on Nov 5th. I have an extra navi10_ta.bin not present in the package and looking at the timestamp it was copied there "from elsewhere" (and can mostly likely be removed).

When consulting http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-firmware/linux-firmware_1.187/changelog
the Jan 28th update (1.185) was still "ok" with the single powerplay error message).
Tuxee Mar 25, 2020
I was overly optimistic. With the same setup (mainline kernel 5.5.11, Mesa 20.0 and the swapped BIOS back from November) it occasionally results in

[    9.413173] amdgpu: [powerplay] failed send message: PowerDownVcn (44)  param: 0x00000000 response 0xffffffc2
[    9.413212] [drm:amdgpu_dpm_enable_uvd [amdgpu]] *ERROR* [SW SMU]: dpm enable uvd failed, state = false, ret = -62. 
[    9.428781] igb 0000:06:00.0 enp6s0: igb: enp6s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[    9.536467] IPv6: ADDRCONF(NETDEV_CHANGE): enp6s0: link becomes ready
[    9.570628] FS-Cache: Loaded
[    9.585778] FS-Cache: Netfs 'nfs' registered for caching
[    9.678575] NFS: Registering the id_resolver key type
[    9.678581] Key type id_resolver registered
[    9.678581] Key type id_legacy registered
[   11.932040] snd_hda_intel 0000:0c:00.1: refused to change power state from D3hot to D0
[   12.036515] snd_hda_intel 0000:0c:00.1: CORB reset timeout#2, CORBRP = 65535
[   12.324229] snd_hda_codec_hdmi hdaudioC0D0: Unable to sync register 0x2f0d00. -5
[   13.082113] Bluetooth: RFCOMM TTY layer initialized
[   13.082121] Bluetooth: RFCOMM socket layer initialized
[   13.082124] Bluetooth: RFCOMM ver 1.11
[   14.295243] amdgpu: [powerplay] failed send message: GetMaxDpmFreq (31)  param: 0x00000000 response 0xffffffc2
[   16.773964] amdgpu: [powerplay] failed send message: GetMaxDpmFreq (31)  param: 0x00000000 response 0xffffffc2
[   19.250067] amdgpu: [powerplay] failed send message: GetMaxDpmFreq (31)  param: 0x00020000 response 0xffffffc2
[   21.728324] amdgpu: [powerplay] failed send message: GetMaxDpmFreq (31)  param: 0x00020000 response 0xffffffc2
[   24.152429] amdgpu: [powerplay] failed send message: GetMaxDpmFreq (31)  param: 0x00000000 response 0xffffffc2
[   26.518834] amdgpu: [powerplay] failed send message: GetMaxDpmFreq (31)  param: 0x00000000 response 0xffffffc2
[   28.998958] amdgpu: [powerplay] failed send message: GetMaxDpmFreq (31)  param: 0x00020000 response 0xffffffc2
[   31.479071] amdgpu: [powerplay] failed send message: GetMaxDpmFreq (31)  param: 0x00020000 response 0xffffffc2
[   33.877170] amdgpu: [powerplay] failed send message: NumOfDisplays (64)  param: 0x00000002 response 0xffffffc2
[   36.245438] amdgpu: [powerplay] failed send message: NumOfDisplays (64)  param: 0x00000002 response 0xffffffc2
[   38.732072] amdgpu: [powerplay] failed send message: NumOfDisplays (64)  param: 0x00000002 response 0xffffffc2
[   41.210837] amdgpu: [powerplay] failed send message: NumOfDisplays (64)  param: 0x00000002 response 0xffffffc2
[   43.426821] amdgpu: [powerplay] failed send message: NumOfDisplays (64)  param: 0x00000002 response 0xffffffc2
[   45.641051] amdgpu: [powerplay] failed send message: NumOfDisplays (64)  param: 0x00000002 response 0xffffffc2
[   47.855394] amdgpu: [powerplay] failed send message: SetMinDeepSleepDcefclk (34)  param: 0x00000010 response 0xffffffc2
[   50.069673] amdgpu: [powerplay] failed send message: SetMinDeepSleepDcefclk (34)  param: 0x00000010 response 0xffffffc2
[   50.069675] amdgpu: [powerplay] SMU11 attempt to set divider for DCEFCLK Failed!


As said, it does this only "every now and then" which makes it pretty much impossible to track down the culprit.
sub Mar 26, 2020
Do you have a spare old HDD?

Any chance of just giving Arch a try?
I had zero (apparent) issues so far.
And I didn't manually build the driver stack
and fiddling with the BIOSes. :D
Just the plain experience.

Reading through this thread it gives the experience
that AMD still struggles with Navi.
But from my POV that's absolutely not the case.
Neither on Linux nor on Windows.

Really, don't know what's wrong with your setup. XD

Sorry.
tuubi Mar 26, 2020
Quoting: subDo you have a spare old HDD?

Any chance of just giving Arch a try?
I had zero (apparent) issues so far.
And I didn't manually build the driver stack
and fiddling with the BIOSes. :D
Just the plain experience.

Reading through this thread it gives the experience
that AMD still struggles with Navi.
But from my POV that's absolutely not the case.
Neither on Linux nor on Windows.

Really, don't know what's wrong with your setup. XD

Sorry.
Yeah, my experience has been pretty much perfect on Mint since I bought my 5700 XT late last year. With Kisak's PPA for latest stable Mesa. And latest mainline Linux kernel from Ubuntu, but the default 5.3 kernel seems just as stable. Firmware is whatever comes with the system, haven't touched that at all.

So the only thing I apparently had to do on this distro is add a single PPA, and that takes less than a minute. Although I added it before I upgraded the GPU, so no idea if I'd have problems without it.

Switching distros might help some of the people with issues, but it might also be time and effort wasted.
dvd Mar 26, 2020
Quoting: TuxeeAaaand it's the BIOS.
Replacing the most recent BIOS files (2020-02-04) with some "different ones", namely the ones I have on my 18.04 setup results in smooth and speedy booting and not a single amdgpu error, frame rates in my ROTR benchmark are ok. Even the lone
amdgpu: [powerplay] failed send message: SetHardMinByFreq (28)  is gone. I suppose I now have to backtrack which firmware version is the one I am now using. (Which reiterates what I tried to express with this whole thread.)

What kind of motherboard are you using?
Tuxee Mar 28, 2020
Quoting: subDo you have a spare old HDD?
I even have a spare NVMe SSD in an USB3 case :-)

Quoting: subAny chance of just giving Arch a try?
I had zero (apparent) issues so far.
And I didn't manually build the driver stack
and fiddling with the BIOSes. :D
Just the plain experience.

Reading through this thread it gives the experience
that AMD still struggles with Navi.
But from my POV that's absolutely not the case.
Neither on Linux nor on Windows.

As stated already: My 5.3 kernel with Mesa 20.0 works pretty much flawless, too. It just took its fair time getting there and I didn't expect any regressions. The last couple of 20.04 boots (kernel 5.5, Mesa 20.0, BIOS back from November) went smooth again...

So Arch might be fine for some time. Or for several boots.

Quoting: subReally, don't know what's wrong with your setup. XD

Sorry.

Neither do I. But reading through the various bug reports I might not be the only one.

Edit: How many displays do you use? Seems as if some issues stem from multi-monitor setups.

Last edited by Tuxee on 28 March 2020 at 1:16 pm UTC
Tuxee Mar 28, 2020
Quoting: dvdWhat kind of motherboard are you using?

ASRock X570M Pro4.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.