Subject: linux-image-6.12.96+deb13-amd64: S3 (deep) suspend powers the machine off instead of suspending; 6.12.95 unaffected

Package: linux-image-6.12.96+deb13-amd64
Version: 6.12.96-1
Severity: important

Since upgrading to 6.12.96-1 from trixie-security, closing the lid powers
the machine off completely instead of suspending. Not a failed resume, not a
hang: the machine is fully off, and pressing power gives a cold boot with a
dirty filesystem and journal replay. Unsaved work is lost.

6.12.95-1 on identical hardware and config does not do this. It is still
installed here and still works.

Reproducer:

  $ cat /sys/power/mem_sleep
  s2idle [deep]
  $ sudo rtcwake -m mem -s 30

Machine powers off. Same result from closing the lid or from
systemctl suspend. 3 for 3 on 6.12.96.

The journal ends mid-suspend with no resume and no panic:

  systemd-sleep[2973]: Performing sleep operation 'suspend'...
  kernel: PM: suspend entry (deep)
  <end of boot>

No "PM: suspend exit". Nothing in /sys/fs/pstore. On two of the three
failures the "PM: suspend entry (deep)" line never made it to disk at all,
which I read as power being cut before the journal could flush.

Counting entry/exit pairs across boots on this machine:

  kernel     deep    s2idle   resumes
  6.12.95    1987    1282     3269      (entries and exits match exactly)
  6.12.96       3       2        2      (all 3 deep attempts lost the machine)

The 6.12.95 numbers are high because I had been running suspend stress loops
while chasing an unrelated brcmfmac problem. Every one of those 3269 cycles
resumed. The kernel upgrade is the only change between the working and
broken boots.

Workaround: mem_sleep_default=s2idle on the kernel command line. s2idle
suspends and resumes reliably on 6.12.96, so whatever broke is specific to
the S3 path. Costs battery on this hardware, but it beats losing the session.

Ruled out:

- Not systemd. Suspend gets past systemd-sleep and into the kernel's S3
  path before dying, so this is not systemd/systemd#38337.
- Not config. No changes to logind.conf, sleep.conf, or /etc/default/grub
  between the last working boot and the first broken one.
- Not firmware. No BIOS update; 1.13.0 from 2020 throughout.

Timeline: 6.12.96-1 installed 2026-07-21, first booted 2026-07-26. The delay
is why it initially looked unrelated to the upgrade.

Hi

Can you please bisect the changes between 6.12.95 and 6.12.96 to
identify the breaking change?

Regards,
Salvatore

Hi,

Okay. If you want to give it a try still here are the instrucitons on
how to bisect the changes between 6.12.95 and 6.12.96 to identify the
problematic commit:

    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.95
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

    # test 6.12.95 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.96 to ensure this is "bad"
    git checkout v6.12.96
    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.95
    git bisect bad v6.12.96

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