[REGRESSION] amdgpu: Raven/Picasso MCLK stays at 1200 MHz after Chromium exits

[REGRESSION] amdgpu: Raven/Picasso MCLK stays at 1200 MHz after Chromium exits

[Ata İlhan Köktürk]

Hi,

On a Picasso/Raven2 laptop, MCLK stays pinned at its highest level
(1200 MHz) after a Chromium-based browser (Brave) has used the GPU and
been closed. I could not find where the state is set or released from
the driver side, so I am asking whether this is known and what else I
should collect. I have the kernel tree and can test patches.

== System ==

Laptop:  Huawei MateBook D14 (NBLK-WAX9X), Ryzen 5 3500U,
          Picasso/Raven2 1002:15d8 rev c2
Distro:  Fedora 44, Sway 1.11 on Wayland
Kernel:  7.2.13-200.fc44.x86_64 (Fedora kernel, not tested on drm-next)
amdgpu 3.64.0, DCN 1.0, SMU10, VCN 1.0 (ENC 1.15 DEC 3 VEP 0 Rev 9)
Mesa 26.2.5, libva 2.23.0
Boot:    amdgpu.noretry=0 amdgpu.ppfeaturemask=0xffffffff
	 amdgpu.gpu_recovery=1 amdgpu.vcnfw_log=1
	 amdgpu.dcdebugmask=0x10
Userspace: no daemon or tool writes to amdgpu sysfs.

== Symptom ==

Idle: pp_dpm_mclk shows "0: 667Mhz *".

After WebGL (WebGL Aquarium, sometimes this doesn't trigger?) or
VA-API video (YouTube, VP9 1080p) in Brave, and closing the tab
or the whole browser, pp_dpm_mclk shows "3: 1200Mhz *" indefinitely,
with GPU load 0% and SCLK back at idle. amdgpu_pm_info reports
"VCN: Powered down". Battery drain is about 5 W higher, (which for
my machine it makes about 1.5 hour at my daily usage).

- Persists across tab close, browser kill -9, all fds closed, VT switch.
- power_dpm_force_performance_level stays "auto" and
   pp_power_profile_mode stays BOOTUP_DEFAULT throughout.
- While latched, writing "low" or manual MCLK levels does not move it.
   After it is cleared, MCLK follows low/manual requests normally.
- Cleared by: amdgpu_gpu_recover (debugfs), or by playing a video in
   Firefox (MCLK goes to 667 MHz -sometimes 933 MHz- during playback).
- Firefox itself does not trigger it.

== What triggers it ==

- WebGL alone in Brave latches it, with VCN powered down the whole
   time. So this is not specific to a VCN decode teardown path.
   A clean Brave without custom flags behaves the same.
- VA-API video decode in Brave latches it with VaapiVideoDecoder
   confirmed active in media-internals, in each of these variants:
   default flags, --use-angle=gl,
   --disable-features=UseMultiPlaneFormatForHardwareVideo,
   --disable-features=VaapiIgnoreDriverChecks, even I run with
   temp user directory with no flags, VA-API decoding ran and same issue
   continued.
- mpv --hwdec=vaapi on the same file: MCLK is 933 MHz during playback.

== Kernel-side ==

I attached bpftrace kprobes (with kstack) to smum_send_msg_to_smc and
smum_send_msg_to_smc_with_parameter and ran: Brave WebGL, Brave
YouTube, close (latched), Firefox WebGL, Firefox video (released),
then amdgpu_gpu_recover.

- Before the latch was first observed: 152 SMU messages, all either
   GFXOFF enable/disable (smu10_gfx_off_control) or two VCN power
   up/down pairs (smu10_powergate_vcn). No smu10_dpm_force_dpm_level,
   no hard-min, active-display-count or deep-sleep messages.
- Between the latched read and the released read (Firefox): again only
   GFXOFF toggles and two balanced VCN up/down pairs. Brave's video
   session produces the same two pairs and does not release.
- A kprobe on rv1_update_clocks never fires during any browser
   activity, only during gpu_recover.
- Each read of pp_dpm_sclk/pp_dpm_mclk issues an SMU query
   (smu10_emit_clock_levels), so the reported value is live.

So neither setting nor releasing the state is visible on the SMU
mailbox through these wrappers. This would not show direct register or
table writes. I cannot tell whether the state lives in SMU firmware,
in the display/data fabric p-state handshake, or elsewhere.

== Questions ==

1. Is this a known issue on Raven/Picasso?
2. On SMU10, what other path can hold FCLK/MCLK high that does not go
    through the mailbox (DCN hubbub watermarks, DF p-state, firmware
    internal state)?
3. What should I trace next? amdgpu_dm_dtn_log returns EPERM here even
    as root (probably lockdown); I can boot without Secure Boot if that
    output would help.

Full trace logs and brave://media-internals output are available; I can
attach them if asked.

Thanks,
Ata

[REGRESSION] amdgpu: Raven/Picasso MCLK stays at 1200 MHz after Chromium exits

[Ata İlhan Köktürk]

[-- Attachment #1: Type: text/plain, Size: 4107 bytes --]

Hi,On a Picasso/Raven2 laptop, MCLK stays pinned at its highest level(1200 MHz) after a Chromium-based browser (Brave) has used the GPU andbeen closed. I could not find where the state is set or released fromthe driver side, so I am asking whether this is known and what else Ishould collect. I have the kernel tree and can test patches.== System ==Laptop:  Huawei MateBook D14 (NBLK-WAX9X), Ryzen 5 3500U,          Picasso/Raven2 1002:15d8 rev c2Distro:  Fedora 44, Sway 1.11 on WaylandKernel:  7.2.13-200.fc44.x86_64 (Fedora kernel, not tested on drm-next)amdgpu 3.64.0, DCN 1.0, SMU10, VCN 1.0 (ENC 1.15 DEC 3 VEP 0 Rev 9)Mesa 26.2.5, libva 2.23.0Boot:    amdgpu.noretry=0 amdgpu.ppfeaturemask=0xffffffff	 amdgpu.gpu_recovery=1 amdgpu.vcnfw_log=1	 amdgpu.dcdebugmask=0x10Userspace: no daemon or tool writes to amdgpu sysfs.== Symptom ==Idle: pp_dpm_mclk shows "0: 667Mhz *".After WebGL (WebGL Aquarium, sometimes this doesn't trigger?) orVA-API video (YouTube, VP9 1080p) in Brave, and closing the tabor the whole browser, pp_dpm_mclk shows "3: 1200Mhz *" indefinitely,with GPU load 0% and SCLK back at idle. amdgpu_pm_info reports"VCN: Powered down". Battery drain is about 5 W higher, (which formy machine it makes about 1.5 hour at my daily usage).- Persists across tab close, browser kill -9, all fds closed, VT switch.- power_dpm_force_performance_level stays "auto" and   pp_power_profile_mode stays BOOTUP_DEFAULT throughout.- While latched, writing "low" or manual MCLK levels does not move it.   After it is cleared, MCLK follows low/manual requests normally.- Cleared by: amdgpu_gpu_recover (debugfs), or by playing a video in   Firefox (MCLK goes to 667 MHz -sometimes 933 MHz- during playback).- Firefox itself does not trigger it.== What triggers it ==- WebGL alone in Brave latches it, with VCN powered down the whole   time. So this is not specific to a VCN decode teardown path.   A clean Brave without custom flags behaves the same.- VA-API video decode in Brave latches it with VaapiVideoDecoder   confirmed active in media-internals, in each of these variants:   default flags, --use-angle=gl,   --disable-features=UseMultiPlaneFormatForHardwareVideo,   --disable-features=VaapiIgnoreDriverChecks, even I run with   temp user directory with no flags, VA-API decoding ran and same issue   continued.- mpv --hwdec=vaapi on the same file: MCLK is 933 MHz during playback.== Kernel-side ==I attached bpftrace kprobes (with kstack) to smum_send_msg_to_smc andsmum_send_msg_to_smc_with_parameter and ran: Brave WebGL, BraveYouTube, close (latched), Firefox WebGL, Firefox video (released),then amdgpu_gpu_recover.- Before the latch was first observed: 152 SMU messages, all either   GFXOFF enable/disable (smu10_gfx_off_control) or two VCN power   up/down pairs (smu10_powergate_vcn). No smu10_dpm_force_dpm_level,   no hard-min, active-display-count or deep-sleep messages.- Between the latched read and the released read (Firefox): again only   GFXOFF toggles and two balanced VCN up/down pairs. Brave's video   session produces the same two pairs and does not release.- A kprobe on rv1_update_clocks never fires during any browser   activity, only during gpu_recover.- Each read of pp_dpm_sclk/pp_dpm_mclk issues an SMU query   (smu10_emit_clock_levels), so the reported value is live.So neither setting nor releasing the state is visible on the SMUmailbox through these wrappers. This would not show direct register ortable writes. I cannot tell whether the state lives in SMU firmware,in the display/data fabric p-state handshake, or elsewhere.== Questions ==1. Is this a known issue on Raven/Picasso?2. On SMU10, what other path can hold FCLK/MCLK high that does not go    through the mailbox (DCN hubbub watermarks, DF p-state, firmware    internal state)?3. What should I trace next? amdgpu_dm_dtn_log returns EPERM here even    as root (probably lockdown); I can boot without Secure Boot if that    output would help.Full trace logs and brave://media-internals output are available; I canattach them if asked.Thanks,Ata

[-- Attachment #2: Type: text/html, Size: 5886 bytes --]

Re: [REGRESSION] amdgpu: Raven/Picasso MCLK stays at 1200 MHz after Chromium exits

[Alex Deucher]

On Mon, Nov 9, 2026 at 4:56 AM Ata İlhan Köktürk <atailhan2006@gmail.com> wrote:
>
> Hi,
>
> On a Picasso/Raven2 laptop, MCLK stays pinned at its highest level
> (1200 MHz) after a Chromium-based browser (Brave) has used the GPU and
> been closed. I could not find where the state is set or released from
> the driver side, so I am asking whether this is known and what else I
> should collect. I have the kernel tree and can test patches.
>
> == System ==
>
> Laptop:  Huawei MateBook D14 (NBLK-WAX9X), Ryzen 5 3500U,
>           Picasso/Raven2 1002:15d8 rev c2
> Distro:  Fedora 44, Sway 1.11 on Wayland
> Kernel:  7.2.13-200.fc44.x86_64 (Fedora kernel, not tested on drm-next)
> amdgpu 3.64.0, DCN 1.0, SMU10, VCN 1.0 (ENC 1.15 DEC 3 VEP 0 Rev 9)
> Mesa 26.2.5, libva 2.23.0
> Boot:    amdgpu.noretry=0 amdgpu.ppfeaturemask=0xffffffff
> amdgpu.gpu_recovery=1 amdgpu.vcnfw_log=1
> amdgpu.dcdebugmask=0x10
> Userspace: no daemon or tool writes to amdgpu sysfs.
>
> == Symptom ==
>
> Idle: pp_dpm_mclk shows "0: 667Mhz *".
>
> After WebGL (WebGL Aquarium, sometimes this doesn't trigger?) or
> VA-API video (YouTube, VP9 1080p) in Brave, and closing the tab
> or the whole browser, pp_dpm_mclk shows "3: 1200Mhz *" indefinitely,
> with GPU load 0% and SCLK back at idle. amdgpu_pm_info reports
> "VCN: Powered down". Battery drain is about 5 W higher, (which for
> my machine it makes about 1.5 hour at my daily usage).
>
> - Persists across tab close, browser kill -9, all fds closed, VT switch.
> - power_dpm_force_performance_level stays "auto" and
>    pp_power_profile_mode stays BOOTUP_DEFAULT throughout.
> - While latched, writing "low" or manual MCLK levels does not move it.
>    After it is cleared, MCLK follows low/manual requests normally.
> - Cleared by: amdgpu_gpu_recover (debugfs), or by playing a video in
>    Firefox (MCLK goes to 667 MHz -sometimes 933 MHz- during playback).
> - Firefox itself does not trigger it.
>
> == What triggers it ==
>
> - WebGL alone in Brave latches it, with VCN powered down the whole
>    time. So this is not specific to a VCN decode teardown path.
>    A clean Brave without custom flags behaves the same.
> - VA-API video decode in Brave latches it with VaapiVideoDecoder
>    confirmed active in media-internals, in each of these variants:
>    default flags, --use-angle=gl,
>    --disable-features=UseMultiPlaneFormatForHardwareVideo,
>    --disable-features=VaapiIgnoreDriverChecks, even I run with
>    temp user directory with no flags, VA-API decoding ran and same issue
>    continued.
> - mpv --hwdec=vaapi on the same file: MCLK is 933 MHz during playback.
>
> == Kernel-side ==
>
> I attached bpftrace kprobes (with kstack) to smum_send_msg_to_smc and
> smum_send_msg_to_smc_with_parameter and ran: Brave WebGL, Brave
> YouTube, close (latched), Firefox WebGL, Firefox video (released),
> then amdgpu_gpu_recover.
>
> - Before the latch was first observed: 152 SMU messages, all either
>    GFXOFF enable/disable (smu10_gfx_off_control) or two VCN power
>    up/down pairs (smu10_powergate_vcn). No smu10_dpm_force_dpm_level,
>    no hard-min, active-display-count or deep-sleep messages.
> - Between the latched read and the released read (Firefox): again only
>    GFXOFF toggles and two balanced VCN up/down pairs. Brave's video
>    session produces the same two pairs and does not release.
> - A kprobe on rv1_update_clocks never fires during any browser
>    activity, only during gpu_recover.
> - Each read of pp_dpm_sclk/pp_dpm_mclk issues an SMU query
>    (smu10_emit_clock_levels), so the reported value is live.
>
> So neither setting nor releasing the state is visible on the SMU
> mailbox through these wrappers. This would not show direct register or
> table writes. I cannot tell whether the state lives in SMU firmware,
> in the display/data fabric p-state handshake, or elsewhere.
>
> == Questions ==
>
> 1. Is this a known issue on Raven/Picasso?
> 2. On SMU10, what other path can hold FCLK/MCLK high that does not go
>     through the mailbox (DCN hubbub watermarks, DF p-state, firmware
>     internal state)?
> 3. What should I trace next? amdgpu_dm_dtn_log returns EPERM here even
>     as root (probably lockdown); I can boot without Secure Boot if that
>     output would help.
>

Please open a ticket at:
https://gitlab.freedesktop.org/drm/amd/-/work_items
If you recently updated the firmware can you try going back to an
older firmware?  If you changed your kernel can you bisect?

Alex