Graphics Pipe, Memory Clock and Shader Clock stuck at 100%

[jstkdng]

The issue is self explanatory. Not running anything that could use the GPU btw. Running under Arch Linux, Ryzen 5 3400G and a ASUS Prime X570-P motherboard.

[clbr]

APUs cannot change the memory clock, but the kernel should have reported you have an APU and so radeontop shouldn't show that field at all. So I believe it's one of two things:

• kernel too early to have full support for raven, to detect it's an apu
• kernel too early to turn the GPU on when it's being queried (see the issue about radeontop triggering a kernel hang for details) What's your kernel ver?

[jstkdng]

I have 5.4.10.arch1.

Jan 11, 2020 1:58:33 PM clbr notifications@github.com:

APUs cannot change the memory clock, but the kernel should have reported you have an APU and so radeontop shouldn't show that field at all. So I believe it's one of two things:

• kernel too early to have full support for raven, to detect it's an apu
• kernel too early to turn the GPU on when it's being queried (see the issue about radeontop triggering a kernel hang for details) What's your kernel ver?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [https://github.com/clbr/radeontop/issues/98?email_source=notifications&email_token=AMNDTKKV5OTSU2HKDFQVNZLQ5IJFRA5CNFSM4KFSL6L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWIW3A#issuecomment-573344620] , or unsubscribe [https://github.com/notifications/unsubscribe-auth/AMNDTKIXERVTQTFBK7EXIZ3Q5IJFRANCNFSM4KFSL6LQ] . [https://github.com/notifications/beacon/AMNDTKKAZKXZONOV5KNHTWTQ5IJFRA5CNFSM4KFSL6L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWIW3A.gif]

[clbr]

Then I don't know.

[jstkdng]

Now I'm using kernel 5.5.875547.2f2d67238034 and the problems sort of fixed itself. Memory clock is still stuck at 100% though. Is there something I could do? like running with gdb or something?

[clbr]

Memory clock is supposed to be 100% since it can't be changed. If you have C experience you could try to track down why the kernel isn't reporting it as an APU.

[jstkdng]

Ok, I think I got it. On amdgpu.c, change:

if (!(ret = retmclk_amdgpu(&out32)))
    getmclk = getmclk_amdgpu;
else    // memory clock reporting not available on APUs
    if (!(gpu.ids_flags & AMDGPU_IDS_FLAGS_FUSION))
        drmError(ret, _("Failed to get memory clock"));

for this

if (gpu.ids_flags & AMDGPU_IDS_FLAGS_FUSION)
    drmError(ret, _("Failed to get memory clock"));
else 
    if (!(ret = getmclk_amdgpu(&out32)))
        getmclk = getmclk_amdgpu;

As it seems getmclk_amdgpu is not failing so gpu.ids_flags & AMDGPU_IDS_FLAGS_FUSION is never touched. Also, gpu.ids_flags & AMDGPU_IDS_FLAGS_FUSION is always returning 1. At least in my platform it is working like that. I have amdgpu ver. 3.36.0 and libdrm 2.4.100. This is how it looks like now: And on the terminal I'm getting this:

$ ./radeontop
Failed to get memory clock: error 0 (Success)
Collecting data, please wait....

[xavier83]

Happening for me too I have an R5 M230 Notebook GPU.

[jens1o]

I have the same, I'm running a PowerColor 8 GB RX 5700 XT

[clbr]

jens1o, your issue is different; it's because radeontop doesn't recognize your device. It's also curious that the version string is entirely missing.

Please try latest git, it may have more pci ids than your current binary.

[jens1o]

Please try latest git, it may have more pci ids than your current binary.

That helped, thanks! :)

[guglovich]

Radeon RX460

[dm17]

Any idea if this is normal for a zen 4 iGPU ("Raphael")? Always idles here as such:

[clbr]

On Thu, 21 Mar 2024 18:45:55 -0700 dm17 @.***> wrote:

Any idea if this is normal for a zen 4 iGPU ("Raphael")?

Assuming the DRM path, everything comes from the kernel and if it's wrong, it's still what the kernel reported. If you're using the mem path, then the block percentages could be wrong as the chip was unknown, but vram/gtt still come directly from the kernel.

[dm17]

On Thu, 21 Mar 2024 18:45:55 -0700 dm17 @.***> wrote: Any idea if this is normal for a zen 4 iGPU ("Raphael")? Assuming the DRM path, everything comes from the kernel and if it's wrong, it's still what the kernel reported. If you're using the mem path, then the block percentages could be wrong as the chip was unknown, but vram/gtt still come directly from the kernel.

Thx. I realized it is yet another AMDGPU but that I need to file. :face_with_spiral_eyes:

I've also given up on radeontop because so many AMD GPUs I've used can't be identified by it - and it takes a long time to start even on the latest hardware. nvtop - on the other hand - starts instantly and identifies everything I have thrown at it. Plus it gives the relevant temperature information.