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

[Baolu Lu <baolu.lu@linux.intel.com>]

On 10/20/26 22:40, Perlow, Jason 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.
> 
> 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.

Can you confirm that the IOMMU is actually enabled and translating on
the rc7 boot? Please check that boot's kernel log for:

DMAR: IOMMU enabled
iommu: Default domain type: Translated

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

If CONFIG_INTEL_IOMMU_DEFAULT_ON was not set in your rc7 build, and
intel_iommu=on was not on the command line, the Intel IOMMU was
disabled by default on rc7. In that case, rc7 could never report a
DMAR fault, and the "regression" is only that v7.3 final enabled the
IOMMU.

Could you boot the rc7 kernel on the affected unit with intel_iommu=on
and see whether the same fault shows up? If it does, there is no
rc7->final regression in the IOMMU code. It would be an existing DMA
issue with brcmfmac/BCM4364.

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

Thanks,
baolu