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

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

Bug#1113942: linux-image-6.16.3+deb14-amd64: Fails to suspend

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1113942: linux-image-6.16.3+deb14-amd64: Fails to suspend Uwe Kleine-König <u.kleine-koenig@baylibre.com> - 2025-09-15 09:30 +0200
    Bug#1113942: linux-image-6.16.3+deb14-amd64: Fails to suspend Uwe Kleine-König <u.kleine-koenig@baylibre.com> - 2025-09-18 08:50 +0200

#89275 — Bug#1113942: linux-image-6.16.3+deb14-amd64: Fails to suspend

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Thu, Sep 04, 2025 at 03:38:32PM +0200, Philipp Klaus Krause wrote:
> Package: src:linux
> Version: 6.16.3-1
> Severity: normal
> X-Debbugs-Cc: debian-amd64@lists.debian.org, pkk@spth.de
> User: debian-amd64@lists.debian.org
> Usertags: amd64
> 
> Dear Maintainer,
> 
> with Linux 6.16.3, my system (MSI Bravo Laptop, Ryzen 4800H, Radeon RX 5500M)
> fails to suspend. Suspend works with Linux 6.12.38.

So this happens reliably with a (so far) 100% reproduction rate?

> I'm reporting this on the system while running 6.12.38-1. Below You will find
> the relevant dmesg output from attemping to suspend using "systemctl suspend"
> on 6.16.3 and, for comparison, the dmesg output from suspending on 6.12.38.

There are some changes to the amdgpu driver in newer stable version for
6.16.x, but none of them looks very relevant to your problem.

Can you please bisect the problem using the kernel packages available at
https://snapshot.debian.org/package/linux/ to find the first affected
version?
(That is, pick a version between 6.12.38 (current newest good) and
6.16.3 (current oldest bad) and test that. Depending on the outcome
update your notion of "current newest good" or "current oldest bad" and
repeat until you find two consecutive packages where one is good and the
other is bad. If that sketch of the procedure is too sparse for you to
follow, please ask for more details.)

The likely outcome is that the first broken version is the first package
for a new major release. In that case the followup is likely to continue
bisecting using git on the mainline history. Instructions will follow
then.

In the end make sure to uninstall all the old kernel versions again.
This might also be necessary in the middle of the bisection process if
space in /boot runs out.

Best regards
Uwe

[toc] | [next] | [standalone]

#89312

[Multipart message — attachments visible in raw view] — view raw

[readded 1113942@bugs.debian.org to Cc:]

Hello Philipp,

On Mon, Sep 15, 2025 at 02:42:59PM +0200, Philipp Klaus Krause wrote:
> > Can you please bisect the problem using the kernel packages available at
> > https://snapshot.debian.org/package/linux/ to find the first affected
> > version?
> > (That is, pick a version between 6.12.38 (current newest good) and
> > 6.16.3 (current oldest bad) and test that. Depending on the outcome
> > update your notion of "current newest good" or "current oldest bad" and
> > repeat until you find two consecutive packages where one is good and the
> > other is bad. If that sketch of the procedure is too sparse for you to
> > follow, please ask for more details.)
> > 
> > The likely outcome is that the first broken version is the first package
> > for a new major release. In that case the followup is likely to continue
> > bisecting using git on the mainline history. Instructions will follow
> > then.
> > 
> > In the end make sure to uninstall all the old kernel versions again.
> > This might also be necessary in the middle of the bisection process if
> > space in /boot runs out.
> 
> Is there some howto for that? It has been more than a decade since I
> compiled a Linux kernel.

Another bug where I provided such a howto is #1109203, you can take a
look there if you want to know already now. You can also start with that
procedure without testing images at all. The cost is probably ~5 or so
more steps (involving a kernel compilation, so it takes some time), but
then you don't have to go through the hassle to check authenticity of
the packages from snapshot.d.o (or configure apt to do it for you).

> How can I try those kernels from the link you provided?

There is a generic description at https://snapshot.debian.org/. A
slightly easier (but formally unsafe) option is to just download the
packages and install them using dpkg.

> Installing the .deb packages and choosing the kernels in the grub boot menu
> gets me an error message "Fehler: Falsche Shim-Signatur". Do I need to
> disable Secure Boot? Will disabling Secure boot or switching it on again
> later require a reinstallation of Debian?

You don't need to disable Secure Boot, but doing that will simplify
things. I'm pretty sure you don't need to reinstall when switching, but
I'm unsure if it involves some bootloader fiddling.

With Secure Boot enabled you have to pick the test images from
https://snapshot.debian.org/package/linux-signed-amd64/. For booting
self-compiled images during the git bisection process later you have to
use your own signing key, see
https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key for the
details.

Best regards
Uwe

[toc] | [prev] | [standalone]

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

csiph-web