Control: tags -1 + moreinfo Hi
On Sun, Jul 26, 2026 at 08:27:24PM -0600, chrisbrasington wrote: > Package: src:linux > Version: 6.12.96-1 > Severity: important > X-Debbugs-Cc: [email protected], [email protected] > User: [email protected] > Usertags: amd64 > > 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. Can you please bisect the changes between 6.12.95 and 6.12.96 to identify the breaking change? Regards, Salvatore
