Nasty amdgpu powerplay regression Navi14/Linux 5.10

Brief summary of the problem:

Idle power draw goes from 5w -> 15w when upgrading from kernel 5.19 to kernel 5.10 resulting in increased gpu temp at idle.

Hardware description:

• CPU: FX 8300
• GPU: RX 5500 XT
• System Memory: 16gb ddr3
• Display: 1080p
• Type of Diplay Connection: HDMI

System infomration:

• Distro name and Version: Manjaro
• Kernel version: 5.10
• AMD package version: No package

How to reproduce the issue:

Watch gpu idle powerdraw&temp with kernel 5.19 and lm_sensors, upgrade to kernel 5.10 and repeat the process.

Attached files:

• Dmesg logdmesg5.9

changed the description

changed the description

I also found out that at idle:

kernel 5.9:

cat /sys/class/drm/card0/device/pp_dpm_mclk                                                                                                                         

0: 100Mhz *
1: 500Mhz
2: 625Mhz
3: 875Mhz

kernel 5.10:

cat /sys/class/drm/card0/device/pp_dpm_mclk                                                                                                                         

0: 100Mhz 
1: 500Mhz
2: 625Mhz
3: 875Mhz *

I booted kernel 5.19 and forced pp_dpm_mclk to 875mhz* and i get the same faulty power draw as kernel 5.10 out of the box, so the bug is that kernel 5.10 forces the highest clock on gpu memory at idle. Can this be fixed in kernel 5.10?

Can you bisect?

Well not really unless someone could guide me through the process

It's a pretty easy process, you split the commits range in half, build and test the middle, if it works you forgo before, if not you forgo after, then you split that in half again, build, test etc. until you find the offending commit.

git offers the git bisect tool to help with getting the commit to test, cf: https://git-scm.com/docs/git-bisect

The process can be time consuming so you may want to use ccache for it.

Getting same behavior with RX 5700XT, memory clock at idle stays at max clock.

0: 100Mhz

1: 500Mhz

2: 625Mhz

3: 875Mhz *

Idle power is now at ~30W instead of the usual 10W

Present at 5.10-rc1

@siyia , if you are able to build, compile, and boot a kernel, you can perform a bisect as well. Just search Google git bisect.

If you want this to be fixed faster, providing the offending patch (hoping it is just one), will speed it up.

Well sorry i am not that familiar with git, i cannot even clone the 5.10 and 5.9 git repos tostart bisecting

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

That would clone it, but you'd probably want to keep the config you already use.

This may help: https://kernelnewbies.org/KernelBuild

ok i believe i am bisecting the first out of 13 maximum required bisects, this is going to take forever on my cpu

To soften the pain a bit, each next compile run should go faster, since the number of commits (changes) is about half of the previous run. So there is less work to do for the compiler.

The compilation process might be also beneficial, depending where you are geolocated (winter/summer), since the CPU partially replaces the heating system of the room. ;-)

if first bisect wont solve the problem, i just do:

git bisect bad
make clean
make -j8

all over again?

IMO, skip the make clean.

If not, everything will be recompiled. Without it, only the changes (and related) will be recompiled, thus reducing compile time.

Not if one is using ccache as suggested before. I'm afraid though that this is spamming the devs with non-essential stuff and maybe it should be better taken to phoronix/reddit/irc etc.

https://bugzilla.kernel.org/show_bug.cgi?id=210683

I get the same blank screen when trying to boot the bisected kernel

I'll make a very wild guess and I hope I'm wrong and it can be fixed. I stumbled upon this issue by accident (your post in phoronix) but I was expecting this to appear. This also started happening about a month ago for the AMD drivers for Windows, after adding support for the 6800xt GPUs, and the AMD developers on reddit stated that there is no intention to fix this, because it's considered normal behaviour. The workaround for Windows is to increase the resolution vertical blanking for the monitor (using an utility called CRU) - but I'm not sure if it's possible to do this for Linux. Do you have a 75hz / 144hz / 60hz BenQ monitor by any chance? I think it's more common for 75hz monitors.

I haven't used any 5.10.* kernel so I can't confirm if this is happening for my system (5700xt) yet. I also hope this is useful information and I'm not creating noise.