Radeon 6800 XT: 100% GPU core usage & 74 Watts when idle

[piorunz]

Hello,

I am using Bullseye 11 with Radeon 6800 XT and noticed higher
temperature and noise comparing to Windows, so I investigated this and
found the fault. GPU core works at 100% usage at all times, even at idle.

$ cat /sys/class/drm/card0/device/gpu_busy_percent
99

$ sensors
(...)
amdgpu-pci-0900
Adapter: PCI adapter
vddgfx: 1.14 V
fan1: 1098 RPM (min = 0 RPM, max = 3000 RPM)
edge: +51.0°C (crit = +100.0°C, hyst = -273.1°C)
(emerg = +105.0°C)
junction: +55.0°C (crit = +110.0°C, hyst = -273.1°C)
(emerg = +115.0°C)
mem: +56.0°C (crit = +100.0°C, hyst = -273.1°C)
(emerg = +105.0°C)
power1: 74.00 W (cap = 272.00 W)

gpu-mon (from rickslab-gpu-utils)
┌─────────────┬────────────────────┐
│Card # │card0 │
├─────────────┼────────────────────┤
│Model │ Navi 21 RX │
│GPU Load % │99 │
│Mem Load % │0 │
│VRAM Usage % │4.839 │
│GTT Usage % │0.802 │
│Power (W) │75.0 │
│Power Cap (W)│272.0 │
│Energy (kWh) │0.0 │
│T (C) │53.0 │
│VddGFX (mV) │1143 │
│Fan Spd (%) │0 │
│Sclk (MHz) │2470 │
│Sclk Pstate │1 │
│Mclk (MHz) │1000 │
│Mclk Pstate │3 │
│Perf Mode │0-BOOTUP_DEFAULT │
└─────────────┴────────────────────┘


This is my hardware:
$ inxi -G
Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX
6800/6800 XT / 6900 XT] driver: amdgpu v: kernel
Display: x11 server: X.Org 1.20.11 driver: loaded:
amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution:
1: 1920x1200~60Hz 2: 3840x2160~60Hz
OpenGL: renderer: AMD SIENNA_CICHLID (DRM 3.40.0
5.10.0-8-amd64 LLVM 11.0.1) v: 4.6 Mesa 20.3.5

All packages are default from Bullseye (apart from rickslab-gpu-utils
package which I installed to debug this issue), fresh install from the
scratch a week ago, all graphics and games works perfectly. It's just
that 100% GPU usage when idle. 74 Watts used when idle! I did further
testing and found out this:

Windows 10
one monitor: 9-11 W, GPU clock 0-10 MHz, Memory Clock 40-100 MHz
two monitors: 34 W, GPU clock 0-10 MHz, Memory Clock 2000 MHz

Debian 11
one monitor: 74 W, GPU clock 2475 MHz, Memory Clock 2000 MHz
two monitors: 74 W, GPU clock 2475 MHz, Memory Clock 2000 MHz

Debian results are very bad! On Windows 10, high memory clock with two
monitors it's a known issue, but on Debian also 100% GPU usage and
2.5GHz GPU core clock is a big problem.

Any tips appreciated.

--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[The Wanderer]

On 2021-07-23 at 16:44, piorunz wrote:

> Hello,
>
> I am using Bullseye 11 with Radeon 6800 XT and noticed higher
> temperature and noise comparing to Windows, so I investigated this and
> found the fault. GPU core works at 100% usage at all times, even at idle.
>
> $ cat /sys/class/drm/card0/device/gpu_busy_percent
> 99

That's interesting. I get the same output from that command (with a 5600
XT), but I'm not noticing any meaningful noise that seems to be coming
from the card.

> $ sensors
> (...)
> amdgpu-pci-0900
> Adapter: PCI adapter
> vddgfx: 1.14 V
> fan1: 1098 RPM (min = 0 RPM, max = 3000 RPM)
> edge: +51.0°C (crit = +100.0°C, hyst = -273.1°C)
> (emerg = +105.0°C)
> junction: +55.0°C (crit = +110.0°C, hyst = -273.1°C)
> (emerg = +115.0°C)
> mem: +56.0°C (crit = +100.0°C, hyst = -273.1°C)
> (emerg = +105.0°C)
> power1: 74.00 W (cap = 272.00 W)

I get 1478 RPM, and temperature readings of 66, 72, 78, plus a power
reading of 94 W. Those do sound higher than reasonable, but I'm
disinclined to trust the RPM value at least, since that'd be nearly 25
revolutions per second and I'm nearly positive that'd be a lot more
audible than what I'm hearing. And of course if that reading isn't
accurate, there's less reason to trust the others.

> gpu-mon (from rickslab-gpu-utils)

Where does that come from? It's not in current Debian stable or testing.

> This is my hardware:
> $ inxi -G
> Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX
> 6800/6800 XT / 6900 XT] driver: amdgpu v: kernel
> Display: x11 server: X.Org 1.20.11 driver: loaded:
> amdgpu,ati unloaded: fbdev,modesetting,radeon,vesa resolution:
> 1: 1920x1200~60Hz 2: 3840x2160~60Hz
> OpenGL: renderer: AMD SIENNA_CICHLID (DRM 3.40.0
> 5.10.0-8-amd64 LLVM 11.0.1) v: 4.6 Mesa 20.3.5

I get:

Graphics:
Device-1: AMD Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT]
driver: amdgpu v: kernel
Display: server: X.Org 1.20.11 driver: loaded: amdgpu,ati
unloaded: fbdev,modesetting,radeon,vesa resolution: 2560x1600~60Hz
OpenGL: renderer: AMD Radeon RX 5700 XT (NAVI10 DRM 3.40.0 5.10.0-8-amd64
LLVM 12.0.1)
v: 4.6 Mesa 21.1.4

Mesa and a couple of other things are from sid, courtesy of an
experiment I did on the wrong path to getting Vulkan working, but
otherwise this looks substantially similar.

> All packages are default from Bullseye (apart from rickslab-gpu-utils
> package which I installed to debug this issue), fresh install from the
> scratch a week ago, all graphics and games works perfectly. It's just
> that 100% GPU usage when idle. 74 Watts used when idle! I did further
> testing and found out this:
>
> Windows 10
> one monitor: 9-11 W, GPU clock 0-10 MHz, Memory Clock 40-100 MHz
> two monitors: 34 W, GPU clock 0-10 MHz, Memory Clock 2000 MHz
>
> Debian 11
> one monitor: 74 W, GPU clock 2475 MHz, Memory Clock 2000 MHz
> two monitors: 74 W, GPU clock 2475 MHz, Memory Clock 2000 MHz

Where are the Debian-side results from?

> Debian results are very bad! On Windows 10, high memory clock with two
> monitors it's a known issue, but on Debian also 100% GPU usage and
> 2.5GHz GPU core clock is a big problem.
>
> Any tips appreciated.

My initial guess is that this is either A: bad data / false positive
(i.e., it's not really that bad under the hood), or B: a limitation of
the Linux-side drivers.

If you're willing to try out the official direct-from-AMD drivers (which
may or may not include an associated stack, I'm not sure), and they give
different results, that could be informative. I'm not willing to try
those out under present circumstances, so I can't directly contribute
information there.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Dan Ritter]

The Wanderer wrote:
> On 2021-07-23 at 16:44, piorunz wrote:
>
> > Hello,
> >
> > I am using Bullseye 11 with Radeon 6800 XT and noticed higher
> > temperature and noise comparing to Windows, so I investigated this and
> > found the fault. GPU core works at 100% usage at all times, even at idle.
> >
> > $ cat /sys/class/drm/card0/device/gpu_busy_percent
> > 99
>
> That's interesting. I get the same output from that command (with a 5600
> XT), but I'm not noticing any meaningful noise that seems to be coming
> from the card.

RX560: 0

> > $ sensors

> > amdgpu-pci-0900
> > Adapter: PCI adapter
> > vddgfx: 1.14 V
> > fan1: 1098 RPM (min = 0 RPM, max = 3000 RPM)
> > edge: +51.0°C (crit = +100.0°C, hyst = -273.1°C)
> > (emerg = +105.0°C)
> > junction: +55.0°C (crit = +110.0°C, hyst = -273.1°C)
> > (emerg = +115.0°C)
> > mem: +56.0°C (crit = +100.0°C, hyst = -273.1°C)
> > (emerg = +105.0°C)
> > power1: 74.00 W (cap = 272.00 W)
>
> I get 1478 RPM, and temperature readings of 66, 72, 78, plus a power
> reading of 94 W. Those do sound higher than reasonable, but I'm
> disinclined to trust the RPM value at least, since that'd be nearly 25
> revolutions per second and I'm nearly positive that'd be a lot more
> audible than what I'm hearing. And of course if that reading isn't
> accurate, there's less reason to trust the others.

Still an RX560:

amdgpu-pci-2b00
Adapter: PCI adapter
vddgfx: 887.00 mV
fan1: 1610 RPM (min = 0 RPM, max = 3600 RPM)
edge: +42.0°C (crit = +94.0°C, hyst = -273.1°C)
power1: 22.09 W (cap = 48.00 W)

> My initial guess is that this is either A: bad data / false positive
> (i.e., it's not really that bad under the hood), or B: a limitation of
> the Linux-side drivers.

It's plausible that there's something in power management that
can and should be turned on, and isn't.

-dsr-

[The Wanderer]

On 2021-07-23 at 18:33, Dan Ritter wrote:

> The Wanderer wrote:
>
>> On 2021-07-23 at 16:44, piorunz wrote:
>>
>> > Hello,
>> >
>> > I am using Bullseye 11 with Radeon 6800 XT and noticed higher
>> > temperature and noise comparing to Windows, so I investigated this and
>> > found the fault. GPU core works at 100% usage at all times, even at idle.
>> >
>> > $ cat /sys/class/drm/card0/device/gpu_busy_percent
>> > 99
>>
>> That's interesting. I get the same output from that command (with a 5600
>> XT), but I'm not noticing any meaningful noise that seems to be coming
>> from the card.
>
> RX560: 0

Permit me to correct myself: I have a 5700 XT, not a 5600 XT. (I always
get that mixed up, because I have a Ryzen 5600 CPU.)

Given the below, it'd be interesting to know what kernel that's with.

>> My initial guess is that this is either A: bad data / false positive
>> (i.e., it's not really that bad under the hood), or B: a limitation of
>> the Linux-side drivers.
>
> It's plausible that there's something in power management that
> can and should be turned on, and isn't.

https://bbs.archlinux.org/viewtopic.php?id=267503 (from just a few weeks
ago) reports that this is fixed in kernel 5.12.14.

Debian testing, being frozen, is still on 5.10.x:

$ uname -r
5.10.0-8-amd64

The release is AFAIK less than two weeks away (barring delays), and
after that it's likely that a newer version will pass into testing. Once
a newer-enough version is available, it should resolve this.


For additional reference,
https://forums.lenovo.com/topic/view/27/5085655 has another report of
the issue, and links to
https://gitlab.freedesktop.org/drm/amd/-/issues/1632 as being an
upstream(?) bug report which covers it. Not sure how directly applicable
those are, but just in case...

[piorunz]

On 23/07/2021 23:44, The Wanderer wrote:

> https://bbs.archlinux.org/viewtopic.php?id=267503 (from just a few weeks
> ago) reports that this is fixed in kernel 5.12.14.
>
> Debian testing, being frozen, is still on 5.10.x:
>
> $ uname -r
> 5.10.0-8-amd64

Yes, that's what I use.

> The release is AFAIK less than two weeks away (barring delays), and
> after that it's likely that a newer version will pass into testing. Once
> a newer-enough version is available, it should resolve this.
>
>
> For additional reference,
> https://forums.lenovo.com/topic/view/27/5085655 has another report of
> the issue, and links to
> https://gitlab.freedesktop.org/drm/amd/-/issues/1632 as being an
> upstream(?) bug report which covers it. Not sure how directly applicable
> those are, but just in case...
>

Thanks! Looks like someone found one particular commit which causes
this. They say, that fixed commit will be in kernel 5.13. I hope this
will be imported to Debian's 5.10 LTS as well, so I can continue to use
5.10?
Should I report it somewhere as Debian bug, to make sure its being
backported?

[piorunz]

On 23/07/2021 22:46, The Wanderer wrote:

>> gpu-mon (from rickslab-gpu-utils)
>
> Where does that come from? It's not in current Debian stable or testing.

In Debian, there is old ricks-amdgpu-utils, which doesn't work. New
package has been renamed upstream to rickslab-gpu-utils and most likely
will be available in Debian 12. Today you can install that from apt
repository they maintain.

>> Windows 10
>> one monitor: 9-11 W, GPU clock 0-10 MHz, Memory Clock 40-100 MHz
>> two monitors: 34 W, GPU clock 0-10 MHz, Memory Clock 2000 MHz
>>
>> Debian 11
>> one monitor: 74 W, GPU clock 2475 MHz, Memory Clock 2000 MHz
>> two monitors: 74 W, GPU clock 2475 MHz, Memory Clock 2000 MHz
>
> Where are the Debian-side results from?

From rickslab-gpu-utils. radeontop shows the same:
1.00G / 1.00G Memory Clock 100.00%
2.47G / 2.58G Shader Clock 95.92%
Graphics pipe 100.00%

Regarding memory clock: I don't even know real MHz frequency of the
chip, some tools in Windows/Linux show 1000 or 2000 MHz, but that's
irrelevant; Cold, idle card should be at 100 Mhz tops on memory and 10
Mhz on GPU core.

> My initial guess is that this is either A: bad data / false positive
> (i.e., it's not really that bad under the hood), or B: a limitation of
> the Linux-side drivers.

Yes that must be Linux driver problem. Results are accurate I believe,
under Windows GPU fan will never spin unless gaming, because it's using
10W (one monitor) or 34W (two monitors). In Debian it's 74W minimum.

> If you're willing to try out the official direct-from-AMD drivers (which
> may or may not include an associated stack, I'm not sure), and they give
> different results, that could be informative. I'm not willing to try
> those out under present circumstances, so I can't directly contribute
> information there.

Unfortunately, I don't know how to install official AMD drivers on
Debian correctly. I've tried, but there was no Xorg, it failed to start,
I had to uninstall and revert. They publish Ubuntu version only and it's
not compatible with Debian 11, unless I don't know some tricks.

Also I've tried Mesa from experimental (via apt pinning and manual
install), Mesa 21.1.4-1 is there, but that didn't changed anything. I
reverted back to default, Bullseye repo got Mesa 20.3.5-1.

[piorunz]

On 23/07/2021 23:44, The Wanderer wrote:

> https://gitlab.freedesktop.org/drm/amd/-/issues/1632 as being an
> upstream(?) bug report which covers it. Not sure how directly applicable
> those are, but just in case...

That escalated very quickly :D This bug is responsible for this. And
patch works.

I compiled my own 5.10 kernel using Debian source, and I patched that
one line in drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c file. Now I rebooted
to my custom 5.10 kernel and it works :)

Let's see - before:

$ sensors
(...)
amdgpu-pci-0900
(...)

power1: 74.00 W (cap = 272.00 W)

gpu-mon (from rickslab-gpu-utils)
┌─────────────┬────────────────────┐
│Card # │card0 │
├─────────────┼────────────────────┤
│Model │ Navi 21 RX │
│GPU Load % │99 │
│Mem Load % │0 │
│VRAM Usage % │4.839 │
│GTT Usage % │0.802 │
│Power (W) │75.0 │
│Power Cap (W)│272.0 │
│Energy (kWh) │0.0 │
│T (C) │53.0 │
│VddGFX (mV) │1143 │
│Fan Spd (%) │0 │
│Sclk (MHz) │2470 │
│Sclk Pstate │1 │
│Mclk (MHz) │1000 │
│Mclk Pstate │3 │
│Perf Mode │0-BOOTUP_DEFAULT │
└─────────────┴────────────────────┘

And after:

$ sensors
(...)
amdgpu-pci-0900
(...)
power1: 34.00 W (cap = 272.00 W)

┌─────────────┬────────────────────┐
│Card # │card0 │
├─────────────┼────────────────────┤
│Model │ Navi 21 RX │

│GPU Load % │0 │
│Mem Load % │0 │
│VRAM Usage % │6.109 │
│GTT Usage % │1.147 │
│Power (W) │35.0 │
│Power Cap (W)│272.0 │
│Energy (kWh) │0.004 │
│T (C) │54.0 │
│VddGFX (mV) │856 │
│Fan Spd (%) │0 │
│Sclk (MHz) │500 │
│Sclk Pstate │0 │

│Mclk (MHz) │1000 │
│Mclk Pstate │3 │
│Perf Mode │0-BOOTUP_DEFAULT │
└─────────────┴────────────────────┘

0% GPU core use, 0% memory use, core clock is 500 MHz instead of maxed
out at 2470 Mhz. Success!
Power usage is on par with Windows.
However, I still have 34W even if I disconnect second monitor. On
Windows, with one monitor only power goes down to 10W and core is 10
MHz. But my default setup it 2 monitors so I don't worry too much anyway :)

[tv.d...@googlemail.com]

Hello,

Le 24/07/2021 à 01:07, piorunz a écrit :
> On 23/07/2021 23:44, The Wanderer wrote:
>
>> https://bbs.archlinux.org/viewtopic.php?id=267503 (from just a few weeks
>> ago) reports that this is fixed in kernel 5.12.14.
>>
>> Debian testing, being frozen, is still on 5.10.x:
>>
>> $ uname -r
>> 5.10.0-8-amd64
>

5.10.0-7 didn't exhibit this behavior, but anything newer is on a Radeon
Vega 56. Self compiled kernel with Debian kernel config doesn't have
this bug either. Many commits touch AMD "powerplay" features in 5.10.0-8.

> Yes, that's what I use.
>
>> The release is AFAIK less than two weeks away (barring delays), and
>> after that it's likely that a newer version will pass into testing. Once
>> a newer-enough version is available, it should resolve this.
>>
>>
>> For additional reference,
>> https://forums.lenovo.com/topic/view/27/5085655 has another report of
>> the issue, and links to
>> https://gitlab.freedesktop.org/drm/amd/-/issues/1632 as being an
>> upstream(?) bug report which covers it. Not sure how directly applicable
>> those are, but just in case...
>>
>
> Thanks! Looks like someone found one particular commit which causes
> this. They say, that fixed commit will be in kernel 5.13. I hope this
> will be imported to Debian's 5.10 LTS as well, so I can continue to use
> 5.10?
> Should I report it somewhere as Debian bug, to make sure its being
> backported?
>

Pinning 5.10.0-7 resolves the issue for me, as is compiling a newer
upstream kernel (5.13.4 currently).

[piorunz]

On 24/07/2021 09:11, tv.d...@googlemail.com wrote:

> 5.10.0-7 didn't exhibit this behavior, but anything newer is on a Radeon
> Vega 56. Self compiled kernel with Debian kernel config doesn't have
> this bug either. Many commits touch AMD "powerplay" features in 5.10.0-8.

> Pinning 5.10.0-7 resolves the issue for me, as is compiling a newer
> upstream kernel (5.13.4 currently).

Great. I reported this to Debian BTS.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991453
All fixed, for me as well because I recompiled kernel, and soon for
everyone else once another iteration of 5.10 lands in repos.

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-07-23 7:07 p.m., piorunz wrote:
> On 23/07/2021 23:44, The Wanderer wrote:
>
>> https://bbs.archlinux.org/viewtopic.php?id=267503 (from just a few weeks
>> ago) reports that this is fixed in kernel 5.12.14.
>>
>> Debian testing, being frozen, is still on 5.10.x:
>>
>> $ uname -r
>> 5.10.0-8-amd64
>
> Yes, that's what I use.
>
>> The release is AFAIK less than two weeks away (barring delays), and
>> after that it's likely that a newer version will pass into testing. Once
>> a newer-enough version is available, it should resolve this.
>>
>>
>> For additional reference,
>> https://forums.lenovo.com/topic/view/27/5085655 has another report of
>> the issue, and links to
>> https://gitlab.freedesktop.org/drm/amd/-/issues/1632 as being an
>> upstream(?) bug report which covers it. Not sure how directly applicable
>> those are, but just in case...
>>

Why don't you custom compile a Kernel using as base for .config the file
from Debian ?

> With kindest regards, piorunz.
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄⠀⠀⠀⠀
>

--
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development

[tv.d...@googlemail.com]

It was tested, you can follow the bug there:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991453

[piorunz]

On 24/07/2021 20:20, Polyna-Maude Racicot-Summerside wrote:
> Why don't you custom compile a Kernel using as base for .config the file
> from Debian ?

That's what I did, please see my other post. I downloaded source
package, copied config, changed one line of code and recompiled Debian
kernel. It works fine now. It was my first kernel compilation and I
succeeded, yay :)

--

[piorunz]

Debian 11 patched kernel is out!
That will fix everyone who have been affected and they didn't switched
to older kernel or compiled their own.


linux-signed-amd64 (5.10.46+3) unstable; urgency=medium

* Sign kernel from linux 5.10.46-3

* [armhf] Add mdio-aspeed to nic-modules.
Thanks to Joel Stanley <jo...@jms.id.au> (Closes: #991262)
* Revert "drm/amdgpu/gfx9: fix the doorbell missing when in CGPG issue."
(Closes: #990312)
* Revert "drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to
cover full
doorbell." (Closes: #990312)
* Input: joydev - prevent use of not validated data in JSIOCSBTNMAP ioctl
(CVE-2021-3612)
* sctp: validate from_addr_param return (CVE-2021-3655)
* sctp: add size validation when walking chunks (CVE-2021-3655)
* [s390x] sclp_vt220: fix console name to match device (Closes: #961056)
* block: return the correct bvec when checking for gaps
* sctp: fix return value check in __sctp_rcv_asconf_lookup

-- Salvatore Bonaccorso <car...@debian.org> Wed, 28 Jul 2021 07:55:40
+0200

[The Wanderer]

On 2021-07-31 at 17:20, piorunz wrote:

> Debian 11 patched kernel is out!
> That will fix everyone who have been affected and they didn't switched
> to older kernel or compiled their own.
>
>
> linux-signed-amd64 (5.10.46+3) unstable; urgency=medium

> * Revert "drm/amdgpu/gfx9: fix the doorbell missing when in CGPG issue."
> (Closes: #990312)
> * Revert "drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to
> cover full
> doorbell." (Closes: #990312)

I was actually watching the unblock-request bug for that, but apparently
it doesn't get updated when the package migrates.

I'm in the updated kernel now, and I confirm the fix. gpu_busy_percent
is now 0 rather than 99, and the output of 'sensors' for amdgpu-pci-0d00
now reports a fan speed of 815 RPM (down from 1478), temperature
readings of 55, 56, and 68 degrees Celsius (down from 66, 72, and 78),
and a power reading of 40 W (down from 94).

I wasn't hearing/noticing meaningful levels of noise from the fan(s)
before, but it does sound just a bit quieter now - and of course less
power draw, less heat generation, and less energy consumption are all
good things.