Bug 2391221

TLDR version: There is a regression in power handling on kernel 6.15.11 and 6.16.3, due to bug(s) in AMD suspend/resume code within the kernel.

Patch against kernel 6.17-rc3 to potentially fix the bug is available from Mario Limonciello (AMD): https://lore.kernel.org/linux-pm/20250826052747.2240670-1-superm1@kernel.org/T/#uncategorized

Could you apply the patch to Fedora kernels?

Other relevant bug reports:
* https://bugzilla.kernel.org/show_bug.cgi?id=219981
* https://community.frame.work/t/increased-power-usage-after-resuming-from-suspend-on-ryzen-7040-kernel-6-15-regression/74531
* https://github.com/redhat-performance/tuned/issues/789

Problem description - long version:

After coming out of suspend, the actual energy preference is always reported as "performance", even though it was set to "power" before suspend.

The regression does NOT occur on kernel 6.14.11 (everything else is the same except kernel version).

Machine setup: Framework AMD FW13 laptop, AMD Ryzen 5 7640U. Using Fedora 41, tuned-2.25.1-2, kernel 6.15.11 / 6.16.3, gnome-shell 47.9, latest framework bios (3.16).

How to reproduce:

Before suspend: using the gnome shell top-right menu to set the power mode to "Power Saver", which under the hood uses TuneD. The change in the energy preference after the resume is NOT reflected in the gnome shell top-right menu (still says "Power Saver"). However, the actual mode can be seen via the cpupower command (part of kernel-tools).

State before suspend according to cpupower:

$ sudo cpupower frequency-info
analyzing CPU 0:
driver: amd-pstate-epp
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
energy performance preference: power

State after resuming from suspend according to cpupower:

$ sudo cpupower frequency-info
analyzing CPU 6:
driver: amd-pstate-epp
CPUs which run at the same hardware frequency: 6
CPUs which need to have their frequency coordinated by software: 6
energy performance preference: performance


2. What is the Version-Release number of the kernel:

Known affected kernels:
kernel-6.15.11-100.fc41.x86_64
kernel-6.16.3-100.fc41.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :

Known to work properly with:
kernel-6.14.11-200.fc41.x86_64

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

Yes, see the "Long version" section above.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:

Haven't tried, though I did try kernel-6.16.3-100.fc41.x86_64 from koji:
https://kojipkgs.fedoraproject.org/packages/kernel/6.16.3/

6. Are you running any modules that not shipped with directly Fedora's kernel?:

No.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.



Reproducible: Always