Bug 2266265
| Summary: | Thinkpad P16v sometimes resumes with CPU frequency locked to 400-500 MHz | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral (Red Hat) <kparal> | ||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | rawhide | CC: | acaringi, adscvr, agk, airlied, alciregi, bskeggs, cevich, crempel, dmoore, dphillip, hdegoede, hpa, jarod, jbilling, jeckersb, josef, jsaucier, kernel-maint, khowell, leonardi, linville, lmeyer, masami256, mchehab, mpearson, nchakrab, nixuser, plautrba, pragazzi, pstourac, ptalbert, ryasharz, saroy, steved, vcojot, zkabelac | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | Type: | Bug | |||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 2184978 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Kamil Páral (Red Hat)
2024-02-27 11:36:49 UTC
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. |