https://bugs.kde.org/show_bug.cgi?id=510992
--- Comment #27 from nyanpasu64 <[email protected]> --- Created attachment 186829 --> https://bugs.kde.org/attachment.cgi?id=186829&action=edit Shell script to enable /sys/power/wakeup_count and trigger a failed sleep. I've reproduced this bug without depending on KDE or wakeupsourcehelper. I have attached a shell script replicating wakeupsourcehelper's behavior. If you run `sudo ./badsleep.sh`, it reads and writes `/sys/power/wakeup_count`, then triggers a mem sleep with `/sys/power/state`. (sudo is needed to write to `/sys/power/wakeup_count` on Fedora.) This reproduces failed sleeps on my computer: - If I edit the script and comment out `echo $wakeup_count > /sys/power/wakeup_count`, the sleep succeeds, and waking the computer skips the lock screen and resumes where I left off. - If I run the script unaltered, the screen turns off and on, and the terminal outputs `./badsleep.sh: line 14: echo: write error: Device or resource busy` indicating the mem sleep failed. - If I run `sudo rmmod rtsx_pci_sdmmc` to disable the faulty module, the sleep succeeds, and waking the computer skips the lock screen and resumes where I left off. I get unclear behavior when reloading the module. If I have stacksnoop running, and run `sudo modprobe rtsx_pci_sdmmc` quickly followed by `sudo ./badsleep.sh`, sleep succeeds and I do not see a pm_wakeup_ws_event() call in stacksnoop. If I wait over ~5 seconds after modprobe, sleep fails from `pm_wakeup_ws_event()` as usual. In past boots, sleep would sometimes stop breaking altogether, but I don't know what causes it, nor if pm_wakeup_ws_event() gets called then. ---- Unfortunately I will probably not be able to report a kernel bug soon. - https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html says bug reports not tested on the latest mainline kernel may be rejected. - I currently have a Fedora 43 installation in my NUC, and tried adding COPRs for @kernel-vanilla/mainline and @kernel-vanilla/mainline-wo-mergew. - However all kernel updates since 6.16.12 do not get found by GRUB2, because dnf installs them to /boot/efi/$(cat /etc/machine-id)/ and indexes them in /boot/efi/loader/entries/, but the GRUB kernel (and `sudo grubby --info=ALL`) looks in /boot/loader/entries/ and loads kernels from /boot/. - https://discussion.fedoraproject.org/t/f39-kernels-fail-to-install-when-boot-efi-machineid-is-present/96086 suggested renaming /boot/efi/$(cat /etc/machine-id)/, but `sudo dnf reinstall kernel-core` would fail because the boot partition was full. If I remove the folder entirely, `sudo dnf reinstall kernel-core` recreates this folder again. -- You are receiving this mail because: You are watching all bug changes.
