Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1260228 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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 Salvatore Bonaccorso <carnil@debian.org> - 2025-09-06 14:00 +0200
    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 Francesco Poli <invernomuto@paranoici.org> - 2025-09-07 13:20 +0200
      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 Francesco Poli <invernomuto@paranoici.org> - 2025-09-29 23:10 +0200
        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 Francesco Poli <invernomuto@paranoici.org> - 2025-10-05 18:50 +0200
          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 Francesco Poli <invernomuto@paranoici.org> - 2025-10-05 21:30 +0200
            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 Salvatore Bonaccorso <carnil@debian.org> - 2025-10-11 17:30 +0200
              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 Francesco Poli <invernomuto@paranoici.org> - 2025-10-11 19:00 +0200
                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 Salvatore Bonaccorso <carnil@debian.org> - 2025-10-17 15:50 +0200
                  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 Francesco Poli <invernomuto@paranoici.org> - 2025-10-18 13:20 +0200
                    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 Salvatore Bonaccorso <carnil@debian.org> - 2025-10-25 17:00 +0200
                      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 Francesco Poli <invernomuto@paranoici.org> - 2025-10-25 17:40 +0200
                        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 Salvatore Bonaccorso <carnil@debian.org> - 2025-10-26 14:10 +0100
                      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 Francesco Poli <invernomuto@paranoici.org> - 2025-10-26 23:40 +0100
                        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 Francesco Poli <invernomuto@paranoici.org> - 2025-11-06 00:00 +0100
                          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 Salvatore Bonaccorso <carnil@debian.org> - 2025-11-11 13:50 +0100
                            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 Francesco Poli <invernomuto@paranoici.org> - 2025-11-12 22:50 +0100
                              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 Salvatore Bonaccorso <carnil@debian.org> - 2025-11-16 17:50 +0100
                                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 Francesco Poli <invernomuto@paranoici.org> - 2025-11-24 23:40 +0100
                                  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 Salvatore Bonaccorso <carnil@debian.org> - 2025-11-26 08:50 +0100

#1260228 — 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 upstream

On Sun, Aug 31, 2025 at 02:43:30PM +0200, Francesco Poli (wintermute) wrote:
> Package: src:linux
> Version: 6.16.3-1
> Severity: important
> X-Debbugs-Cc: debian-amd64@lists.debian.org, invernomuto@paranoici.org
> User: debian-amd64@lists.debian.org
> Usertags: amd64
> 
> Hello!
> 
> I've just upgraded linux-image-amd64 and rebooted to
> linux-image-6.16.3+deb14-amd64, to find a very bad surprise:
> Intel integrated audio (device 00:1b.0, see the PCI list) no longer works.
> 
> Everything looks normal: alsamixer shows the usual controls (nothing relevant
> was found to be accidentally muted) for the usual sound card (HDA Intel PCH);
> jackd starts as usual; audacious starts as usual and plays music as usual.
> 
> But...
> 
> But nothing can be heard from the speakers and /var/log/kern.log is
> filled with the following error messages (that repeat once every 5 s):
> 
> kernel: dmar_fault: 19382 callbacks suppressed
> kernel: DMAR: DRHD: handling fault status reg 3
> kernel: DMAR: [DMA Write NO_PASID] Request device [00:1b.0] fault addr 0xffa02000 [fault reason 0x0c] non-zero reserved fields in PTE
> kernel: DMAR: DRHD: handling fault status reg 3
> kernel: DMAR: [DMA Write NO_PASID] Request device [00:1b.0] fault addr 0xffa02000 [fault reason 0x0c] non-zero reserved fields in PTE
> kernel: DMAR: DRHD: handling fault status reg 3
> kernel: DMAR: [DMA Write NO_PASID] Request device [00:1b.0] fault addr 0xffa02000 [fault reason 0x0c] non-zero reserved fields in PTE
> kernel: DMAR: DRHD: handling fault status reg 3
> 
> 
> Rebooting with linux-image-6.12.38+deb13-amd64 makes everything work
> again.
> 
> The error messages look similar to the ones quoted in a comment to
> one [upstream bug] report, however that comment refers to Linux kernel
> version 6.12.23, while I only see this issue after upgrading from
> version 6.12.38 to version 6.16.3 ...
> 
> [upstream bug]: <https://bugzilla.kernel.org/show_bug.cgi?id=215919#c6>
> 
> 
> What am I doing wrong?
> Please forward my bug report upstream and incorporate a fix as soon as
> possible.
> 
> Thanks for any help you may provide!

So while this is IOMMU related, it *still* might be broken firmware
and you can try if disabling IOMMU "resolves" the issue. Still there
is indication that this might be a real regression from 6.12 to 6.16.
So additionally to the above tests I would like to ask you  to do the
following:

Between your last "good" Debian revision (6.12.38-1) and your first
noticed "bad' revison (6.16.3-1) there were a couple of experimental
uploads:

	6.16.3-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.43-1
	6.12.41-1
	6.12.38-1

Via snapshot.debian.org service, do a manual search of
linux-image-amd64 package an determine a close a possible range of
still "good" and first "bad" kernel revision. I would start here to
test first the major upstream bumps as we do not know if the potential
rgression was as well introduced backported in the back then stable
series. So you might wnant to test first 6.13~rc6-1~exp1, test,
depending on the result go up to the 6.14.y versions, test, if
behavoour changes, then search between the 6.13 and 6.14.y versions
oteherwise move the 6.15.y versions and search similarly.

Let's say you find hipotetically now you found that all up to
6.14.6-1~exp1 were good and breaks with testing 6.15~rc7-1~exp1.

(Note if the situation is not very clear and you jump between results
while moving, then it's better to directly bisect v6.12 to 6.16.3)

But let's assume we have all up to 6.14.6-1~exp1 are good and
6.15~rc7-1~exp1 is bad.

It would be great if you could bisect the problem. That would involve
compiling and testing a few kernels:

        git clone ttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
        cd linux-stable
        git checkout v6.14
        cp /boot/config-$(uname -r) .config
        yes '' | make localmodconfig
        make savedefconfig
        mv defconfig arch/x86/configs/my_defconfig

        # test 6.14 to ensure this is "good"
        make my_defconfig
        make -j $(nproc) bindeb-pkg
        ... install the resulting .deb package and confirm it successfully boots / problem does not exist

        # test 6.15-rc7 to ensure this is "bad"
        git checkout v6.15-rc7
        make my_defconfig
        make -j $(nproc) bindeb-pkg
        ... install the resulting .deb package and confirm it fails to boot / problem exists

With that confirmed, the bisection can start:
 
        git bisect start
	git bisect good v6.14
	git bisect bad v6.15-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 bad
 
and if the problem doesn't trigger run:
 
    git bisect good
 
. 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 bad 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.

Once we have a clear bad commit we might we can douple check. If the
problem seems clear we can take it from here, if not we might ask to
you to send now the report to upstream (if needed helping how to
determine the correct recipients, ideally keeping our bug in the
loop).

Let's see how this goes. Let us know if you struggle with some steps.

Again, if the first search via Debian packages is unhelpful do a git
bisect directly with upstream version, then it the bigger range of
versions you have from your initial report.

Regards,
Salvatore

[toc] | [next] | [standalone]

#1260369

[Multipart message — attachments visible in raw view] — view raw

On Sat, 6 Sep 2025 13:55:25 +0200 Salvatore Bonaccorso wrote:

[...]
> So while this is IOMMU related, it *still* might be broken firmware
> and you can try if disabling IOMMU "resolves" the issue. Still there
> is indication that this might be a real regression from 6.12 to 6.16.

Hello Salvatore,
thanks for your followup.

I've just tried to disable IOMMU.

Sound output works with:
 
  $ cat /proc/cmdline
  BOOT_IMAGE=/boot/vmlinuz-6.16.3+deb14-amd64 root=UUID=a5d36947-d90d-4818-9184-7cda88ade7fd ro iommu=off quiet
 
Sound is silent with:
 
  $ cat /proc/cmdline
  BOOT_IMAGE=/boot/vmlinuz-6.16.3+deb14-amd64 root=UUID=a5d36947-d90d-4818-9184-7cda88ade7fd ro quiet


So it indeed seems that disabling IOMMU "resolves" or works around the
issue.
Well, not entirely,
It seems that, with disabled IOMMU, sound input (microphone in) is
still silent, and I noticed a number of USB-related warnings/errors
during boot, such as:

  kernel: usb 1-1: device descriptor read/64, error -11
  kernel: usb 2-1: device descriptor read/64, error -11
  kernel: usb 1-1: device descriptor read/64, error -11
  kernel: usb 5-1: device descriptor read/64, error -11
  kernel: usb 2-1: device descriptor read/64, error -11

and a call trace, too:

  kernel: ------------[ cut here ]------------
  kernel: ehci-pci 0000:00:1a.0: DMA addr 0x00000001203d5070+8 overflow (mask ffffffff, bus limit 0).
  kernel: WARNING: CPU: 2 PID: 64 at kernel/dma/direct.h:103 dma_map_page_attrs+0x3b7/0x3f0
  kernel: Modules linked in: iTCO_wdt r8169 intel_pmc_bxt iTCO_vendor_support watchdog ahci xhci_pci libahci realtek xhci_hcd ehci_pci mdio_devres ehci_hcd libphy libata video mdio_bus usbcore scsi_mod wmi e1000e i2c_i801 i2c_smbus scsi_common lpc_ich usb_common efivarfs
  kernel: CPU: 2 UID: 0 PID: 64 Comm: kworker/2:1 Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy)  Debian 6.16.3-1 
  kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme6, BIOS P1.60 12/09/2014
  kernel: Workqueue: usb_hub_wq hub_event [usbcore]
  kernel: RIP: 0010:dma_map_page_attrs+0x3b7/0x3f0
  kernel: Code: 89 0c 24 e8 fb 51 83 00 4d 89 f8 48 c7 c7 78 bb 32 88 48 8d 4c 24 18 53 4c 8b 4c 24 08 48 89 c6 48 8b 54 24 10 e8 b9 8d f1 ff <0f> 0b 4c 89 e3 48 2b 1d d5 1c 3f 01 5a 48 c7 c1 ff ff ff ff 48 c1
  kernel: RSP: 0018:ffffd1320024fae8 EFLAGS: 00010282
  kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff88cf2ea8
  kernel: RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000003
  kernel: RBP: ffff88a14018d0c8 R08: 0000000000000000 R09: 0000000000000000
  kernel: R10: 6c20737562202c66 R11: 2e29302074696d69 R12: fffff658c480f540
  kernel: R13: 0000000000000001 R14: 0000000000000070 R15: 0000000000000008
  kernel: FS:  0000000000000000(0000) GS:ffff88a4d66c8000(0000) knlGS:0000000000000000
  kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  kernel: CR2: 00007f75d49fd0ac CR3: 0000000391c2c002 CR4: 00000000001706f0
  kernel: Call Trace:
  kernel:  <TASK>
  kernel:  usb_hcd_map_urb_for_dma+0x17f/0x470 [usbcore]
  kernel:  usb_hcd_submit_urb+0x2a0/0xa70 [usbcore]
  kernel:  usb_start_wait_urb+0x89/0x190 [usbcore]
  kernel:  usb_control_msg+0xec/0x150 [usbcore]
  kernel:  get_bMaxPacketSize0+0x64/0xc0 [usbcore]
  kernel:  hub_port_init+0x1ee/0xde0 [usbcore]
  kernel:  hub_event+0x10d5/0x1a00 [usbcore]
  kernel:  ? __schedule+0x4b8/0xd00
  kernel:  process_one_work+0x18d/0x340
  kernel:  worker_thread+0x256/0x3a0
  kernel:  ? __pfx_worker_thread+0x10/0x10
  kernel:  kthread+0xfc/0x240
  kernel:  ? __pfx_kthread+0x10/0x10
  kernel:  ? __pfx_kthread+0x10/0x10
  kernel:  ret_from_fork+0x15f/0x190
  kernel:  ? __pfx_kthread+0x10/0x10
  kernel:  ret_from_fork_asm+0x1a/0x30
  kernel:  </TASK>
  kernel: ---[ end trace 0000000000000000 ]---


> So additionally to the above tests I would like to ask you  to do the
> following:
[...]

Wow, a long list of tests!   ;-)
Honestly, I don't know when (or if) I can get around to performing all
these tests...
I guess we will see.

Bye.



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

[toc] | [prev] | [next] | [standalone]

#1263862

[Multipart message — attachments visible in raw view] — view raw

On Sun, 7 Sep 2025 13:01:16 +0200 Francesco Poli wrote:

[...]
> Wow, a long list of tests!   ;-)
> Honestly, I don't know when (or if) I can get around to performing all
> these tests...
> I guess we will see.

OK, a first update.
Via snapshot.debian.org service, I performed a manual search, with the
following results:

  6.13~rc6-1~exp1    BAD
  6.12.43-1          good
  6.12.41-1          good
  6.12.38-1          good

So I guess I now have to bisect between v6.12 and v6.13-rc6, right?


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

[toc] | [prev] | [next] | [standalone]

#1264867

[Multipart message — attachments visible in raw view] — view raw

On Tue, 30 Sep 2025 05:42:51 +0200 Salvatore Bonaccorso wrote:

[...]
> Yes that brings us already quite closer. So next would be to try to
> bisect between v6.12 and v6.13-rc6 upstream.

OK, I found an issue on the first kernel build...

  # 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 localmodconfig
  $ make savedefconfig
  $ mv defconfig arch/x86/configs/my_defconfig
  
  $ make my_defconfig
  $ make -j 2 bindeb-pkg
  [...]
  In file included from ./include/uapi/linux/posix_types.h:5,
                   from ./include/uapi/linux/types.h:14,
                   from ./include/linux/types.h:6,
                   from ./include/linux/kasan-checks.h:5,
                   from ./include/asm-generic/rwonce.h:26,
                   from ./arch/x86/include/generated/asm/rwonce.h:1,
                   from ./include/linux/compiler.h:317,
                   from ./include/linux/build_bug.h:5,
                   from ./include/linux/init.h:5,
                   from ./include/linux/efi.h:15,
                   from drivers/firmware/efi/libstub/efi-stub-helper.c:12:
  ./include/linux/stddef.h:11:9: error: cannot use keyword ‘false’ as enumeration constant
     11 |         false   = 0,
        |         ^~~~~
  ./include/linux/stddef.h:11:9: note: ‘false’ is a keyword with ‘-std=c23’ onwards
  ./include/linux/types.h:35:33: error: ‘bool’ cannot be defined via ‘typedef’
     35 | typedef _Bool                   bool;
        |                                 ^~~~
  ./include/linux/types.h:35:33: note: ‘bool’ is a keyword with ‘-std=c23’ onwards
  ./include/linux/types.h:35:1: warning: useless type name in empty declaration
     35 | typedef _Bool                   bool;
        | ^~~~~~~
  make[9]: *** [scripts/Makefile.build:229: drivers/firmware/efi/libstub/efi-stub-helper.o] Error 1
  make[8]: *** [scripts/Makefile.build:478: drivers/firmware/efi/libstub] Error 2
  make[7]: *** [scripts/Makefile.build:478: drivers/firmware/efi] Error 2
  make[6]: *** [scripts/Makefile.build:478: drivers/firmware] Error 2
  make[5]: *** [scripts/Makefile.build:478: drivers] Error 2
  make[4]: *** [Makefile:1936: .] Error 2
  make[3]: *** [debian/rules:74: build-arch] Error 2
  dpkg-buildpackage: error: make -f debian/rules binary subprocess returned exit status 2
  make[2]: *** [scripts/Makefile.package:126: bindeb-pkg] Error 2
  make[1]: *** [/home/frx/lab/linux/bug1112627/linux-stable/Makefile:1557: bindeb-pkg] Error 2
  make: *** [Makefile:224: __sub-make] Error 2



How do I fix or work around this error?

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

[toc] | [prev] | [next] | [standalone]

#1264914

[Multipart message — attachments visible in raw view] — view raw

On Sun, 5 Oct 2025 20:50:47 +0200 Salvatore Bonaccorso wrote:

[...]
> On Sun, Oct 05, 2025 at 06:40:20PM +0200, Francesco Poli wrote:
[...]
> > How do I fix or work around this error?
> 
> Oh, yes that is quite "unfortunate", unstable switched to gcc-15 in
> meanwhile. So the easiest thing is likely to keep gcc-14 and use it
> for this bisection work.

How do I use gcc-14 to build the Linux kernel?

Is

  $ CC=gcc-14 make -j 2 bindeb-pkg

enough?

Or should I modify some of the previous commands (some configuration
step, perhaps)?



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

[toc] | [prev] | [next] | [standalone]

#1265664

Hi Francesco,

Sorry the delay, busy with other things.

On Sun, Oct 05, 2025 at 09:19:07PM +0200, Francesco Poli wrote:
> On Sun, 5 Oct 2025 20:50:47 +0200 Salvatore Bonaccorso wrote:
> 
> [...]
> > On Sun, Oct 05, 2025 at 06:40:20PM +0200, Francesco Poli wrote:
> [...]
> > > How do I fix or work around this error?
> > 
> > Oh, yes that is quite "unfortunate", unstable switched to gcc-15 in
> > meanwhile. So the easiest thing is likely to keep gcc-14 and use it
> > for this bisection work.
> 
> 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.

Let me know if that works to get your bisect running.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#1265674

[Multipart message — attachments visible in raw view] — view raw

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?



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

[toc] | [prev] | [next] | [standalone]

#1266426

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

[toc] | [prev] | [next] | [standalone]

#1266540

[Multipart message — attachments visible in raw view] — view raw

On Fri, 17 Oct 2025 15:44:21 +0200 Salvatore Bonaccorso wrote:

> Control: tags -1 + moreinfo
> 
> Hi Francesco,

Hello Salvatore,

> 
> On Sat, Oct 11, 2025 at 06:50:06PM +0200, Francesco Poli wrote:
[...]
> >      $ 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?
[...]
> > 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.

Yes, I can confirm.

  $ cat /proc/cmdline 
  BOOT_IMAGE=/boot/vmlinuz-6.13.0-rc6 root=UUID=a5d36947-d90d-4818-9184-7cda88ade7fd ro quiet

This is good.


  $ cat /proc/cmdline 
  BOOT_IMAGE=/boot/vmlinuz-6.13.0-rc6 root=UUID=a5d36947-d90d-4818-9184-7cda88ade7fd ro intel_iommu=on quiet

This is bad: no audio output or input and the usual flood of
error messages in /var/log/kern.log

  kernel: DMAR: DRHD: handling fault status reg 3
  kernel: DMAR: [DMA Write NO_PASID] Request device [00:1b.0] fault addr 0xffa01000 [fault reason 0x0c] non-zero reserved fields in PTE



Please let me know how to proceed.
Thanks 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

[toc] | [prev] | [next] | [standalone]

#1267557

Control: tags -1 + moreinfo

Hi Francesco,

On Sat, Oct 18, 2025 at 01:12:05PM +0200, Francesco Poli wrote:
> On Fri, 17 Oct 2025 15:44:21 +0200 Salvatore Bonaccorso wrote:
> 
> > Control: tags -1 + moreinfo
> > 
> > Hi Francesco,
> 
> Hello Salvatore,
> 
> > 
> > On Sat, Oct 11, 2025 at 06:50:06PM +0200, Francesco Poli wrote:
> [...]
> > >      $ 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?
> [...]
> > > 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.
> 
> Yes, I can confirm.
> 
>   $ cat /proc/cmdline 
>   BOOT_IMAGE=/boot/vmlinuz-6.13.0-rc6 root=UUID=a5d36947-d90d-4818-9184-7cda88ade7fd ro quiet
> 
> This is good.
> 
> 
>   $ cat /proc/cmdline 
>   BOOT_IMAGE=/boot/vmlinuz-6.13.0-rc6 root=UUID=a5d36947-d90d-4818-9184-7cda88ade7fd ro intel_iommu=on quiet
> 
> This is bad: no audio output or input and the usual flood of
> error messages in /var/log/kern.log
> 
>   kernel: DMAR: DRHD: handling fault status reg 3
>   kernel: DMAR: [DMA Write NO_PASID] Request device [00:1b.0] fault addr 0xffa01000 [fault reason 0x0c] non-zero reserved fields in PTE
> 
> 
> 
> Please let me know how to proceed.
> Thanks for your kind assistance!

So we talked about your issue on the last team meeting, and have not
much good steps forwward but the following.

With intel_iommu=off check the full boot log if there are some hints
about swiotlb issues.

https://docs.kernel.org/core-api/swiotlb.html

But then here we would have expected to see for instance an overflow
warning (for which then could try playing around increasing the size).

The second thing we were suggsting: In the boot log the BIOS version
shown is from 2014. Double check if there is an update available. If
so please upgrade to the latest available one, which might have fixed
underlying issue.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#1267591

[Multipart message — attachments visible in raw view] — view raw

On Sat, 25 Oct 2025 16:49:26 +0200 Salvatore Bonaccorso wrote:

[...]
> With intel_iommu=off check the full boot log if there are some hints
> about swiotlb issues.

Which kernel should I perform this check with?
A Debian Linux kernel where the audio fails to work, I guess.
Such as linux-image-6.16.12+deb14+1-amd64/6.16.12-2

Is this correct?


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

[toc] | [prev] | [next] | [standalone]

#1267781

Hi Francesco,

On Sat, Oct 25, 2025 at 05:35:14PM +0200, Francesco Poli wrote:
> On Sat, 25 Oct 2025 16:49:26 +0200 Salvatore Bonaccorso wrote:
> 
> [...]
> > With intel_iommu=off check the full boot log if there are some hints
> > about swiotlb issues.
> 
> Which kernel should I perform this check with?
> A Debian Linux kernel where the audio fails to work, I guess.
> Such as linux-image-6.16.12+deb14+1-amd64/6.16.12-2
> 
> Is this correct?

Yes correct, please the Debian ones. Currently we have 6.16.12-2 in
unstable (or 6.17.5-1~exp1 in experimental, which will be moving to
unstable "soonish")..

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#1267841

[Multipart message — attachments visible in raw view] — view raw

On Sat, 25 Oct 2025 16:49:26 +0200 Salvatore Bonaccorso wrote:

[...]
> On Sat, Oct 18, 2025 at 01:12:05PM +0200, Francesco Poli wrote:
[...]
> > Please let me know how to proceed.
> > Thanks for your kind assistance!
> 
> So we talked about your issue on the last team meeting,

Thanks a lot, much appreciated!

> and have not
> much good steps forwward but the following.
> 
> With intel_iommu=off check the full boot log if there are some hints
> about swiotlb issues.
> 
> https://docs.kernel.org/core-api/swiotlb.html

OK, I tried to boot the current Debian Linux kernel in forky (linux-image-6.16.12+deb14+1-amd64/6.16.12-2) with intel_iommu=off.

In the kern.log snippet corresponding to the boot time span I only see
swiotlb mentioned once:

  $ cat /proc/cmdline 
  BOOT_IMAGE=/boot/vmlinuz-6.16.12+deb14+1-amd64 root=UUID=a5d36947-d90d-4818-9184-7cda88ade7fd ro intel_iommu=off quiet
  $ grep -i swiotlb boot_kern.log 
  kernel: PCI-DMA: Using software bounce buffering for IO (SWIOTLB)

Does this mean that there are issues with swiotlb?

I am attaching the full kern.log snippet, in case you can see something
I am missing...


By the way, an important question: booting
linux-image-6.16.12+deb14+1-amd64/6.16.12-2 with intel_iommu=off makes
audio work, apparently.
Is adding this kernel boot parameter a possible (temporary) workaround?

> 
> But then here we would have expected to see for instance an overflow
> warning (for which then could try playing around increasing the size).
> 
> The second thing we were suggsting: In the boot log the BIOS version
> shown is from 2014. Double check if there is an update available. If
> so please upgrade to the latest available one, which might have fixed
> underlying issue.

I'll try and check whether there is a BIOS update available... although
flashing this update (if any is indeed available) won't necessarily be
an easy and trouble-free process...   :-(


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

[toc] | [prev] | [next] | [standalone]

#1269190

[Multipart message — attachments visible in raw view] — view raw

On Sun, 26 Oct 2025 23:36:29 +0100 Francesco Poli wrote:

[...]
> By the way, an important question: booting
> linux-image-6.16.12+deb14+1-amd64/6.16.12-2 with intel_iommu=off makes
> audio work, apparently.
> Is adding this kernel boot parameter a possible (temporary) workaround?
>
> On Sat, 25 Oct 2025 16:49:26 +0200 Salvatore Bonaccorso wrote:
[...]
> > The second thing we were suggsting: In the boot log the BIOS version
> > shown is from 2014. Double check if there is an update available. If
> > so please upgrade to the latest available one, which might have fixed
> > underlying issue.
> 
> I'll try and check whether there is a BIOS update available... although
> flashing this update (if any is indeed available) won't necessarily be
> an easy and trouble-free process...   :-(

Important update: I flashed the latest BIOS available for the
motherboard (ASRock Z97 Extreme6). This way, I switched from version
P1.60 (year 2014) to version P2.80 (year 2018), as can be seen from the
BIOS download [page].

[page]: <https://www.asrock.com/MB/Intel/Z97%20Extreme6/index.asp#BIOS>

I booted linux-image-6.16.12+deb14+1-amd64/6.16.12-2 and the issue
seemed to have gone away!

Then I happily rebooted and tweaked the few BIOS settings I had
customized before the BIOS update (as documented by ASRock, all
settings were reset to their defaults during the BIOS update).
I booted linux-image-6.16.12+deb14+1-amd64/6.16.12-2 again, and,
surprise!, the issue was back...   :-(

After a few tests, I figured out which setting makes the issue
appear/disappear:

 * 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?

 - 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?

 - does this additional information help in understanding the issue
   and, perhaps, in fixing it?


Please let me know, thanks 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

[toc] | [prev] | [next] | [standalone]

#1269805

Hi Francesco

On Wed, Nov 05, 2025 at 11:52:55PM +0100, Francesco Poli wrote:
> On Sun, 26 Oct 2025 23:36:29 +0100 Francesco Poli wrote:
> 
> [...]
> > By the way, an important question: booting
> > linux-image-6.16.12+deb14+1-amd64/6.16.12-2 with intel_iommu=off makes
> > audio work, apparently.
> > Is adding this kernel boot parameter a possible (temporary) workaround?
> >
> > On Sat, 25 Oct 2025 16:49:26 +0200 Salvatore Bonaccorso wrote:
> [...]
> > > The second thing we were suggsting: In the boot log the BIOS version
> > > shown is from 2014. Double check if there is an update available. If
> > > so please upgrade to the latest available one, which might have fixed
> > > underlying issue.
> > 
> > I'll try and check whether there is a BIOS update available... although
> > flashing this update (if any is indeed available) won't necessarily be
> > an easy and trouble-free process...   :-(
> 
> Important update: I flashed the latest BIOS available for the
> motherboard (ASRock Z97 Extreme6). This way, I switched from version
> P1.60 (year 2014) to version P2.80 (year 2018), as can be seen from the
> BIOS download [page].
> 
> [page]: <https://www.asrock.com/MB/Intel/Z97%20Extreme6/index.asp#BIOS>
> 
> I booted linux-image-6.16.12+deb14+1-amd64/6.16.12-2 and the issue
> seemed to have gone away!
> 
> Then I happily rebooted and tweaked the few BIOS settings I had
> customized before the BIOS update (as documented by ASRock, all
> settings were reset to their defaults during the BIOS update).
> I booted linux-image-6.16.12+deb14+1-amd64/6.16.12-2 again, and,
> surprise!, the issue was back...   :-(
> 
> After a few tests, I figured out which setting makes the issue
> appear/disappear:
> 
>  * if I enable VT-d, audio fails to work
> 
>  * if I disable VT-d, audio works correctly

Yes BIOS flashing/updating are not fun :(

> 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.

>  - 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? Do you use nested virtualization? 

>  - does this additional information help in understanding the issue
>    and, perhaps, in fixing it?

That is still the harder part :(. We will have another meeting on
wednesday and this bug will likely (unless we run out of time) be on
the agenda/table again.

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.

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#1269966

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1270415

Hi,

On Wed, Nov 12, 2025 at 10:44:00PM +0100, Francesco Poli wrote:
> 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!   :-)

I keep the answer short after we discussed it as promissed.

You can pass in as well other PCI devices for instance, say maybe pass
a USB controller in, or a NIC. But really if you never used that for
your usecase, our proposal is now to just keep IOMMU disabled (either
via BIOS setting, or via kernel command line parameter) and consider
this (even not solved in the most optimal way) "done".

Regards,
Salvatore

[toc] | [prev] | [next] | [standalone]

#1271480

[Multipart message — attachments visible in raw view] — view raw

On Thu, 20 Nov 2025 13:15:58 +0100 Salvatore Bonaccorso wrote:

[...]
> On Sun, Nov 16, 2025 at 05:43:05PM +0100, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Wed, Nov 12, 2025 at 10:44:00PM +0100, Francesco Poli wrote:
[...]
> > > OK, looking forward to receiving further feedback.
> > > 
> > > As always, thank you so much for your kind assistance!   :-)
> > 
> > I keep the answer short after we discussed it as promissed.
> > 
> > You can pass in as well other PCI devices for instance, say maybe pass
> > a USB controller in, or a NIC. But really if you never used that for
> > your usecase, our proposal is now to just keep IOMMU disabled (either
> > via BIOS setting, or via kernel command line parameter) and consider
> > this (even not solved in the most optimal way) "done".
> 
> And we agreed in yesterday's meeting since we have a workaround here,
> and no further ideas to move on and close the bug, which I'm doing
> now.

OK, I'll keep VT-d disabled in the UEFI configuration, for the time
being.

Please come back to me, in case some new fact arises in the future.
Thank you so much!

Bye.


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

[toc] | [prev] | [next] | [standalone]

#1271641

Hi Francesco,

On Mon, Nov 24, 2025 at 11:25:51PM +0100, Francesco Poli wrote:
> On Thu, 20 Nov 2025 13:15:58 +0100 Salvatore Bonaccorso wrote:
> 
> [...]
> > On Sun, Nov 16, 2025 at 05:43:05PM +0100, Salvatore Bonaccorso wrote:
> > > Hi,
> > > 
> > > On Wed, Nov 12, 2025 at 10:44:00PM +0100, Francesco Poli wrote:
> [...]
> > > > OK, looking forward to receiving further feedback.
> > > > 
> > > > As always, thank you so much for your kind assistance!   :-)
> > > 
> > > I keep the answer short after we discussed it as promissed.
> > > 
> > > You can pass in as well other PCI devices for instance, say maybe pass
> > > a USB controller in, or a NIC. But really if you never used that for
> > > your usecase, our proposal is now to just keep IOMMU disabled (either
> > > via BIOS setting, or via kernel command line parameter) and consider
> > > this (even not solved in the most optimal way) "done".
> > 
> > And we agreed in yesterday's meeting since we have a workaround here,
> > and no further ideas to move on and close the bug, which I'm doing
> > now.
> 
> OK, I'll keep VT-d disabled in the UEFI configuration, for the time
> being.
> 
> Please come back to me, in case some new fact arises in the future.
> Thank you so much!

Sure if we do no forget or get reminded of this particular issue.

What you might try, time permitting is when you update to a new
(major) upstream version re-try with IOMMU enabled and see if things
get better.

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web