Control: tags -1 + moreinfo Hi Stefan,
On Sat, Jun 13, 2026 at 03:09:57PM -0400, Stefan Monnier wrote: > Package: linux-image-amd64 > Version: 6.12.90-2 > Severity: normal > X-Debbugs-Cc: [email protected] > User: [email protected] > Usertags: amd64 > > Dear Maintainer, > > After a power failure a week ago, my desktop started to be unable to > resume from suspend. More specifically, it would reboot during the > resume. Not all the time, but about 50% of the time. > > At first I thought it was a hardware problem linked to the power > failure, but after some experimentation (which showed that hibernation > worked reliably), I tried to reboot into the previous 6.12.88 kernel, > and sure enough this one suspends&resumes just as reliably as before. > > The behavior I can see is quite limited: everything seems to work as > usual during suspend, which ends with the machine's light blinking and > the monitor going to sleep. When I hit a key on the keyboard, the > machine's light stops blinking (and stays on), then the monitor's light > stops blinking (but it remains dark at this stage, which is quite normal > because it takes a while for it to start displaying a picture), and > after a few more seconds sometimes the system wakes up normally, but > other times (about 50% of the time) the keyboard's "num lock" led turns > on (which I interpret to mean that the machine has started rebooting) > and after a few more seconds the screen shows the BIOS's > booting sequence. > > This machine has been running Debian stable and doing suspend/resume > sequences for the last 10 years without much trouble (beside > occasionally needing me to disconnect and reconnect the USB hub on which > the keyboard is connected), so I'm hopeful that it's a minor > regression that will be addressed easily. As you have a procedure to name the behaviour happening, can you please bisect the changes between 6.12.88 and 6.12.90 so we can identify the culprit and see if it is either a known problem upstream or make an upstream report. Doing so will involve compiling and testing a couple of kernels. git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git cd linux-stable git checkout v6.12.88 cp /boot/config-$(uname -r) .config yes '' | make localmodconfig make savedefconfig mv defconfig arch/x86/configs/my_defconfig # test 6.12.88 to ensure this is "good" make my_defconfig make -j $(nproc) bindeb-pkg ... install the resulting .deb package and confirm problem does not exist # test 6.12.90 to ensure this is "bad" git checkout v6.12.90 make my_defconfig make -j $(nproc) bindeb-pkg ... install the resulting .deb package and confirm problem exists. With that confirmed, the bisection can start: git bisect start git bisect good v6.12.88 git bisect bad v6.12.90 In each bisection step git checks out a state between the oldest known-bad and the newest known-good commit. In each step test using: make my_defconfig make -j $(nproc) bindeb-pkg ... install, verify if problem exists and if the problem is hit run: git bisect bad and if the problem doesn't trigger run: git bisect good . Please pay attention to always select the just built kernel for booting, it won't always be the default kernel picked up by grub. Iterate until git announces to have identified the first bad commit. Then provide the output of git bisect log In the course of the bisection you might have to uninstall previous kernels again to not exhaust the disk space in /boot. Also in the end uninstall all self-built kernels again. Regards, Salvatore
