Created attachment 306330 [details] kernel log with @kernel-vanilla/stable - 6.9.1-351 Kernel Log after wake from S3 Sleep - Thinkpad P1 Gen2 1. Please describe the problem: After waking up my Lenovo Thinkpad P1 Gen2 from the S3 sleep state, it shows an incorrect battery level. After a closer look at /sys/class/power_supply/BAT0/energy_now /sys/class/power_supply/BAT0/energy_full /sys/class/power_supply/BAT0/energy_full_design shows that energy_full is usually significantly higher than energy_full_design. After a reboot, the battery data is correct again until the next S3 sleep state. Sometimes it takes 2 sleep states until the battery values are read out incorrectly. Battery Readings after wake from S3 Sleep: test@fedora:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: Celxpert model: ! serial: 8472 power supply: yes updated: Fr 03 Mai 2024 17:28:37 (6 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: pending-charge warning-level: none energy: 37,3866 Wh energy-empty: 0 Wh energy-full: 453,584 Wh energy-full-design: 228,134 Wh energy-rate: 0 W voltage: 16,456 V charge-cycles: 230 percentage: 8% capacity: 100% icon-name: 'battery-caution-charging-symbolic' Battery Readings after Reboot: test@fedora:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: Celxpert model: 5B10V98091 serial: 2691 power supply: yes updated: Fr 03 Mai 2024 17:31:31 (6 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: pending-charge warning-level: none energy: 53,91 Wh energy-empty: 0 Wh energy-full: 67,81 Wh energy-full-design: 80,4 Wh energy-rate: 0 W voltage: 16,456 V charge-cycles: 230 percentage: 79% capacity: 84,3408% technology: lithium-polymer icon-name: 'battery-full-charging-symbolic' History (charge): 1714750266 79,000 pending-charge 1714750266 0,000 unknown History (rate): 1714750266 0,000 unknown Battery Readings after wake from S3 Sleep: test@fedora:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: % model: 5B10V980% serial: 9499 power supply: yes updated: Mo 13 Mai 2024 10:12:54 (5 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging warning-level: low energy: 56,88 Wh energy-empty: 0 Wh energy-full: 655,12 Wh energy-full-design: 80,4 Wh energy-rate: 9,106 W voltage: 16,089 V charge-cycles: N/A time to empty: 6,2 hours percentage: 8% capacity: 100% technology: lithium-polymer icon-name: 'battery-caution-symbolic' History (rate): 1715587974 9,106 discharging 1715587944 10,488 discharging 1715587914 9,922 discharging 1715587884 16,294 discharging Battery Readings after wake from S3 Sleep: test@fedora:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: Ce%')#$- model: 5B10V9)#$- serial: 11556 power supply: yes updated: Mi 15 Mai 2024 11:04:11 (26 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: pending-charge warning-level: none energy: 60,48 Wh energy-empty: 0 Wh energy-full: 102,16 Wh energy-full-design: 328,96 Wh energy-rate: 0 W voltage: 16,696 V charge-cycles: 65512 percentage: 59% capacity: 31,0554% icon-name: 'battery-good-charging-symbolic' History (charge): 1715763822 59,000 pending-charge 1715763820 100,000 fully-charged Battery Readings after wake from S3 Sleep: test@fedora:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: Celxpert model: 5B10V+$$. serial: 11812 power supply: yes updated: Do 23 Mai 2024 13:37:12 (2 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: fully-charged warning-level: none energy: 53,3069 Wh energy-empty: 0 Wh energy-full: 338,138 Wh energy-full-design: 1,06902 Wh energy-rate: 0 W voltage: 16,467 V charge-cycles: 235 percentage: 100% capacity: 100% technology: lithium-polymer icon-name: 'battery-full-charged-symbolic' History (charge): 1716464142 100,000 fully-charged 2. What is the Version-Release number of the kernel: Issue since Kernel 6.8 current Kernel: 6.8.10 Vanilla kernel tested as well under Fedora 40 Linux 6.9.1-351.vanilla.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 17 17:44:59 UTC 2024 x86_64 GNU/Linux Linux 6.10.0-0.rc0.20240524gt6d69b6c1.312.vanilla.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 24 05:51:24 UTC 2024 x86_64 GNU/Linux 3. Did it work previously? 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 : Before Kernel 6.8 no issues at all. I have tested Fedora 39 with Kernel 6.7.11, no Issue. Fedora 39 from Kernel 6.8.3 and the wrong battery reading started to appear. Fedora 40 is based on Kernel 6.8, so could not test Kernel lower than 6.8. To be certain that it is the kernel I have tested with other Linux distros, like Ubuntu 24.04 which is also based on Kernel 6.8. Same issue with Ubuntu with Kernel 6.8.0 and newer. In addition Vanilla kernels were tested Linux 6.9.1-351.vanilla.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 17 17:44:59 UTC 2024 x86_64 GNU/Linux Linux 6.10.0-0.rc0.20240524gt6d69b6c1.312.vanilla.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 24 05:51:24 UTC 2024 x86_64 GNU/Linux 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Reproduction is easy. Installation of Kernel 6.8.0 or newer. Putting Thinkpad P1 Gen2 to S3 Sleep and wake again from sleep. You will see wrong battery readings. Sometimes more than one sleep/wake cycle is necesarry to reproduce the issue. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 3rd party Kernel modules are used. Installed Fedora 39 from scratch -> No Issue Updated Kernel to 6.8 -> Issue of wrong battery reading after Wake from S3 Sleep 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.
This could be a problem in the ACPI code, a platform specific driver, or some other related code – which is why no developer might look into this. You might want to perform a bisection to find the cause (see https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html ), as the culprits author then has to look into the problem.
Thanks Thorsten for your feedback. Thanks to your reply I am already working on bisection. I hope this will help identifying the issue.
Created attachment 306369 [details] bisection log git bisect bad 5a5efdaffda5d23717d9117cf36cda9eafcf2fae # first bad commit: [5a5efdaffda5d23717d9117cf36cda9eafcf2fae] thermal: core: Resume thermal zones asynchronously
I have verified this. with reverted commit 5a5efdaffda5d23717d9117cf36cda9eafcf2fae Battery Status is find after S3 Sleep and Wake cycles To change the actual component, does anyone know the component of Product "drivers"?
I have compiled kernel 6.8.11 with reverted commit 5a5efdaffda5d23717d9117cf36cda9eafcf2fae. Battery Status works fine with reverted commit after S3 Sleep and Wake cycles.
(In reply to fhortner from comment #4) > To change the actual component, does anyone know the component of Product > "drivers"? Most likely nobody will care; bringing it to the list and the culprits author should do the trick (for the bystanders: that was done here: https://lore.kernel.org/all/435867b5-029b-419f-bb7f-2d4902c62556@leemhuis.info/)
Same issue here for my ThinkPad X1 Extreme (Gen 2). I hadn't seen this report yet and went through the bisection process and ended up at the same bad commit.
@slip Thanks for your confirmation. Could you also bring this to the mailing list. see Reply instructions at the bottom here: https://lore.kernel.org/all/435867b5-029b-419f-bb7f-2d4902c62556@leemhuis.info/ @Thorsten Could we somehow synchronise this bug with the mailinglist?
*** Bug 218915 has been marked as a duplicate of this bug. ***
(In reply to fhortner from comment #8) > Could you also bring this to the mailing list. Won't hurt, but there is no pressing need either for now; but if nothing happens in a day or two it's likely a wise move. > @Thorsten > Could we somehow synchronise this bug with the mailinglist? That's not easy (that's a longer story short). But you (and slip) could allow me to use your emails addresses in a reply, then we could let this ticket rest.
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #10) > But you (and slip) And Axel, too. > could allow me to use your emails addresses in a reply, > then we could let this ticket rest. And yes, that all not ideal, I know; with a bit of luck this will become easier in a few months.
(In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #10) > But you (and slip) could allow me to use your emails addresses in a reply, I am already in CC
> But you (and slip) could allow me to use your emails addresses in a reply, > then we could let this ticket rest. This works for me! Happy to keep it centralized.
Patch submitted: https://lore.kernel.org/linux-pm/3317718.44csPzL39Z@kreacher/
Patch introduced with Kernel 6.10.rc5 Patch added and available since Kernel 6.9.7 stable Thanks to Rafael and Greg