[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



On Tue, 11 Nov 2025 13:44:23 +0100 Salvatore Bonaccorso wrote:

[...]
> On Wed, Nov 05, 2025 at 11:52:55PM +0100, Francesco Poli wrote:
[...]
> >  * if I enable VT-d, audio fails to work
> > 
> >  * if I disable VT-d, audio works correctly
[...]
> > Now I have some questions:
> > 
> >  - is disabling VT-d in the BIOS settings equivalent to booting with
> >    intel_iommu=off kernel parameter?
> 
> Yes, this result is equivalent.

OK, good to know.

> 
> >  - I thought that enabling VT-d was needed for QEMU in KVM mode, but I
> >    cannot verify it (starting 'kvm' seems to work, without any visible
> >    complaint): could you please tell me what I am missing, by disabling
> >    VT-d?
> 
> It depends on which use cases you have for the VMs. Do you need to
> passh through hardware?

Things like GPU pass-through?
Do I understand correctly that it requires at least two GPUs in the
box?
I only have the graphics integrated in the Intel CPU, hence, if GPU
pass-through indeed requires two GPUs, I am not going to need GPU
pass-through anytime soon... Probably I'll never use it on this box...

Is there any other relevant pass-through thing, besides GPU
pass-through? 

> Do you use nested virtualization?

VMs running within the VM which is running on the bare metal?
I have never used it. I don't know whether I will need it in the
future, but I guess I won't. At least, not in the short/medium term...

> 
> >  - does this additional information help in understanding the issue
> >    and, perhaps, in fixing it?
> 
> That is still the harder part :(.

I can imagine!   :-p

> We will have another meeting on
> wednesday and this bug will likely (unless we run out of time) be on
> the agenda/table again.

Thanks a lot, this is really appreciated.

> 
> We see more IOMMU related failures recently (when old HW is involved),
> so this might indeed be the way forward, tbh. But we will see tomorrow
> is someone has other input on the topic.

OK, looking forward to receiving further feedback.

As always, thank you so much for your kind assistance!   :-)


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Attachment: pgpv8p1Ma_q1x.pgp
Description: PGP signature


Reply to: