Linux wireless drivers development
 help / color / mirror / Atom feed
From: Aditya Garg <aditya.garg@linux.dev>
To: Peter Kiddier <peter@kiddier.org>, linux-wireless@vger.kernel.org
Cc: brcm80211@lists.linux.dev, iommu@lists.linux.dev,
	arend.vanspriel@broadcom.com, regressions@lists.linux.dev,
	jgg@nvidia.com, kevin.tian@intel.com, joro@8bytes.org,
	will@kernel.org, robin.murphy@arm.com, dwmw2@infradead.org,
	baolu.lu@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: [REGRESSION] BCM4355 Wi-Fi fails with Intel IOMMU on 7.3.0-2-t2-noble
Date: Tue, 20 Oct 2026 17:38:44 +0530	[thread overview]
Message-ID: <b75feca5-6025-44ff-8b82-b1da48cc5ced@linux.dev> (raw)
In-Reply-To: <CA+3E58-2N-uVNsmwvOGDKZvtnDQ1DF=GzFbTyRLuN8FpAd4qdg@mail.gmail.com>



On 20/10/26 5:19 pm, Peter Kiddier wrote:
> Adding the IOMMU maintainers and linux-kernel.
> 
> The original report and test results are below for context.
> 
> I haven't tested a vanilla upstream kernel, and may have limited time
> for further testing, but wanted to share the findings in case they're
> useful.
> 
> Thank you.

https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/info.html

Similar issue is present in older non T2 Macs, so definitely not a T2 patches issue. Also, T2 patches do not touch IOMMU or brcmfmac

> 
> 
> On Tue, 20 Oct 2026 at 22:32, Peter Kiddier <peter@kiddier.org> wrote:
>>
>> Hello,
>>
>> I am reporting a Wi-Fi regression on a 2018 Apple MacBook Air with a
>> T2 chip, running Linux Mint Zena based on Ubuntu 24.04.
>>
>> The Broadcom BCM4355 Wi-Fi device works with kernel 7.2.11-3-t2-noble
>> but fails with 7.3.0-2-t2-noble. Disabling the Intel IOMMU using
>> intel_iommu=off restores Wi-Fi on 7.3.0-2.
>>
>> Hardware:
>> - Apple MacBook Air 2018 (MacBookAir8,1)
>> - Wi-Fi: Broadcom BCM4355 802.11ac Wireless LAN SoC
>> - PCI ID: 14e4:43dc (subsystem 106b:0843)
>> - Driver: brcmfmac
>> - Interface: wlp2s0
>>
>> Test results:
>>
>> - 7.2.11-3-t2-noble, default kernel command line: Wi-Fi works.
>> - 7.3.0-2-t2-noble, default kernel command line: Wi-Fi fails.
>> - 7.3.0-2-t2-noble with intel_iommu=off: Wi-Fi works.
>> - Reloading brcmfmac on the failing configuration does not restore Wi-Fi.
>>
>> On the failing 7.3.0-2 boot, the driver detects the device, loads its
>> firmware and creates wlp2s0:
>>
>> brcmfmac 0000:02:00.0: enabling device (0000 -> 0002)
>> brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4355c1-pcie for
>> chip BCM4355/12
>> brcmfmac: brcmf_c_process_txcap_blob: TxCap blob found, loading
>> brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4355/12 wl0: Jul  8 2023
>> 17:49:51 version 9.30.503.0.32.5.87 FWID 01-e74b9cb0
>> brcmfmac 0000:02:00.0 wlp2s0: renamed from wlan0
>>
>> However, Wi-Fi subsequently stops responding. The kernel log reports
>> errors including:
>>
>> brcmf_msgbuf_query_dcmd: Timeout on response for query command
>> brcmf_cfg80211_scan: scan error (-5)
>> brcmf_run_escan: error (-5)
>> brcmf_msgbuf_tx_ioctl: Failed to reserve space in commonring
>> brcmf_cfg80211_get_channel: chanspec failed (-5)
>>
>> There is also an error creating the P2P interface:
>>
>> brcmf_cfg80211_add_iface: add iface p2p-dev-wlp2s0 type 10 failed: err=-52
>>
>> I tried reloading the driver using:
>>
>> sudo modprobe -r brcmfmac_wcc
>> sudo modprobe -r brcmfmac
>> sudo modprobe brcmfmac
>>
>> The driver and firmware loaded again, but Wi-Fi remained unusable.
>>
>> The firmware files are present under /lib/firmware/brcm/, and the
>> firmware version reported by the driver is the same on the working and
>> failing kernels.
>>
>> The brcmfmac module metadata differs between the kernels:
>>
>> Working kernel 7.2.11-3-t2-noble:
>> srcversion: 3B6176FDB720DDE8E7C596B
>>
>> Failing kernel 7.3.0-2-t2-noble:
>> srcversion: 3DCA38D52402541701276CF
>>
>> I did not find obvious PCIe AER or fatal errors in the failing boot's
>> kernel log.
>>
>> It has been suggested testing intel_iommu=off after reloading
>> brcmfmac. The driver reload did not help, but booting with
>> intel_iommu=off restored Wi-Fi.
>>
>> This strongly suggests an interaction between Intel IOMMU handling and
>> the BCM4355/brcmfmac driver in the 7.3.0-2-t2-noble kernel.
>>
>> I have not tested a vanilla upstream kernel, so I cannot yet confirm
>> whether this reproduces outside the T2 kernel packages. Unfortunately,
>> I have limited time available for further testing, so I may not be
>> able to investigate additional requests promptly. I wanted to report
>> the reproducible behaviour and the intel_iommu=off workaround in case
>> it helps identify the regression.
>>
>> Could you advise on further diagnostics, or whether this should be
>> investigated as an IOMMU or brcmfmac regression?
>>
>> Thank you.


      reply	other threads:[~2026-10-20 12:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-20 11:32 [REGRESSION] BCM4355 Wi-Fi fails with Intel IOMMU on 7.3.0-2-t2-noble Peter Kiddier
2026-10-20 11:49 ` Peter Kiddier
2026-10-20 12:08   ` Aditya Garg [this message]

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=b75feca5-6025-44ff-8b82-b1da48cc5ced@linux.dev \
    --to=aditya.garg@linux.dev \
    --cc=arend.vanspriel@broadcom.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=brcm80211@lists.linux.dev \
    --cc=dwmw2@infradead.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=peter@kiddier.org \
    --cc=regressions@lists.linux.dev \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /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