Re: intel-iommu: DMAR PTE Read fault crash-loops a PCIe wifi device, v7.3-rc7 -> v7.3 final regression, reproduces on one unit out of five tested

[Aditya Garg <aditya.garg@linux.dev>]

On 20 October 2026 8:10:21 pm IST, "Perlow, Jason" <jperlow@gmail.com> wrote:
>Hardware: Intel CoffeeLake-H platforms, various. The affected device is a
>Broadcom BCM4364 802.11ac PCIe wifi adapter (14e4:4464) at 0000:05:00.0 on
>an Apple MacBookPro16,1 (T2 Mac). Aditya, including you directly since this
>is T2 hardware; copying iommu/pci/wireless because the fault signature and
>the fact that it reproduces on only one of five tested machines looks like
>it needs eyes on the core IOMMU/PCI path, not the driver.

Nice that's the third bug report of this issue today:

1. https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg6317918.html

2. https://lore.kernel.org/lkml/CA+3E58-2N-uVNsmwvOGDKZvtnDQ1DF=GzFbTyRLuN8FpAd4qdg@mail.gmail.com/

>
>SYMPTOM
>
>Between a locally-built v7.3-rc7 kernel and a v7.3 final kernel (same
>.config template, same patch series beyond one T2-specific AER quirk that
>is upstream in final and therefore held out of our patch set), the BCM4364
>wifi firmware on ONE affected unit crash-loops continuously:
>
>brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4364b3-pcie for chip
>BCM4364/4
>brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4364/4 wl0: ...
>ieee80211 phy0: brcmf_fw_crashed: Firmware has halted or crashed
>
>repeating every ~6s, indefinitely. dmesg shows the actual mechanism -- a
>real IOMMU DMAR page fault on the wifi device, timed to the same cadence as
>the firmware crash:
>
>DMAR: DRHD: handling fault status reg 3
>DMAR: [DMA Read NO_PASID] Request device [0000:05:00.0] fault addr
>0xffeff000 [fault reason 0x06] PTE Read access is not set
>
>Four such faults logged at uptime 13.4s/19.4s/25.3s/31.2s, each immediately
>followed by a brcmf_fw_crashed event. intel_iommu=off removes the fault and
>the crash entirely (8+ minutes stable, single clean firmware load, stable
>AP association). The prior v7.3-rc7 kernel on the SAME unit has zero DMAR
>faults and zero firmware crashes with IOMMU on by default, so this is a
>regression introduced somewhere in the rc7->final window on this unit, not
>a long-standing issue.
>
>REPRODUCES ON 1 OF 5 MACHINES TESTED
>
>We ran the identical kernel build (and, where applicable, the identical
>firmware blob) across five machines and only one faults:
>
>* Affected unit (MacBookPro16,1, T2, BCM4364 wifi): faults as above.
>* Second MacBookPro16,1 (same generation, different configuration within
>the 16,1 line -- we have not enumerated every hardware delta): same kernel
>binary, same firmware blob, IOMMU also active by default (iommu: Default
>domain type: Translated, identical to the affected unit) -- zero DMAR
>faults, brcmfmac stable.
>* Three non-Mac x86_64 machines spanning three more wifi vendors (Intel
>iwlwifi AX201, Intel iwlwifi Centrino 2230, Realtek rtw89 8852BE) -- IOMMU
>active and translating on all three, zero DMAR faults, all three wifi chips
>loaded firmware and ran cleanly.
>
>So across four different wifi silicon vendors and five physical machines,
>IOMMU is actively translating DMA on every one of them and only the single
>affected unit faults. This looks like a host-specific or
>hardware-configuration-specific trigger rather than a blanket rc7->final
>regression that would hit every machine with this kernel. We do not yet
>know what distinguishes the affected unit (ACPI RMRR table contents, exact
>PCIe link training time, and IOMMU group/domain-attach ordering are the
>candidates we have not yet isolated).
>
>WHAT WE RULED OUT BEFORE WRITING IN
>
>* AER/ANFE quirk on the T2 Secure Enclave device: its PCI ID match is exact
>(Apple SEP, 106b:1802) and does not touch the wifi device (14e4:4464); real
>PCI topology on the affected unit also shows SEP and wifi on separate root
>ports (00:1b.0 -> [04] vs 00:1c.0 -> [05] off the PCH), so there's no
>shared-root-port mechanism either.
>* brcmfmac driver source: git diff v7.3-rc7..v7.3 --
>drivers/net/wireless/broadcom/brcm80211/ is empty.
>* Our own config template: byte-identical between the rc7 and final builds.
>* The upstream Kconfig stanza for INTEL_IOMMU_DEFAULT_ON
>(drivers/iommu/intel/Kconfig): byte-identical text between v7.3-rc7 and
>v7.3 (default y, no depends on).
>
>THE ONE ANOMALY WE CAN'T YET EXPLAIN
>
>Despite the last two items above being unchanged, the actual generated
>.config has CONFIG_INTEL_IOMMU_DEFAULT_ON unset after make olddefconfig
>against the rc7 source tree, but =y after the same process against the
>final source tree, even though our template explicitly answers "#
>CONFIG_INTEL_IOMMU_DEFAULT_ON is not set" in both cases. Our working theory
>is that some other symbol started selecting/implying INTEL_IOMMU_DEFAULT_ON
>between rc7 and final -- which would override an explicitly-seeded "not
>set" answer during olddefconfig resolution -- but we have not identified
>which one. Happy to bisect further, or provide the full .config /
>additional dmesg, if that would help narrow it.
>
>CURRENT STATUS
>
>intel_iommu=off on the affected unit's kernel command line is our accepted
>fix for this specific machine while the root cause is unresolved; we are
>not disabling IOMMU fleet-wide, since four of the five test machines show
>no problem with it on. Posting here in case this fault signature is
>recognized, or in case others on different T2 or non-T2 hardware see the
>same thing on v7.3 final.