public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Mukesh Sisodiya <mukesh.sisodiya@intel.com>,
	Miri Korenblit <miriam.rachel.korenblit@intel.com>,
	Matti Gottlieb <matti.gottlieb@intel.com>,
	Luca Coelho <luciano.coelho@intel.com>
Cc: Johannes Berg <johannes.berg@intel.com>,
	Kalle Valo <kvalo@kernel.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [regression] Significant WiFi Speed Reduction with Kernel Versions > 6.8.12 on Intel Wi-Fi 6 AX203
Date: Mon, 3 Mar 2025 16:27:00 -0600	[thread overview]
Message-ID: <20250303222700.GA202089@bhelgaas> (raw)
In-Reply-To: <20250225182514.GA512422@bhelgaas>

On Tue, Feb 25, 2025 at 12:25:16PM -0600, Bjorn Helgaas wrote:
> On Thu, Aug 08, 2024 at 08:43:53AM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> > On 07.08.24 11:12, Linux regression tracking (Thorsten Leemhuis) wrote:
> > > 
> > > Mukesh Sisodiya, I noticed a report about a regression in
> > > bugzilla.kernel.org that appears to be caused by a change of yours:
> > > 
> > > 099a47dbe71b75 ("wifi: iwlwifi: Add support for new 802.11be device")
> > > [v6.9-rc1]
> > 
> > For the record, turns out the bisection went a bit sideways and the
> > problems apparently is caused by 84ec2d2e960f33 ("wifi: iwlwifi: disable
> > 160 MHz based on subsystem device ID") [v6.9-rc1]. For details, see
> > https://bugzilla.kernel.org/show_bug.cgi?id=219114#c8
> 
> Browsing the regression tracker, this seems stalled with no responses
> even though the submitter (bcc'd) has bisected it.

FWIW, it looks like the following commits are relevant:

  https://git.kernel.org/linus/d6f2134a3831 ("iwlwifi: add mac/rf types and 160MHz to the device tables")
  https://git.kernel.org/linus/568d3434178b ("iwlwifi: pcie: invert values of NO_160 device config entries")
  https://git.kernel.org/linus/4886460c4d15 ("iwlwifi: Fix IWL_SUBDEVICE_NO_160 macro to use the correct bit.")
  https://git.kernel.org/linus/84ec2d2e960f ("wifi: iwlwifi: disable 160 MHz based on subsystem device ID")

4886460c4d15 ("iwlwifi: Fix IWL_SUBDEVICE_NO_160 macro to use the
correct bit.") updated IWL_SUBDEVICE_NO_160() to identify devices that
should not support 160MHz:

  -#define IWL_SUBDEVICE_NO_160(subdevice)        ((u16)((subdevice) & 0x0100) >> 9)
  +#define IWL_SUBDEVICE_NO_160(subdevice)        ((u16)((subdevice) & 0x0200) >> 9)

The submitter's device has Subdevice ID 0x1652.  Prior to
4886460c4d15, that did not match IWL_SUBDEVICE_NO_160(), but
afterwards it does:

  0000:00:14.3 Network controller [0280]: Intel Corporation Alder Lake-P PCH CNVi WiFi [8086:51f0] (rev 01)
    Subsystem: Rivet Networks Dual Band Wi-Fi 6(802.11ax) Killer AX1650i 160MHz 2x2 [Cyclone Peak] [1a56:1652]

But apparently it wasn't until 84ec2d2e960f ("wifi: iwlwifi: disable
160 MHz based on subsystem device ID"), that 160MHz support actually
got disabled for devices that match IWL_SUBDEVICE_NO_160():

  @@ -1061,6 +1061,10 @@ iwl_nvm_fixup_sband_iftd(struct iwl_trans *trans,

  +       if (trans->no_160)
  +               iftype_data->he_cap.he_cap_elem.phy_cap_info[0] &=
  +                       ~IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G;
  +


  @@ -1394,6 +1394,7 @@ static int iwl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)

          dev_info = iwl_pci_find_dev_info(pdev->device, pdev->subsystem_device,
                                           ...
                                           IWL_SUBDEVICE_NO_160(pdev->subsystem_device),
                                           ...);

          if (dev_info) {
                  iwl_trans->cfg = dev_info->cfg;
                  iwl_trans->name = dev_info->name;
  +               iwl_trans->no_160 = dev_info->no_160 == IWL_CFG_NO_160;
          }

84ec2d2e960f appeared in v6.9.  Per the submitter, the speed reduction
appeared in v6.8.12.  Maybe it was backported?  I dunno.

If 160MHz is disabled on that device because of regulatory
restrictions, and it worked when it should not have prior to
84ec2d2e960f, I guess the submitter is out of luck.

If that's the case, maybe we could at least update the bugzilla with
the status to close this out?  The submitter has done a LOT of work to
isolate this, and I think we owe them the courtesy of resolving it.

Bjorn

  reply	other threads:[~2025-03-03 22:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-07  9:12 [regression] Significant WiFi Speed Reduction with Kernel Versions > 6.8.12 on Intel Wi-Fi 6 AX203 Linux regression tracking (Thorsten Leemhuis)
2024-08-08  6:43 ` Linux regression tracking (Thorsten Leemhuis)
2025-02-25 18:25   ` Bjorn Helgaas
2025-03-03 22:27     ` Bjorn Helgaas [this message]
2025-03-05 12:56       ` Johannes Berg

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=20250303222700.GA202089@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=johannes.berg@intel.com \
    --cc=kvalo@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luciano.coelho@intel.com \
    --cc=matti.gottlieb@intel.com \
    --cc=miriam.rachel.korenblit@intel.com \
    --cc=mukesh.sisodiya@intel.com \
    /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