On 6/26/25 6:32 PM, Askar Safin wrote:
Hi. This commit:
#regzbot introduced: 1796f808e4bb2c074824dc32258ed1e719370cb3
caused a regression. Dell Precision 7780 often wakes up on its own from suspend.
Sometimes wake up happens immediately (i. e. within 7 seconds), sometimes it happens after, say, 30 minutes.
(The laptop comes with Ubuntu preinstalled, but I didn't test this bug on preinstalled Ubuntu)
That commit already caused a lot of other regressions on other laptops:
#regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cb786180dfb5258ff3111181b5e4ecb1d4a297b
#regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d63f11c02b8d3e54bdb65d8c309f73b7f474aec4
#regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a69982c37cd0586e6832268155349301b87f2e35
#regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=782eea0c89f7d071d6b56ecfa1b8b0c81164b9be
I will be available for testing in coming days, then I will switch to other things, and so will not be available for testing.
If you want more time, then, please, ask for it, i. e. say me something like "Please, be available for testing in more 10 days".
Here is config I used for testing:
https://zerobin.net/?5c4e4b8f6e7a6a0d#W35/IXYAxzjFyp7yP71V0EZ6jcF83HOWB/52ldl5jig=
In other words, this is config I used for bisecting. In other words, the bug reproduces
with this config on 1796f808, but doesn't reproduce on d86388c9.
This config was created using localmodconfig, so it is quite possible it will not boot on other computers.
Also, the bug reproduces on pretty standard Debian kernels, for example, on
http://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.12.32-amd64_6.12.32-1_amd64.deb
with standard Debian config.
Here is "bad" dmesg:
https://zerobin.net/?525f36df8d698fba#e3+DHsvv3Lsqmi91d1TqHx19mrilYNDR0bL8DbeNxw0=
I. e. this is dmesg generated during attempts to reproduce the bug on "bad" kernel, i. e. on 1796f808
with minimized config provided above.
And here is "good" dmesg:
https://zerobin.net/?09b26bfcfa523eff#zDMKsIGmfXBLgpml3qDjwW0NnclErstolYEjCMzmmsA=
I. e. it was generated the same way, but with d86388c9.
This is script I used for bisecting:
https://zerobin.net/?a2acfc92e5a33cc3#L7/Z0jY47FFFp7UJ1GPmbhmfrcMTr0zBZst82ubyDs8=
The script uses "rtcwake" to automatize bisecting. Note that the bug reproduces
not only with "rtcwake", but also with normal suspend initiated from GUI without any timer.
This bug causes "rtcwake" to wake up BEFORE specified time.
Bug sometimes reproduces and sometimes not, so script above makes multiple attempts.
The script writes some info to /dev/kmsg , and you may see its output in dmesg above.
If you need more info, ask me. But again: I will be available within some days and then not.
If you need more time, ask me for it.
Reverting commit 1796f808 on top of v6.12.32 causes the bug to disappear.
When I connect external wireless mouse via USB, then the bug becomes harder to reproduce,
so I did testing without anything connected to laptop (except for power source).
--
Askar Safin
https://types.pl/@safinaskar
In order to debug this a few helpful things to add to your script:
1) Set /sys/power/pm_debug_messages before starting
2) Capture the value of /sys/power/suspend_stats/last_hw_sleep
BTW - When a wireless mouse is connected via USB I /suspect/ you aren't
getting into hardware sleep state (or if your it's for not as long of a
duration). I'm not sure if that's a hint for this issue or not right
now. That's why I think capturing it might be helpful for this issue.
