XPost: linux.debian.bugs.dist   
   From: carnil@debian.org   
      
   Control: tags -1 + moreinfo   
      
   Hi   
      
   On Sun, Jan 04, 2026 at 12:49:13AM +0000, LuboÅ¡ BouÄ   
   ek wrote:   
   > With this kernel:   
   >   
   > $ uname -r   
   > 6.17.13+deb13-amd64   
   >   
   > The laptop seems to suspend correctly, thanks!   
      
   Ok that are great news.   
      
   Can you do further debugging on this issue? I see three major steps,   
   each in case of debugging "success".   
      
   - narrow down more the affected range of Debian versions where the   
     issue got fixed.   
   - Bisect the upstream changes to identify a fixing commit   
   - Check if the commit can be backported to 6.12.y and resolving the   
     issue.   
      
   I will outline only the first two first. So between 6.12.57-1 and   
   6.17.13-1 there are a couple of linux uploads happened:   
      
   6.17.13-1   
   6.17.13-1~bpo13+1   
   6.17.12-1   
   6.17.11-1   
   6.17.10-1   
   6.17.9-1   
   6.17.8-1   
   6.17.8-1~bpo13+1   
   6.17.7-2   
   6.17.7-1   
   6.17.6-1   
   6.17.5-1~exp1   
   6.17.2-1~exp1   
   6.16.12-2   
   6.16.12-1   
   6.16.12-1~bpo13+1   
   6.16.11-1   
   6.16.10-1   
   6.16.9-1   
   6.16.8-1   
   6.16.7-1   
   6.16.6-1   
   6.16.5-1   
   6.16.3-1   
   6.16.3-1~bpo13+1   
   6.16.1-1~exp1   
   6.16-1~exp1   
   6.16~rc7-1~exp1   
   6.15.6-1~exp1   
   6.15.5-1~exp1   
   6.15.4-1~exp1   
   6.15.3-1~exp1   
   6.15.2-1~exp1   
   6.15.1-1~exp1   
   6.15-1~exp1   
   6.15~rc7-1~exp1   
   6.14.6-1~exp1   
   6.14.5-1~exp1   
   6.14.3-1~exp1   
   6.13.11-1~exp1   
   6.13.10-1~exp1   
   6.13.9-1~exp1   
   6.13.8-1~exp1   
   6.13.7-1~exp1   
   6.13.6-1~exp1   
   6.13.5-1~exp1   
   6.13.4-1~exp1   
   6.13.3-1~exp1   
   6.13.2-1~exp1   
   6.13~rc7-1~exp1   
   6.13~rc6-1~exp1   
   6.12.63-1   
   6.12.57-1   
      
   From https://snapshot.debian.org/ you can fetch earlier and seen   
   uploads.so by querying   
   https://snapshot.debian.org/package/linux-signed-amd64/ you can get   
   earlier linux-image packages.   
      
   The idea would be to now do a "manual" bisect of those changes   
   identifying at least a major version range where things changes.   
      
   Assume you found that, by first searching and testing the major   
   version bumps that 6.13~rc7-1~exp1 exposes the problem but   
   6.14.3-1~exp1 will not anymore.   
      
   The next step would be to test the equivalent upstream versions and   
   check that this still holds true and then start the bisection. This   
   can be done as follows, again remember with the hypotetical above   
   versions (adapt as needed), and it would involve compiling and testing   
   a few kernels:   
      
       git clone https://git.kernel.org/pub/scm/linux/kernel/git/st   
   ble/linux-stable.git   
       cd linux-stable   
       git checkout v6.14.3   
       cp /boot/config-$(uname -r) .config   
       yes '' | make localmodconfig   
       make savedefconfig   
       mv defconfig arch/x86/configs/my_defconfig   
      
       # test 6.14.3 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.13~rc7 to ensure this is "bad"   
       git checkout v6.13-rc7   
       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 --term-new=fixed --term-old=broken   
       git bisect fixed v6.14.3   
       git bisect broken v6.13-rc7   
      
   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, try to boot / verify if problem exists   
      
   and if the problem is hit run:   
      
       git bisect broken   
      
   and if the problem doesn't trigger run:   
      
       git bisect fixed   
      
   . 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 'fixed'   
   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.   
      
   Can you please do this bisect?   
      
   Regards,   
   Salvatore   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)