Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #92993 > unrolled thread

Bug#1139942: linux-image-amd64: Desktop reboots upon resume from suspend

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1139942: linux-image-amd64: Desktop reboots upon resume from suspend Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-13 21:20 +0200
    Processed: Re: Bug#1139942: linux-image-amd64: Desktop reboots  upon resume from suspend "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-06-17 16:00 +0200
    Bug#1139942: linux-image-amd64: Desktop reboots upon resume from suspend Salvatore Bonaccorso <carnil@debian.org> - 2026-06-17 16:00 +0200
      Bug#1139942: linux-image-amd64: Desktop reboots upon resume from suspend Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-17 17:20 +0200

#92993 — Bug#1139942: linux-image-amd64: Desktop reboots upon resume from suspend

Package: linux-image-amd64
Version: 6.12.90-2
Severity: normal
X-Debbugs-Cc: debian-amd64@lists.debian.org
User: debian-amd64@lists.debian.org
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.


=== Stefan


-- System Information:
Debian Release: 13.5
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.88+deb13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-amd64 depends on:
pn  linux-image-6.12.90+deb13.1-amd64  <none>

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#93017 — Processed: Re: Bug#1139942: linux-image-amd64: Desktop reboots upon resume from suspend

Processing control commands:

> tags -1 + moreinfo
Bug #1139942 [src:linux] linux-image-amd64: Desktop reboots upon resume from suspend
Added tag(s) moreinfo.

-- 
1139942: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1139942
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#93019

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: debian-amd64@lists.debian.org
> User: debian-amd64@lists.debian.org
> 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

[toc] | [prev] | [next] | [standalone]

#93022

> 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.

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web