1. Please describe the problem: I noticed that since the upgrade to Kernel 6.8 (6.8.4, and 6.8.5), there is something wrong with power management. Sometimes /sys/class/power_supply/BAT0/power_now is no longer present. Instead I see a /sys/class/power_supply/BAT0/current_now. In addition, the power reporting with both 'acpi -b' and via the KDE widget is incorrect. Sometimes it show 100% charged, sometimes it show the battery as almost empty. After a reboot everything is back to normal. The power_now file is back, and battery reporting is correct again. 2. What is the Version-Release number of the kernel: 6.8.4 and 6.8.5. This all works fine with kerbel 6.7.11. 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 : Yes. With kernel 6.7.11. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: - Check for the existence /sys/class/power_supply/BAT0/power_now, check battery status with acpi b - Suspend the Laptop - Wait for a few hours - seems to only happen after a while. - Resume - Notice that power_now is gone, battery status is incorrect - Reboot. - Notice that power_now is back, battery status is correctly reported. 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 cannot easily test this. 6. Are you running any modules that not shipped with directly Fedora's kernel?: Yes, the NVidia kernel drivers from RPM fusion. These are also present when it works with kernel 6.7.11, though. 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. I have started to shutdown instead of suspending. I Will attach the logs when I see this the next time. Additional information: This is on a Lenovo X1 Extreme Gen2 Laptop. I notice there are various power management related changes in Kernel 6.8. I looked a Bugzilla on kernel.org, but it was strongly suggested to file a bug with the distribution instead. Reproducible: Always
Update: Happens when suspended with the power adapter connected (no need to wait between suspend and resume).
Created attachment 2027045 [details] dmesg output dmesg taken right a resume that shows the problem.
Still happens with Kernel 6.8.6. For now I switched back to Kernel 6.7.11, as suspend/resume is useless for me until this is fixed.
One more addition piece of information: cat /sys/class/power_supply/BAT0/uevent seems to return some garbage data when this happens: POWER_SUPPLY_NAME=BAT0 POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_STATUS=Not charging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-poly POWER_SUPPLY_CYCLE_COUNT=64 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=7680000 POWER_SUPPLY_VOLTAGE_NOW=16817000 POWER_SUPPLY_POWER_NOW=0 POWER_SUPPLY_ENERGY_FULL_DESIGN=80400000 POWER_SUPPLY_ENERGY_FULL=167090000 POWER_SUPPLY_ENERGY_NOW=68430000 POWER_SUPPLY_CAPACITY=40 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_MODEL_NAME=5B10V98091 POWER_SUPPLY_MANUFACTURER=Celxpe� OWER_SUPPLY_SERIAL_NUMBER= 8220 Compared to after a reboot and no suspend/resume cycle: POWER_SUPPLY_NAME=BAT0 POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_STATUS=Not charging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-poly POWER_SUPPLY_CYCLE_COUNT=64 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=15360000 POWER_SUPPLY_VOLTAGE_NOW=16801000 POWER_SUPPLY_POWER_NOW=0 POWER_SUPPLY_ENERGY_FULL_DESIGN=80400000 POWER_SUPPLY_ENERGY_FULL=72370000 POWER_SUPPLY_ENERGY_NOW=68150000 POWER_SUPPLY_CAPACITY=94 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_MODEL_NAME=5B10V98091 POWER_SUPPLY_MANUFACTURER=Celxpert POWER_SUPPLY_SERIAL_NUMBER= 2988 Notice the garbage in the manufacturer value and that the serial number changes. And mentioned before, sometime CURRENT_NOW is shows instead of POWER_NOW (not in this case, though) So potentially this is some buffer overrun, which would be serious. Looking at the 6.8 git history I see some changes related to strncpy, but I had no time to track it down. Anything else I can provide? Is this the right avenue, or should I report on Kernel.org? This is clearly something that broke with Kernel 6.8.
Still occurring reliably with 6.8.7. (Again last Kernel that did not have this problem was 6.7.11) I'll stop now until there's a response here.
Still happening with 6.8.8 and 6.8.9. (and still not happening with 6.7.11) Easy instruction to repro: Suspend, immediately resume, notice that battery reporting is incorrect, reboot, notice the battert status is correctly displayed again. If I'm the only one, feel free to close.
I'm seeing similar [perhaps the same issue] on a Thinkpad P1 Gen2 [which should be similar to X1 Extreme Gen2] The battery could be fully charged - but on resume from suspend it can show arbitrary value - like 2% [and force a shutdown] - or 7% or such. after suspend/resume $ cat /sys/class/power_supply/BAT0/uevent <snp> POWER_SUPPLY_MANUFACTURER=Celx��'!$ POWER_SUPPLY_SERIAL_NUMBER= 36 vs before suspend/resume POWER_SUPPLY_MANUFACTURER=Celxpert POWER_SUPPLY_SERIAL_NUMBER= 4540 Currently on F40 with: 6.9.0-64.fc41.x86_64
Can confirm kernel-6.7.12-200.fc39.x86_64 works (so far) Also note -I use the default nouveau driver - (i.e not "NVidia kernel drivers")
I'm glad I am not the only one. FWIW, still happening with 6.8.10: $ uname -a Linux think 6.8.10-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 17 21:20:15 UTC 2024 x86_64 GNU/Linux $ cat /sys/class/power_supply/BAT0/uevent POWER_SUPPLY_NAME=BAT0 POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_STATUS=Not charging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_TECHNOLOGY=Li-poly POWER_SUPPLY_CYCLE_COUNT=32790 POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11008000 POWER_SUPPLY_VOLTAGE_NOW=16719000 POWER_SUPPLY_POWER_NOW=0 POWER_SUPPLY_ENERGY_FULL_DESIGN=80400000 POWER_SUPPLY_ENERGY_FULL=1030000 POWER_SUPPLY_ENERGY_NOW=66500000 POWER_SUPPLY_CAPACITY=6456 POWER_SUPPLY_CAPACITY_LEVEL=Normal POWER_SUPPLY_MODEL_NAME=5B10V98091 POWER_SUPPLY_MANUFACTURER=Celxp��▒�� POWER_SUPPLY_SERIAL_NUMBER= 7962 Note the garbled manufacturer and the clearly incorrect energy full.
$ uname -a Linux p1 6.10.0-0.rc1.20240531git4a4be1ad3a6e.21.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 31 13:39:24 UTC 2024 x86_64 GNU/Linux $ cat /sys/class/power_supply/BAT0/uevent <snip> POWER_SUPPLY_MANUFACTURER=Celxp��7,.9&(�� POWER_SUPPLY_SERIAL_NUMBER=14638 i.e still broken for me [with the latest 6.10-rc]
Thanks Satish, I don't think we are going to get a response here. Should we report this to the Kernel Mailing list instead? (They'd probably want us to build our own Kernel in that case)
It's a real issue. See: https://lore.kernel.org/linux-kernel/CAJZ5v0hcX0JAMBA+EVZURDH1BTQ2zL-W_4BjSx0a=1oRaR90ug@mail.gmail.com/T/ So looks like it might get fixed with 6.8.12.
https://lwn.net/Articles/979441/ Linux 6.10-rc5 thermal: core: Change PM notifier priority to the minimum 6.10.0-0.rc5.43.fc41.x86_64 - with this fix, works for me. [tried a few suspend/resume cycles] https://koji.fedoraproject.org/koji/buildinfo?buildID=2478259
https://lwn.net/Articles/979848/ Linux 6.9.7 thermal: core: Change PM notifier priority to the minimum i.e kernel-6.9.7 should also work. I'm still stuck at kernel-6.7.12-200.fc39.x86_64 due to https://bugzilla.redhat.com/show_bug.cgi?id=2274749
Ok... Fixed in 6.9.7 ... Closing. If I may... This was reported, discussed, patched, and fixed upstream, while just stayed unacknowledged in "NEW" here. I realize I am not a paying customer - at least not for my personal devices - but at least an acknowledgement would have been nice.