Dear Maintainer, I am using Debian 13 on a Lenovo ThinkPad X13 Gen 6 AMD laptop. This laptop was released in 2025 and uses the AMD Ryzen AI 7 PRO 350 platform. Since updating to the 6.12.63+deb13-amd64 kernel, the system can no longer wake from suspend. If I close the lid of the laptop, leave it unattended for a while, or manually trigger a suspend, then the laptop will not wake. Nothing appears on the internal or external monitor, and neither the built-in keyboard/touchpad/buttons, nor an external keyboard or mouse, nor opening the lid, nor the power button can wake it from sleep. It is not clear if it is actually suspended or has just hung while trying to suspend, as the power button LED and ThinkPad logo LED never go out. If I revert to the 6.12.57+deb13-amd64 kernel, then the system has no problems waking from suspend. I don't know if it is in a "true" suspended state, because it doesn't have the characteristic pulsing of the ThinkPad logo LED that happens when suspending in Windows. However, the screen does go black, and the laptop disconnects from WiFi while suspended, so it is certainly achieving some of the expected behaviour. If there's anything I can do to help debug this, please let me know. I could build the kernel from source for example. Thanks!
Hi, It was helpfully pointed out to me that since this is a very new platform, it might be wise to try the newer backported kernel. I installed linux-image-amd64/trixie-backports and now I have 6.17.13. This kernel version seems to not usually have trouble resuming from suspend, and it also seems to enter a truer suspended state, as the power and ThinkPad LEDs now pulse when suspended, which wasn't the case with the older kernels.
Hello, That's great. Unless you intend to help identifying the commit responsible to fix your issue, I'd close this bug then. (If you want to help, can you please check for kernels on https://snapshot.debian.org and work out which one is the first working kernel.) Best regards Uwe
Hi, Thanks for that link, that should make it easier to track this down than I had feared. I'll try to do a binary search.
The complication probably comes later because you will identify that it was broken by a major version bump. Then we might ask you for something like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1125405#10 with the added difficulty that we're looking for a fix instead of a breakage (which isn't a big issue). :-D Best regards Uwe
Known points for bisection: 6.17.13-1 ✅ (true suspend) 6.12.63-1 ❌ (broken suspend) 6.12.57-1 ✅ (non-broken suspend) It seems there aren't any snapshots between 6.12.57-1 and 6.12.63-1, so I can't find out where this bug started. But I can download the kernel images to find out when the fix came. Bisection log: linux-image-6.16.3+deb13-amd64-unsigned 6.16.3-1~bpo13+1 ✅ (true suspend) linux-image-6.14-amd64-unsigned 6.14.3-1~exp1 ✅ (true suspend) linux-image-6.13-amd64-unsigned 6.13.7-1~exp1 ✅ (true suspend) linux-image-6.13-amd64-unsigned 6.13.2-1~exp1 ✅ (true suspend) linux-image-6.13-rc6-amd64-unsigned 6.13~rc6-1~exp1 ❌❌❌ (fails to boot to GDM, kernel panic'd once) linux-image-6.13-rc7-amd64-unsigned 6.13~rc7-1~exp1 ❌❌❌ (fails to boot to GDM) So it looks like 6.13.2 is the earliest snapshot available where suspend is fixed on this laptop. I hope that's helpful. I guess I can try to do a git bisect next if that's helpful?
Yes indeed. This would work as follows: a) clone source code and generate a suitable configuration git clone --signle-branch -b linux-6.13.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git cd linux-stable git checkout v6.13.2 cp /boot/config-$(uname -r) .config yes '' | make localmodconfig make savedefconfig mv defconfig arch/x86/configs/my_defconfig b) test v6.13.2 to confirm you have everything you need to compile and install a kernel and that it's good (as one would expect from your test of 6.13.2-1~exp1) make my_defconfig make -j $(nproc) bindeb-pkg ... install the resulting .deb package and confirm suspend is working c) Find an older broken one. A conservative choice is 6.12: git checkout v6.12 make my_defconfig make -j $(nproc) bindeb-pkg ... install the resulting .deb package 🤞 it boots fine and that suspend is broken. If it doesn't boot you have to find another version that boots but doesn't suspend. v6.13-rc1 or v6.13 might be versions to check. d) With a)-c) done, the bisection can start: git bisect start --term-new=fine --term-old=doesntsuspend v6.13.2 v6.12 (Use what ever version you found in c) instead of "v6.12" in the above command. Also "fine" and "doesntsuspend" are arbitrary terms, pick whatever you find suitable for you and use is accordingly in the steps afterwards.) Whenever you called `git bisect ...` git checks out a version of the kernel that you are supposed to test. To do so do: make my_defconfig make -j $(nproc) bindeb-pkg ... install and test If the kernel fails to boot or shows another problem that makes you unable to test if the kernel has the suspend problem run: git bisect skip If the kernel suspends and resumes fine (i.e. the problem is fixed) run: git bisect fine and if the suspend problem happens, run git bisect doesntsuspend . e) repeat d) until git reports to have found the first fine revision. Report back the output of `git bisect log` The things to pay attention for to are: - always select the just built kernel for booting. It won't always be the one the grub picks up as default. - Typically a system doesn't have enough space (in / and/or /boot) to be able to install all kernels needed during a bisection. All kernels that you tested can be uninstalled to make space for the next package. - In the end uninstall all kernels you built to not use these kernels for more than testing. If you have questions or hit problems, that's probably because my instructions don't consider all the corner cases you might hit. Don't hesitate to ask, by mail in reply to this bug or in the #debian-kernel irc channel. Thanks for your time and effort, Uwe