Created attachment 2019130 [details]
lscpu.txt

Created attachment 2019131 [details]
lspci.txt

@mpearson Hey Mark, this is something that you might be interested at, perhaps. Thanks.

Ack - we're already looking at this one. Internal ticket is LO-2468

FW team are having trouble reproducing it with the images we certified the platform with so are pointing at the kernel - which doesn't yet make sense to me. Normally these issues are FW related. We're doing ongoing debug to try and narrow down the issue.
Thanks for the report and details - it's useful to have some other logs to review

Mark

Thanks, Mark. If you want me to provide any further debugging logs, just tell me how. It just happened to me again this morning (that's a second time in 6 days of usage of this laptop), so it seems there's a decent chance to trigger it every few days.

As a note, I reproduced this on my system. Easy repro is to suspend, unplug from power, and resume. 
Using this I narrowed it down to breaking between 6.4 and 6.5-rc1. Did a bisect and it looks like this commit is causing the issue:
https://github.com/torvalds/linux/commit/b5539eb5ee70257520e40bb636a295217c329a50

I'm working with AMD on determining best next steps - but for now this is looking like a kernel regression issue.

Mark

I've fully updated my ThinkPad P16v [1] and used kernel-6.10.1-200.fc40, and the issue is now different. I can no longer use "suspend, unplug from power, and resume" reproducer, because any time I connect or disconnect AC power during suspend, the laptop immediately resumes. Which is quite annoying (breaks the "close laptop, unplug, put it into your bag" workflow), but also precludes testing any fix for this. The issue might or might not still be there, but with the current behavior, I can't tell.

[1] System Firmware 0.1.52

(In reply to Kamil Páral from comment #7)
> I can no longer use "suspend, unplug from power,
> and resume" reproducer, because any time I connect or disconnect AC power
> during suspend, the laptop immediately resumes.

I've reported this problem separately as bug 2301921.

Now that bug 2301921 was resolved, I was able to re-test this. Unfortunately this is still an issue, exactly the same symptoms, exactly the same reproducer (see comment 6). Tested on Fedora 41 with kernel-6.11.0-63.fc41.

This message is a reminder that Fedora Linux 39 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '39'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 39 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

I'm having the same problem with F41. It is constantly reproducible. Happens ONLY when resuming from standby.

More details in https://discussion.fedoraproject.org/t/f41-is-sluggish-after-resuming-from-suspend-fixed-by-a-restart/147352

Apologies, I'd missed updating this bug. 
The FW team and AMD have narrowed down on the root cause and are fixing this in FW. I've tested a trial FW and it works.
It was a tricky issue to resolve and is a signal timing related issue. They are doing some more testing to determine the optimum setting for the fix, and there will be a formal FW release once that exercise is complete.

I don't have the ETA yet, but it is being treated as high priority. I will update once I have the new release details (do nag me if it goes a few weeks without anything..)

I think the workaround, until the updated FW is available, is to plug power in and out again (I'll check that...I have it in my notes somewhere...)

Mark

Any chance there are any updates on an ETA for the firmware fix that addresses this issue?

Not yet - they found some issues in testing of the new release (unrelated) that are being investigated.
Mark

Any updates on this?  We are getting many requests from employees asking to replace their device because of this model's issues.

Just waiting for the updated EC release - I've asked for the ETA date, I hadn't heard of any issues with this since the last date so it should be working it's way thru the FW team testing process.
Mark

Hello,

Is there an ETA date for this fix?

Update from FW team is that the fix is included in EC 1.12 (30W) - this is posted on LVFS so should be offered as an update.
Note, there is also BIOS 1.59 (59W) available as well.

I haven't had a chance to test these myself. Will aim to do so shortly.

I have installed the new firmware, but the issue is still present.

@saroy Could you confirm your BIOS and EC version please? I did check on my system and confirmed it's working correctly.

saroy@saroy-thinkpadp16vgen1:~$ cat /sys/class/dmi/id/bios_version
N3VET59W (1.59 )
saroy@saroy-thinkpadp16vgen1:~$ cat /sys/class/dmi/id/ec_firmware_release
1.12
saroy@saroy-thinkpadp16vgen1:~$ sudo dmidecode -t bios
[sudo] password for saroy: 
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x000F, DMI type 0, 26 bytes
BIOS Information
	Vendor: LENOVO
	Version: N3VET59W (1.59 )
	Release Date: 05/13/2025
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 32 MB
	Characteristics:
		PCI is supported
		PNP is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		3.5"/720 kB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	BIOS Revision: 1.59
	Firmware Revision: 1.12

Handle 0x0018, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Abbreviated
	Installable Languages: 6
		en-US
		fr-FR
		ja-JP
		ko-KR
		zh-CHT
		zh-CHS
	Currently Installed Language: en-US

Thanks - that's exactly the same as I have on my system and it's working for me now (and I could reproduce reliably previously).
Can you share the steps you do to reproduce the issue please, in case I'm missing something

I have ThinkPad Thunderbolt 4 Dock and my laptop lid is closed always, using external Monitor. 
When I put my Fedora 42 on suspend over night, also turn off AC power from main,  at the morning I encounter the lag and all CPU stuck at around 500Mhz.

(Obviously when upgrading firmware I opened my lid)

Let me clarify to make sure I have it correct. Please correct anything below:

 - P15v G1 AMD <--> TBT4 dock <--> monitor.
 - P15v G1 AMD has lid closed all the time and is getting power from the dock?
 - Suspend system and also power off the dock over night.
 - Turn power on to dock in the AM
 - Resume P15v.
 - Check CPU frequences (from /proc/cpuinfo?)

Can you confirm that these steps don't reproduce the problem for you please:
 - P15v G1 AMD not connected to anything with power directly connected.
 - Suspend system
 - unplug power - confirm system doesn't wake up
 - resume system and check CPU frequencies.
I'd like to make sure this works, as the dock setup issue may be something different.

Thanks

I'm still facing the same problem. Here's some details (no dock involved):

➜  ~  cat /sys/class/dmi/id/bios_version
N3VET59W (1.59 )
➜  ~ cat /sys/class/dmi/id/ec_firmware_release
1.12
➜  ~ sudo dmidecode -t bios
[sudo] password for nchakrab: 
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x000F, DMI type 0, 26 bytes
BIOS Information
        Vendor: LENOVO
        Version: N3VET59W (1.59 )
        Release Date: 05/13/2025
        Address: 0xE0000
        Runtime Size: 128 kB
        ROM Size: 32 MB
        Characteristics:
                PCI is supported
                PNP is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                EDD is supported
                3.5"/720 kB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                CGA/mono video services are supported (int 10h)
                ACPI is supported
                USB legacy is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
                UEFI is supported
        BIOS Revision: 1.59
        Firmware Revision: 1.12

Handle 0x0018, DMI type 13, 22 bytes
BIOS Language Information
        Language Description Format: Abbreviated
        Installable Languages: 6
                en-US
                fr-FR
                ja-JP
                ko-KR
                zh-CHT
                zh-CHS
        Currently Installed Language: en-US

This message is a reminder that Fedora Linux 41 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '41'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 41 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

This bug/issue is still present even in Rawhide - with 6.18.0-0.rc7.58.fc44.x86_64

Happened to me just on Friday...

With BIOS: N3VET59W (1.59 )

Happened when unplugged from dock in office and plugged back as home-dock...

(In reply to Mark Pearson from comment #24)
> Let me clarify to make sure I have it correct. Please correct anything below:
> 
>  - P15v G1 AMD <--> TBT4 dock <--> monitor.
>  - P15v G1 AMD has lid closed all the time and is getting power from the
> dock?
>  - Suspend system and also power off the dock over night.
>  - Turn power on to dock in the AM
>  - Resume P15v.
>  - Check CPU frequences (from /proc/cpuinfo?)
> 
> Can you confirm that these steps don't reproduce the problem for you please:
>  - P15v G1 AMD not connected to anything with power directly connected.
>  - Suspend system
>  - unplug power - confirm system doesn't wake up
>  - resume system and check CPU frequencies.
> I'd like to make sure this works, as the dock setup issue may be something
> different.
> 
> Thanks

Running P15V G1 AMD connected directly to a power source, I suspend the system, unplug power and resume system. The CPU frequency gets stuck at 400-500 MHz.

Mark - could you please look into this?

@nchakrab - Assume you mean P16v (looks like I made the same typo). If it's a different machine then we'll need a new ticket

Can you confirm distro, kernel, BIOS and EC versions please? Any kernel log is useful too

If possible please collect the EC registers when in the 400Mhz condition too (easiest is to use https://github.com/mrhpearson/ecreg-dump)

Thanks

(In reply to Mark Pearson from comment #29)
> @nchakrab - Assume you mean P16v (looks like I made the same
> typo). If it's a different machine then we'll need a new ticket
> 
> Can you confirm distro, kernel, BIOS and EC versions please? Any kernel log
> is useful too
> 
> If possible please collect the EC registers when in the 400Mhz condition too
> (easiest is to use https://github.com/mrhpearson/ecreg-dump)
> 
> Thanks

Yep, it's a P16v Gen 1.

More information:

➜  ~ cat /etc/os-release 
NAME="Fedora Linux"
VERSION="43 (Workstation Edition)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=43
VERSION_CODENAME=""
PRETTY_NAME="Fedora Linux 43 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:43"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f43/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=43
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=43
SUPPORT_END=2026-12-02
VARIANT="Workstation Edition"
VARIANT_ID=workstation

➜  ~ uname -a                                      
Linux nchakrab-thinkpadp16vgen1.rmtin.csb 6.17.12-300.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Dec 13 05:06:24 UTC 2025 x86_64 GNU/Linux

➜  ~ cat /sys/class/dmi/id/bios_version      
N3VET59W (1.59 )

➜  ~ cat /sys/class/dmi/id/ec_firmware_release
1.12

➜  ~ sudo dmidecode -t bios     
[sudo] password for nchakrab: 
# dmidecode 3.6
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x000F, DMI type 0, 26 bytes
BIOS Information
        Vendor: LENOVO
        Version: N3VET59W (1.59 )
        Release Date: 05/13/2025
        Address: 0xE0000
        Runtime Size: 128 kB
        ROM Size: 32 MB
        Characteristics:
                PCI is supported
                PNP is supported
                BIOS is upgradeable
                BIOS shadowing is allowed
                Boot from CD is supported
                Selectable boot is supported
                EDD is supported
                3.5"/720 kB floppy services are supported (int 13h)
                Print screen service is supported (int 5h)
                8042 keyboard services are supported (int 9h)
                Serial services are supported (int 14h)
                Printer services are supported (int 17h)
                CGA/mono video services are supported (int 10h)
                ACPI is supported
                USB legacy is supported
                BIOS boot specification is supported
                Targeted content distribution is supported
                UEFI is supported
        BIOS Revision: 1.59
        Firmware Revision: 1.12

Handle 0x0018, DMI type 13, 22 bytes
BIOS Language Information
        Language Description Format: Abbreviated
        Installable Languages: 6
                en-US
                fr-FR
                ja-JP
                ko-KR
                zh-CHT
                zh-CHS
        Currently Installed Language: en-US

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

still happens with Rawhide and kernel 7.1-rc1.....

This report has not received an update in over 90 days. If this issue is still relevant to you, please do not hesitate to update this report with any relevant details on recent investigative steps or changes and we will absolutely work to understand how to best move forward. Otherwise, this bug report will need to be closed in 30 days. No worries, however; should you need still assistance after the report is closed, please do not hesitate to create a new bug report referencing this report and with any new details on the matter. 

NOTE: This is an automated mass update.

I've had a thinkpad P16v Gen1 for two weeks, have NOT encountered this issue so far:


➜ uname -a
Linux pragazzi-thinkpadp16vgen1.tpbc.csb 7.2.4-200.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Sep  7 19:10:19 UTC 2026 x86_64 GNU/Linux


➜ cat /etc/os-release 
NAME="Fedora Linux"
VERSION="44 (Workstation Edition)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=44
VERSION_CODENAME=""
PRETTY_NAME="Fedora Linux 44 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:44"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f44/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=44
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=44
SUPPORT_END=2027-05-19
VARIANT="Workstation Edition"
VARIANT_ID=workstation



➜ dmidecode -t bios
# dmidecode 3.7
Getting SMBIOS data from sysfs.
SMBIOS 3.3.0 present.

Handle 0x0010, DMI type 0, 26 bytes
Platform Firmware Information
	Vendor: LENOVO
	Version: N3VET65W (1.65 )
	Release Date: 03/31/2026
	Address: 0xE0000
	Runtime Size: 128 KiB
	ROM Size: 32 MiB
	Characteristics:
		PCI is supported
		PNP is supported
		Firmware is upgradeable
		Firmware shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		3.5"/720 kB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
		UEFI is supported
	Platform Firmware Revision: 1.65
	Embedded Controller Firmware Revision: 1.12

 
➜ upower -i /org/freedesktop/UPower/devices/battery_BAT0    (of course power stats are relative to the time of probing)
  native-path:          BAT0
  vendor:               Celxpert
  model:                5B11M90093
  serial:               2145
  power supply:         yes
  updated:              Mon 14 Sep 2026 02:44:08 PM CEST (23 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               pending-charge
    warning-level:       none
    energy:              70.26 Wh
    energy-empty:        0 Wh
    energy-full:         88.93 Wh
    energy-full-design:  90 Wh
    voltage-min-design:  15.52 V
    capacity-level:      Normal
    energy-rate:         0 W
    voltage:             16.244 V
    charge-cycles:       17
    percentage:          79%
    capacity:            98.8111%
    technology:          lithium-polymer
    charge-start-threshold:        75%
    charge-end-threshold:          80%
    charge-threshold-enabled:      yes
    charge-threshold-supported:    yes
    icon-name:          'battery-full-charging-symbolic'
  History (voltage):
    1789389818	16.244	pending-charge
    1789389788	16.245	pending-charge


➜ lscpu | grep Model
Model name:                              AMD Ryzen 7 PRO 7840HS w/ Radeon 780M Graphics
Model:                                   116

I'm still hitting this issue  when flipping between  office  (with dock) and home  (no dock).
As a simply workaround it's usually enough to unplug an plug-in power cord - in most case it's fixing the problem.

But it's still present with 7.X kernels.

# AMD Ryzen 7 PRO 7840HS (Phoenix) stuck at ~544 MHz after s2idle resume -
# firmware/SMU clamps far below the OS request, only a reboot recovers

Collected 2026-10-24 on a Lenovo ThinkPad P16v Gen 1. All commands run with
LANG=C LC_ALL=C. Files referenced below are in this directory.

## Summary

After a resume from `s2idle`, the CPU delivers only ~536-557 MHz on every
thread, even under full load, and even though the OS asks for up to 5.14 GHz.
The clamp is enforced by firmware/SMU, not by the OS: the kernel's CPPC request
is ignored in all forms (including min_perf = max_perf = 196 = 5.14 GHz), the
legacy P-state limit MSR reports the CPU pinned to P2, and that MSR is
read-only (#GP on any write). Temperatures are ~40 C, package power stays at
~6.1-6.4 W idle and loaded, no thermal interrupts fire, and no RAPL/cgroup/
governor/EPP/platform-profile/PMF limit is active. Recovery without reboot is
possible: a power-source transition (unplugging or plugging the AC adapter)
re-programs the limit within about a second - confirmed by live measurement on
2026-10-24 19:58-20:00. Before that the CPU was fast again at 4.9 GHz with MSR
0xc0010061 = 0x20; while clamped it reads 0x22.

Trigger observed: the machine was demonstrably fast at boot (userspace startup
6.7 s, same as healthy boots) and was found slow after the s2idle resume at
2026-10-24 13:29:20. The user reports the same thing happening "from time to
time", on battery and on AC.

## Environment

| Item | Value |
|---|---|
| Machine | LENOVO 21FFS02H22 (ThinkPad P16v Gen 1), BIOS N3VET65W (1.65), EC N3VHT30W |
| CPU | AMD Ryzen 7 PRO 7840HS w/ Radeon 780M, family 25 model 116 stepping 1, microcode 0xa70410a, 8C/16T, socket FP8 |
| OS | Fedora Linux 46 (rawhide), kernel 7.3.0-65.fc46.x86_64 (SMP PREEMPT_DYNAMIC, built 2026-10-19) |
| Boot | 2026-10-23 10:51:04 CEST, uptime ~27 h at collection time |
| Power | on battery (AC offline), BAT0 at 73 %, discharging ~12 W |
| cpufreq | amd-pstate-epp, active mode, governor powersave, EPP balance_power, boost=1 |
| Limits | hardware 419 MHz - 5.14 GHz; scaling 1.10098 - 5.137904 GHz |
| CPPC | highest_perf 196 (5.14 GHz), nominal 145 (3.80 GHz), lowest_nonlinear 42 (1.10 GHz), lowest 16 (400 MHz), preferred cores enabled, policy0 ranking 208 |

## Symptom

Every core reports `scaling_cur_freq` ~543-545 MHz and this does not change
under load:

```
$ for i in 0 8; do taskset -c $i ./bench2; done
adds=2000000000 sec=3.735 -> 535.4 MHz (dependent-add latency=1)
adds=2000000000 sec=3.729 -> 536.3 MHz (dependent-add latency=1)
```

`bench2` is a register-only chain of dependent `add $1, %rax` instructions
(1-cycle latency on Zen, verified in the disassembly), so the result is the
delivered clock, not a memory/scheduling effect. `perf stat` agrees:

```
cycles        2,033,929,146   (3.7366 s -> 544.3 MHz)
instructions  2,068,562,687   (IPC 1.017)
tsc          14,172,035,590   (3.792 GHz, unaffected)
ref-cycles   14,169,706,608   (== tsc)
```

The 20 ms `perf stat -I 20` intervals are flat (p10 551, p50 553, p90 554,
max 557 MHz; only the first/last partial interval is lower), so the core does
not alternate between "fast" and "halted" on a >20 ms timescale.

## What the hardware says

### Legacy P-state MSRs (per CPU, identical on all 16 CPUs)

```
0xc0010061 PstateCurLim = 0x22
0xc0010063 PstateStatus = 0x2
0xc0010062 PstateCtl    = 0x0
0xc0010015 HWCR         = 0x1c9006011
```

Decoding 0x22 with the layout used by cpupower
(`tools/power/cpupower/utils/helpers/amd.c`: `psmax = (val >> 4) & 0x7`):
bits[6:4] = 2 (max P-state = P2) and bits[2:0] = 2 - i.e. the limit spans
P2..P2, the CPU is pinned to P2, not merely capped at it.

P-state definitions (MSR 0xc0010064..0xc001006b, formula `200 * fid / did`):

| P-state | raw | fid | did | frequency |
|---|---|---|---|---|
| P0 | 0x8000000049afc898 | 152 | 8 | 3800 MHz |
| P1 | 0x8000000045aac858 | 88 | 8 | 2200 MHz |
| P2 | 0x800000004425ca50 | 80 | 10 | 1600 MHz |
| P3..P7 | 0 | - | - | invalid (PstateEn=0) |

So P2 is 1600 MHz, yet only ~544 MHz is delivered - the core is additionally
stuttered to about one third of P2 (HTC/PROCHOT-style duty cycling), or the SMU
runs a CPPC frequency outside the legacy table. Either way the CPU is pinned to
its lowest allowed operating point *and* throttled below it.

### CPPC is ignored

```
0xc00102b1 CPPC enable = 1
0xc00102b3 CPPC_REQ    = 0xbf002bc4   (min_perf 43, max_perf 196, desired 0, EPP 0xbf)
0xc00102b0             = 0xd0912a10d0912a10
0xc00102b4             = 0
```

Tests (probe-33, probe-36):

| Action | CPPC_REQ after | Delivered |
|---|---|---|
| none | 0xbf002bc4 | 544 MHz |
| `scaling_min_freq = scaling_max_freq = 5137904` | 0xbf00c4c4 (min=max=196) | 536 MHz |
| direct `wrmsr 0xc00102b3 = 0xbfc4c4c4` (desired=196) | 0xbfc4c4c4 | 535 MHz |

The SMU ignores the OS request in every form, including "minimum = maximum =
5.14 GHz". It even violates its own advertised `min_perf` (43 / 1.10 GHz).

### The limit cannot be changed by software

```
$ sudo wrmsr -a 0xc0010061 0
wrmsr: CPU 0 cannot set MSR 0xc0010061 to 0x0000000000000000
```

Tried 0x0, 0x2, 0x7, 0x12 and 0x22 - every write returns #GP and the value
stays 0x22. Writing 0xc0010062 (PstateCtl) is accepted but ignored (status
stays P2). CPU15 offline/online re-applies the limit on the fresh core
(CurLim 0x22, 544 MHz). This is expected when CPPC is enabled: the legacy
P-state MSRs belong to the SMU, and the OS is supposed to steer via CPPC - which
the SMU ignores here.

## What was ruled out

| Candidate | Evidence |
|---|---|
| Thermal | Tctl 40.4 C, acpitz 40 C, amdgpu 39 C, nvme 30.9 C; THM0 trip 106 C; 16 Processor cooling devices all cur_state=0; /proc/interrupts TRM/THR = 0; no thermal_throttle files; dmesg has no thermal events |
| Package power / RAPL | RAPL energy read directly from 0xc001029a/0xc001029b (powercap disabled): idle 6.10 W package, full 16-thread load 6.17 W (probe-14); 16x `yes` load 6.38 W with 1562 % CPU accounted in /proc/stat (probe-18). No budget is being consumed. Single-thread on an otherwise idle machine is equally slow, so it is not a shared power limit |
| Cgroup / scheduler | own cgroup session-2.scope, `cpu.max max 100000`, nr_throttled 0; bench2 98 % CPU (probe-15) |
| Governor / EPP / platform profile | powersave+balance_power, performance+performance, platform_profile performance - all 544 MHz (probe-19, probe-07) |
| RAPL powercap | intel_rapl:0 and intel_rapl:0:0 both `enabled=0` |
| AMD PMF / CnQF / STT | amd_pmf is loaded but has ZERO bound devices; AMDI0052:00 sits in `waiting_for_supplier`; no cnqf/stt sysfs attributes exist (probe-20, probe-32) |
| ACPI _PPC | ssdt6 declares `Name (PPCV, 0)` + `_PPC { Return (PPCV) }` for C000..C00F; no table writes PPCV, so _PPC is always 0 = no limit (acpi-26, acpi-27) |
| EC / GPE storm | gpe_all 168753, sci 168744, sci_not 14 - healthy; no EC or ACPI errors around the resume (probe-29) |

## ACPI/firmware notes

* `FPPT` and `SPPT` (fast/slow package power tracking, 8-bit each) exist at
  dsdt.dsl lines 10082-10083 inside the EC/BIOS NVS field block at Offset 0xFAB,
  but no ACPI method reads them.
* The DSDT contains an AMD ACPI-to-SMU mailbox: `Method (SSTT, 1)` (~line 21016)
  builds a 7-byte `{SSZE=7, SMUF=func, SMUD=data}` buffer and, for 21 function
  IDs from `STTI[]` (0x20-0x2E, 0x07, 0x13, 0x06, 0x08, 0x03, 0x32), sends them
  through `ALIB (0x0C, ...)`. It is called once (dsdt line 20999) only when
  `PSDT == 0`. Linux never executes it (amd-pmf is not bound), so the SMU
  limits are programmed by the BIOS/SMI alone and the OS has no way to
  re-apply them after resume.
* `DYTC` (Lenovo EC HKEY method, used for thermal mode / platform profile) is
  invoked with constants such as 0x001FA001 / 0x000FA001 / 0x001F4001 /
  0x000FE001; this is the path behind platform_profile. Switching it to
  performance does not help.
* Boot logs one unrelated BIOS bug:
  `ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.GPP7._DSD], AE_ALREADY_EXISTS`.

## Timeline

| When | Event |
|---|---|
| 2026-10-23 10:51:04 | boot; userspace startup 6.715 s (normal - CPU fast) |
| 2026-10-23 15:56:20, 15:56:56, 22:59:14 | s2idle resumes |
| 2026-10-24 01:14:34, 08:55:28, 13:29:20 | s2idle resumes |
| 2026-10-24 ~13:30 | user notices the machine is extremely slow |
| 2026-10-24 14:05-14:40 | this data collection |
| 2026-10-24 19:58:57 | AC plugged while clamped - profile switches to performance, limit stays 0x22, still ~544 MHz |
| 2026-10-24 19:59:12-13 | AC removed - MSR 0xc0010061 goes 0x22 -> 0x20, full speed returns within ~1 s |
| 2026-10-24 19:59:25 | AC re-plugged, stays fast (0x20, 2.9-4.9 GHz) |
| 2026-10-24 20:00:32 | fast-state reference captured (bench 4894.5 MHz, package 11.1 W) |

Reference: healthy boots in the journal finish userspace in 6.5-6.8 s
(2026-10-19, 2026-10-21), so the current boot was fast before the failure. One
earlier boot (2026-10-21 12:59 - 2026-10-23 10:50) had 31.3 s userspace startup,
which may be an earlier occurrence of the same condition, or an unrelated delay.

## Conclusions

1. The CPU is held down by firmware: MSR 0xc0010061 reads 0x22 (limit field 2,
   i.e. max P-state P2 = 1600 MHz) and delivers only ~536-557 MHz, ~7x slower
   than nominal and ~2x below the driver's own 1.1 GHz floor. The extra ~3x gap
   below P2 is consistent with duty-cycle throttling (HTC/PROCHOT-style), but
   that is not proven. In the healthy state the same MSR reads 0x20 and the
   CPU boosts to 4.9 GHz, while PstateStatus reads 2 in both states - so
   PstateStatus is not a useful indicator, 0xc0010061 is.
2. The clamp is in firmware/SMU: the CPPC request is ignored even at
   min=max=desired=5.14 GHz, the legacy limit MSR is read-only, and PstateCtl
   writes are ignored. No Linux-side code can override it.
3. It is not thermal, not RAPL/powercap, not cgroup, not governor/EPP, not
   platform_profile, not PMF/CnQF, not an ACPI _PPC limit.
4. The most plausible mechanism is a firmware/SMU (or EC) state latched across
   s2idle resume - e.g. a stale skin-temperature/power-tracking or PROCHOT
   state - that never gets re-initialized because nothing in the OS re-programs
   the SMU after resume. This is a platform firmware bug, not a Linux bug;
   Linux can only detect and report it.
5. There is no useful kernel patch: the controlling MSRs are read-only and the
   firmware mailbox (SSTT/ALIB) is not exposed to the OS. A diagnostic in
   amd-pstate (warn when delivered perf stays far below `min_perf`) would only
   make the condition visible.
6. The clamp is cleared by an EC power-source transition, not by AC presence:
   plugging the adapter while clamped did nothing for 14 s (only the platform
   profile switched to performance), but removing the adapter one minute later
   immediately restored the correct limit (0x20) and full speed. This points at
   the EC: after resume it leaves a stale "low power" P-state limit in the SMU,
   and the next power-source change re-programs it correctly.

## Workarounds

1. Reboot - known to restore full speed.
   Confirmed workaround without reboot: trigger an EC power-source change -
   unplug the AC adapter (or plug/replug it) and the limit clears within
   ~1 second. See "Result of the AC-transition test" below.
2. Suspend/resume - suspected to clear it as well, but deliberately not tested
   here to preserve the reproduction. Worth trying next time *after* capturing
   the fast-state reference.
3. EC/firmware reset - power off, unplug AC, hold the power button ~30 s
   (battery is internal on this model, so a full EC reset may not be possible
   without opening the machine).
4. Check for a newer BIOS/EC than N3VET65W / N3VHT30W at Lenovo support.
5. As a mitigation, use `amd_pstate=passive` (legacy P-state path) on the next
   boot: if the SMU honours explicit P-state requests there, it would give the
   OS a lever; this needs a reboot to test, so it can be combined with the
   fast-state reference capture.

## Open questions / next data to collect

* Is `0xc0010061` also 0x22 in a *fast* state? ANSWERED: no, it is 0x20 in the
  healthy state (0x22 only while clamped).
* Does a suspend/resume cycle restore full speed (and does the value change)?
  Still untested - a fast-state reference has now been captured (see below) so
  it can be tested safely next time.
* Does connecting the AC adapter restore full speed? ANSWERED: not by plugging
  it (the clamp survived 14 s of AC), but by the power-source *transition*:
  unplugging it cleared the limit within ~1 second. See below.
* Does `amd_pstate=passive` change anything? Untested.

## Result of the AC-transition test (2026-10-24 19:58-20:00)

Captured live with `sudo ./probe-ac-transition.sh 600 1 60` on the still-clamped
machine; raw data in `probe-37-ac-transition-20261024-195849.txt`.

| Time (CEST) | AC | platform profile | MSR 0xc0010061 | cpu0 freq | Note |
|---|---|---|---|---|---|
| 19:58:49-19:58:56 | 0 | balanced | 0x22 | ~544 MHz | baseline, clamped |
| 19:58:57 | 1 | performance | 0x22 | ~544 MHz | AC plugged: profile and EPP change, speed does NOT |
| 19:58:58-19:59:11 | 1 | performance | 0x22 | 531-544 MHz | 14 s on AC, still clamped |
| 19:59:12 | 0 | balanced | 0x22 | ~544 MHz | AC removed |
| 19:59:13 | 0 | balanced | **0x20** | 1312 MHz | limit cleared ~1 s after the power-source change |
| 19:59:14-19:59:24 | 0 | balanced | 0x20 | 1.2-2.4 GHz | normal battery operation |
| 19:59:25 | 1 | performance | 0x20 | 2.9-4.9 GHz | AC re-plugged, stays fast |
| 20:00:32 | 1 | performance | 0x20 | 3.33 GHz | `fast-state-2026-10-24-2000.txt` |

Fast-state reference (`fast-state-2026-10-24-2000.txt`): AC online,
governor powersave, EPP balance_performance, `scaling_cur_freq` 3.33 GHz,
CPPC request 0x80002bc4, MSR 0xc0010061 = 0x20 on all CPUs, PstateStatus 2,
`bench2`: 2e9 adds in 0.409 s = 4894.5 MHz, package 11.11 W over the 2 s
window (compare: 6.1-6.4 W while clamped even with 16 threads busy).

Interpretation:

* The clamp is NOT "battery mode": it survives 14 s of AC connection, and the
  platform-profile/EPP switch to performance does not clear it either (this
  matches the earlier on-battery profile=performance test).
* It IS cleared by a power-source transition processed after resume: here the
  unplug cleared it within one sample (~1 s); the earlier plug did not.
* That is consistent with the EC re-programming the SMU (P-state limit / DYTC
  thermal mode) whenever the power source changes. The resume path leaves a
  stale limit (0x22) in the SMU; the next power-source event writes the
  correct value (0x20).
* Practical workaround, confirmed once: after a clamped resume, unplug (or
  plug/replug) the AC adapter. AC presence alone is not enough.
* PstateStatus reads 2 in both the clamped and the fast state, so it is not a
  useful indicator; the discriminator is MSR 0xc0010061 (0x22 vs 0x20).

In short words - this is not a Linux kernel bug - someone @Lenovo needs to fix BIOS for this laptop.

A simple workaround is to plug&unplug&plug AC power....

Anyone here to help ?

I can attach a lot of trace files to this BZ...

Checking with the FW team on if the fix for the P15v G3 got rolled out on the P16v G1 or if it got missed. I'm not able to tell from the internal ticket which makes me suspicious (I should have an EC version with the fix in it and I'm not finding that)

Internal ticket is LO-4725.

Mark