All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aditya Garg <aditya.garg@linux.dev>
To: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: Jason Perlow <jperlow@gmail.com>,
	baolu.lu@linux.intel.com, dwmw2@infradead.org,
	iommu@lists.linux.dev, bhelgaas@google.com,
	linux-pci@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	regressions@leemhuis.info
Subject: Re: [REGRESSION] intel-iommu/brcmfmac DMAR fault on Broadcom PCIe wifi, v7.3-rc7 -> v7.3 final -- candidate mechanism and proposed fix path
Date: Tue, 20 Oct 2026 23:19:29 +0530	[thread overview]
Message-ID: <BCAFF55F-7FFA-4CB5-8738-F56D0F205086@linux.dev> (raw)
In-Reply-To: <1a15a4b49f0.2873.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>



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

  reply	other threads:[~2026-10-20 17:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <D0E6473C-3234-4367-83E7-B85C022B0F1A@gmail.com>
2026-10-20 17:10 ` [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
2026-10-20 17:49   ` Aditya Garg [this message]
2026-10-20 16:24 Jason Perlow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BCAFF55F-7FFA-4CB5-8738-F56D0F205086@linux.dev \
    --to=aditya.garg@linux.dev \
    --cc=arend.vanspriel@broadcom.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jperlow@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.