[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1112627: linux-image-6.16.3+deb14-amd64: Intel audio no longer works: DMAR: [DMA Write NO_PASID] Request device [00:1b.0] ... non-zero reserved fields in PTE



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/git/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


Reply to: