Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 2019129 [details] kernel log after resume with stuck low frequencies 1. Please describe the problem: My Thinkpad P16v gen1 laptop sometimes resumes with CPU frequency locked to 400 Mhz - 544 MHz range. Even when I put load on CPU, the frequency doesn't go above 544 MHz (while in normal case, I can easily see 4,5 GHz), and stay at 400 MHz during idle. The system is then slow and unresponsive, it's easy to spot. I have to reboot to "fix" the issue. This bug has already been seen by two different people on two different laptops (both Thinkpad P16v), so it's not some hardware issue with my exact device. It's probably common to (at least) all Thinkpad P16v laptops. When the system is stuck to low frequencies, I see this output from cpupower: $ sudo cpupower frequency-info analyzing CPU 14: driver: amd-pstate-epp CPUs which run at the same hardware frequency: 14 CPUs which need to have their frequency coordinated by software: 14 maximum transition latency: Cannot determine or is not supported. hardware limits: 400 MHz - 5.76 GHz available cpufreq governors: performance powersave current policy: frequency should be within 400 MHz and 5.76 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 544 MHz (asserted by call to kernel) boost state support: Supported: yes Active: yes AMD PSTATE Highest Performance: 220. Maximum Frequency: 5.76 GHz. AMD PSTATE Nominal Performance: 145. Nominal Frequency: 3.80 GHz. AMD PSTATE Lowest Non-linear Performance: 42. Lowest Non-linear Frequency: 1.10 GHz. AMD PSTATE Lowest Performance: 16. Lowest Frequency: 400 MHz. 2. What is the Version-Release number of the kernel: kernel-6.7.6-200.fc39.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 : This is a new laptop, I haven't used older kernels with it. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Unfortunately it's random. Suspend the laptop and resume it. In most cases, it works as expected, but sometimes, this bug occurs and only low CPU frequencies are available. 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``: I can test if needed, but it might take a long time before I'm able to say whether it's affected or not. 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. Kernel log is attached. The resume happened at 07:06:31 and then another one at 10:27:51. In both cases, the CPU freq was locked to 400-500MHz.
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.