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

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]

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.

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]

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

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

[Jason Perlow]

Yes, done. rc7 with intel_iommu=on on the same MacBookPro16,1 shows
the same fault: 95 DMAR faults, each followed by brcmf_fw_crashed, in
one boot. So no rc7 -> final regression in the IOMMU code.

It is a v7.2 -> v7.3-rc1 regression in brcmfmac, from f0ba5fd51ff2
("wifi: brcmfmac: Set DMA direction for msgbuf packet IDs"). RX
buffers are now mapped DMA_FROM_DEVICE (prot 0x6, no IOMMU_READ) and
the BCM4364 firmware reads them:

  36.512689 map   iova=0xffeff2c0 size=2048 prot=0x6 (brcmf_msgbuf_rxbuf_data_post)
  41.110125 DMAR: [DMA Read NO_PASID] Request device [0000:05:00.0] fault addr 0xffeff000 [fault reason 0x06] PTE Read access is not set
  41.139317 brcmf_fw_crashed: Firmware has halted or crashed

The fault comes before the crash. Before that commit the direction
stayed 0 (DMA_BIDIRECTIONAL). 

Thanks for the pointer.

On October 21, 2026 2:13:40 AM AST, Baolu Lu <baolu.lu@linux.intel.com> wrote:
>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

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

[Arend van Spriel]

Please respond inline. No top posting.

On 21/10/2026 09:33, Jason Perlow wrote:
> Yes, done. rc7 with intel_iommu=on on the same MacBookPro16,1 shows
> the same fault: 95 DMAR faults, each followed by brcmf_fw_crashed, in
> one boot. So no rc7 -> final regression in the IOMMU code.
> 
> It is a v7.2 -> v7.3-rc1 regression in brcmfmac, from f0ba5fd51ff2
> ("wifi: brcmfmac: Set DMA direction for msgbuf packet IDs"). RX
> buffers are now mapped DMA_FROM_DEVICE (prot 0x6, no IOMMU_READ) and
> the BCM4364 firmware reads them:
> 
>    36.512689 map   iova=0xffeff2c0 size=2048 prot=0x6 (brcmf_msgbuf_rxbuf_data_post)
>    41.110125 DMAR: [DMA Read NO_PASID] Request device [0000:05:00.0] fault addr 0xffeff000 [fault reason 0x06] PTE Read access is not set
>    41.139317 brcmf_fw_crashed: Firmware has halted or crashed
> 
> The fault comes before the crash. Before that commit the direction
> stayed 0 (DMA_BIDIRECTIONAL).
> 
> Thanks for the pointer.

The only DMA related commit that I could think of was indeed the DMA 
direction change. Hope restoring DMA_BIDIRECTIONAL fixes it.

Regards,
Arend