mirror of https://lore.kernel.org/lkml/
 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 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®