XPost: linux.debian.bugs.dist   
   From: carnil@debian.org   
      
   Control: tags -1 + moreinfo   
      
   Hi Francesco,   
      
   On Sat, Oct 11, 2025 at 06:50:06PM +0200, Francesco Poli wrote:   
   > On Sat, 11 Oct 2025 17:20:36 +0200 Salvatore Bonaccorso wrote:   
   >   
   > > Hi Francesco,   
   > >   
   > > Sorry the delay, busy with other things.   
   >   
   > No problem, it can happen...   
   >   
   > >   
   > > On Sun, Oct 05, 2025 at 09:19:07PM +0200, Francesco Poli wrote:   
   > [...]   
   > > > How do I use gcc-14 to build the Linux kernel?   
   > > >   
   > > > Is   
   > > >   
   > > >   $ CC=gcc-14 make -j 2 bindeb-pkg   
   > > >   
   > > > enough?   
   > >   
   > > Pass it actually to make as argument, so:   
   > >   
   > > make CC=gcc-14 -j 2 bindeb-pkg   
   > >   
   > > should do the trick.   
   >   
   > Yes, I searched the web and figured out by myself.   
   > I tried to do so (by passing CC=gcc-14 as argument to each and every   
   > 'make' command, since I was not sure whether it was need for   
   > configuration steps too) and it successfully built .deb packages for   
   > v6.12   
   >   
   > >   
   > > Let me know if that works to get your bisect running.   
   >   
   > Well, I also built and tested v6.13-rc6 and found an interesting and   
   > unexpected result: v6.13-rc6 is "good", too!!!   
   >   
   > Since I could not believe my eyes (well, actually, my ears), I again   
   > installed and tested 6.13~rc6-1~exp1 from snapshot.debian.org: it is   
   > "bad"!   
   >   
   >   
   > So, let's summarize the situation:   
   >   
   >  • if I install Debian kernels from snapshot.debian.org, I get the   
   >    following results   
   >   
   >      6.13~rc6-1~exp1    BAD   
   >      6.12.43-1          good   
   >      6.12.41-1          good   
   >      6.12.38-1          good   
   >   
   >  • if I build upstream kernels from the git repository, I get the   
   >    following results   
   >   
   >      # aptitude install flex bison   
   >      # aptitude install bc libelf-dev libssl-dev pahole   
   >   
   >      $ git clone https://git.kernel.org/pub/scm/linux/kernel/g   
   t/stable/linux-stable.git   
   >      $ cd linux-stable   
   >      $ git checkout v6.12   
   >      $ uname -r   
   >      6.12.38+deb13-amd64   
   >      $ cp /boot/config-$(uname -r) .config   
   >      $ yes '' | make CC=gcc-14 localmodconfig   
   >      $ make CC=gcc-14 savedefconfig   
   >      $ mv defconfig arch/x86/configs/my_defconfig   
   >   
   >      $ make CC=gcc-14 my_defconfig   
   >      $ make CC=gcc-14 -j 3 bindeb-pkg   
   >      ---------> v6.12 is good   
   >   
   >      $ git checkout v6.13-rc6   
   >      $ make CC=gcc-14 my_defconfig   
   >      $ make CC=gcc-14 -j 4 bindeb-pkg   
   >      ---------> v6.13-rc6 is good (which is unexpected!)   
   >   
   >   
   >   
   > What should we deduce from this unexpected result?   
   >   
   > Could it be that I built v6.13-rc6 with the '.config' file copied from   
   > '/boot/config-6.12.38+deb13-amd64' ?   
   > Should I try with the '.config' file copied from   
   > '/boot/config-6.16.9+deb14-amd64', instead?   
   >   
   > Or could the issue be in one of the Debian patches (that create source   
   > differences between the Debian kernel   
   > 'linux-image-6.13-rc6-amd64-unsigned' and the upstream kernel   
   > 'linux-image-6.13.0-rc6_6.13.0-rc6-5_amd64.deb', that I rebuilt on my   
   > own)?   
   >   
   > Anything else?   
   >   
   >   
   > What do you suggest to do, next?   
      
   The suspsect is that you see difference as you end in the self   
   compiled kernel without enabled IOMMU. (Background; The Debian config   
   has CONFIG_INTEL_IOMMU_DEFAULT_ON_INTGPU_OFF=y, ntoably this option   
   does not exist in upstream, so you end with   
   CONFIG_INTEL_IOMMU_DEFAULT_ON not set only and see the difference.   
   (if you want to look up what I'm talking, this is   
   features/x86/intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch   
   in the source).   
      
   before we might suggest you need to use the workaround to disable   
   iommu, can you please now test the *selfcompiled* v6.13-rc6 with IOMMU   
   enabled, by booting it with the kernel command line argument   
   intel_iommu=on. I expect you will see then the problem in same way.   
      
   Regards,   
   Salvatore   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)