Re: [REGRESSION] intel-iommu/brcmfmac DMAR fault on Broadcom PCIe wifi, v7.3-rc7 -> v7.3 final -- candidate mechanism and proposed fix path

Re: [REGRESSION] intel-iommu/brcmfmac DMAR fault on Broadcom PCIe wifi, v7.3-rc7 -> v7.3 final -- candidate mechanism and proposed fix path

[Arend van Spriel]

Op 20 oktober 2026 18:02:30 schreef Jason Perlow <jperlow@gmail.com>:

> NOTE: an earlier report on this bug from us bounced off one of these lists 
> due to HTML/multipart formatting from the mail client used -- apologies, 
> switching clients. This mail includes the full original report plus a 
> follow-up, merged into one self-contained report since the original never 
> reached anyone.
>
> === ORIGINAL REPORT ===
>
> 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 (at the 
> time of the original report -- see follow-up below, that has since changed) 
> looked like it needed eyes on the core IOMMU/PCI path, not the driver.

[...]

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

Simply run make menuconfig and it should be able to tell you how it is 
selected.

Regards,
Arend>

Re: [REGRESSION] intel-iommu/brcmfmac DMAR fault on Broadcom PCIe wifi, v7.3-rc7 -> v7.3 final -- candidate mechanism and proposed fix path

[Aditya Garg]

> On 20 Oct 2026, at 10:40 PM, Arend van Spriel <arend.vanspriel@broadcom.com> wrote:
> 
> Op 20 oktober 2026 18:02:30 schreef Jason Perlow <jperlow@gmail.com>:
> 
>> NOTE: an earlier report on this bug from us bounced off one of these lists due to HTML/multipart formatting from the mail client used -- apologies, switching clients. This mail includes the full original report plus a follow-up, merged into one self-contained report since the original never reached anyone.
>> 
>> === ORIGINAL REPORT ===
>> 
>> 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 (at the time of the original report -- see follow-up below, that has since changed) looked like it needed eyes on the core IOMMU/PCI path, not the driver.
> 
> [...]
> 
>> 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 yet.

intel_iommu=off has the same effect as disabling this in the kernel config. The real question is WiFi was still working before when intel_iommu was on.

I wonder if PCs with Broadcom chips are also getting affected since we have a confirmed report of a non T2 Mac as well.

[REGRESSION] intel-iommu/brcmfmac DMAR fault on Broadcom PCIe wifi, v7.3-rc7 -> v7.3 final -- candidate mechanism and proposed fix path

[Jason Perlow]

Resending, stupid Gmail mobile client/HTML/apologies .

=== ORIGINAL REPORT ===

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 (at the time of the original report -- see follow-up below, that has since changed) looked like it needed 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 the 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.

ORIGINAL 1-of-5-machines SURVEY (since superseded, see follow-up)

We initially ran the identical kernel build across five machines and only one faulted at the time: the affected unit; a second MacBookPro16,1 with the same BCM4364 chip; three non-Mac x86_64 machines spanning three more wifi vendors (Intel iwlwifi AX201, Intel iwlwifi Centrino 2230, Realtek rtw89 8852BE), all clean. IOMMU was actively translating DMA on every one of the five machines; only the one unit faulted at that time.

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

=== FOLLOW-UP (what changed since the original report) ===

1. The second test unit we called "clean" (CHIMERA, identical MacBookPro16,1 model and BCM4364 chip to the affected unit) was NOT actually immune -- left running longer, it crashed at 41 minutes uptime with the identical signature. So this is not host-specific or even config-specific within a model; it is cumulative/probabilistic with firmware-crash retries, not a static per-unit property. We now apply intel_iommu=off to both units.

2. We tested iommu.strict=1 (forcing synchronous TLB invalidation, no lazy-unmap window) on the affected unit. It does NOT fix the problem -- 9 firmware crashes and 18 DMAR faults in the first minute, same as baseline with lazy invalidation. This rules out a stale-mapping-during-lazy-unmap race specifically. The IOMMU is failing to produce a valid mapping for the address the device requests, not failing to invalidate an old one in time.

CANDIDATE MECHANISM

The four DMAR fault addresses we captured are all exactly 4K-page-aligned, clustered within a ~2MB window, with irregular (non-fixed-stride) deltas between them -- consistent with each firmware-crash retry requesting a genuinely fresh page, not a sub-page cacheable-alias bug.

Reading drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c (v7.3) shows why. On firmware crash, the bus .reset op (brcmf_pcie_reset()) runs this sequence, unconditionally, for every chip revision:

 1. Disable ASPM.
 2. A real hardware watchdog reset of the wifi chip's own silicon: WRITECC32(devinfo, watchdog, 4) -- a write to the BCMA ChipCommon core's watchdog register, Broadcom's standard SoC-wide hardware reset mechanism (used here in place of a PCIe FLR).
 3. Restore ASPM.
 4. Free the old ring buffers (brcmf_pcie_release_ringbuffers, dma_free_coherent) and allocate fresh ones (brcmf_pcie_init_ringbuffers -> dma_alloc_coherent, confirmed clean, correct DMA-API usage -- no raw pointer math, no dma_map_single/dma_map_page misuse).

So every firmware-crash recovery cycle contains an actual chip-level hardware reset of the wifi silicon, sitting inside the normal recovery path, immediately before fresh DMA buffers are allocated. The IOMMU has no visibility into that internal chip reset -- it only tracks dma_alloc_coherent/dma_free_coherent calls. If the chip's internal DMA engine state (cached pointers, in-flight descriptor/prefetch state) is not fully re-synchronized with the IOMMU's page tables across that reset window -- plausibly interacting with whatever changed in pci_dev_wait()'s reset-timing behavior between v7.3-rc7 and final, one of the only real PCI-core diffs we could find between those two tags -- a stale or premature DMA read from the chip in that window would produce exactly "PTE Read access is not set": a page the IOMMU has no reason to have mapped yet.

This reads as plausibly Broadcom-specific rather than a generic any-PCIe-wifi-vendor bug: in our survey across Intel iwlwifi (two chip generations) and Realtek rtw89, all clean on identical kernel/IOMMU config, none of those drivers perform a full chip-level silicon watchdog reset as part of routine firmware-crash recovery the way brcmfmac does. That is a direct consequence of Broadcom's wifi chips having their own embedded ARM co-processor and firmware, versus a more host-driven firmware model elsewhere.

We have not proven this causally yet -- it is a source-grounded mechanism, not a confirmed root cause.

PROPOSED FIX PATH

1. Bisect: the real fix, if this mechanism is right, most likely belongs in one of two places -- (a) brcmfmac's reset sequence, inserting a synchronization point (barrier, or a readback to force completion) between the point where the fresh DMA mapping is guaranteed IOMMU-visible and the point where the device is signaled ready to resume (brcmf_pcie_hostready / the mailbox write that follows), or (b) PCI/IOMMU core, if pci_dev_wait()'s v7.3 behavior change doesn't give the IOMMU enough time to fully settle before the device can issue a post-reset DMA. We don't yet know which.
2. We are rebuilding with CONFIG_DMA_API_DEBUG=y to reproduce this on the affected unit. That should show the exact call site and timing of the bad mapping, which would tell us definitively whether this is a one-line brcmfmac timing fix or something deeper in IOMMU/PCI core. Will report back with results.
3. In the meantime, worth testing as a less blunt interim workaround than intel_iommu=off: iommu=pt (passthrough -- disables DMA remapping but keeps interrupt remapping). Haven't tried this yet ourselves.

Happy to share full dmesg, the DMA_API_DEBUG output once we have it, or test a proposed patch on real hardware -- we have the affected unit and can reproduce on demand.