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.


=== Stefan

Hi Stefan,

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

Good idea.  It's not fully deterministic (seemed to reboot more often
with higher uptime), so it will take some time.  Will let you know how
it goes.


=== Stefan