On Mon, Nov 9, 2026 at 4:56 AM Ata İlhan Köktürk <[email protected]> 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
