https://bugs.kde.org/show_bug.cgi?id=496772
--- Comment #6 from redford <redf...@dragonsector.pl> --- (In reply to John Kizer from comment #5) > Ah - yep, the catch there is the number of layers, starting from hardware, > through firmware and down to userspace software, that all have to work in > sync (the rest of that Arch Wiki article on CPU frequency scaling has a lot > of good links and info if you want to dig really deeply on it!). The visible > interface you see in a desktop environment like KDE (or Windows, for that > matter) is the very surface layer, but if that surface layer tries to pass > along a command that isn't functioning properly at a lower layer, it just > won't work. I see, thanks! I submitted a report to Lenovo, I suspect it's related to the last BIOS/EC update. > (In an analogous way, our family purchased a laptop once - ironically, also > Lenovo - on which the pre-configured Windows installation couldn't put the > laptop to sleep. We came to find out that the Windows equivalent of > power-profiles-daemon was calling for the firmware to use a sleep state that > it didn't outright reject, but couldn't successfully set, so the machine > just hard-froze - we had to do some work in the Windows Terminal to force it > to only attempt certain sleep states) Heh, I once went through an ACPI issue on an old ThinkPad x230 running Xen, turned out to be a bug in Xen: https://old-list-archives.xen.org/archives/html/xen-changelog/2019-09/msg00301.html. The BIOS there is disabling NX by default, Xen forced it back on during boot, but forgot to do the same when waking from suspend and thus segfaulting when trying to use it. I hope this time I won't end up debugging Linux and ACPI tables, but we'll see :) > In this case, it might be helpful to check around with your device's model > number to see if there are any generally known power-state issues with the > device. You could also try booting from a live USB for another distribution, > like Ubuntu or Fedora, to see if they exhibit the same behavior - if not, > then it may be something that is funky in how your specific Arch setup has > come together, or in how power-profiles-daemon is interacting with it. > Fedora 41 (which comes in a very well-maintained KDE Spin), for example, > uses tuned instead of power-profiles-daemon, which might produce different > results. > > Best of luck! Thanks! I'll see what Lenovo says and probably debug this a bit myself. Will let you know if there's anything related to Powerdevil here. One thing which would be useful though, would be to indicate in the GUI that the battery conservation settings change failed - I see "org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getconservationmode failed "Battery conservation mode is not supported"" in the service logs, but the GUI showed that everything succeeded and it was quite confusing to me. -- You are receiving this mail because: You are watching all bug changes.
