XPost: linux.debian.bugs.dist   
   From: boucek.lubos@protonmail.com   
      
   I am going to try this but it will take some time. I will let you know if I   
   encounter any issues.   
      
   Lubos   
      
      
   On Sunday, January 4th, 2026 at 06:35, Salvatore Bonaccorso  wrote:   
      
   >    
   >    
   > 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/stab   
   e/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)