[regression] Significant WiFi Speed Reduction with Kernel Versions > 6.8.12 on Intel Wi-Fi 6 AX203

[regression] Significant WiFi Speed Reduction with Kernel Versions > 6.8.12 on Intel Wi-Fi 6 AX203

[Linux regression tracking (Thorsten Leemhuis)]

Hi, Thorsten here, the Linux kernel's regression tracker.

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]

As many (most?) kernel developers don't keep an eye on the bug tracker,
I decided to write this mail. To quote from
https://bugzilla.kernel.org/show_bug.cgi?id=219114 :

> I am experiencing a significant reduction in WiFi download speeds when
> using any Linux kernel version greater than 6.8.12. The issue does not
> occur with kernel versions 6.8.12 or lower. The only change is the
> firmware version loaded by the kernel (I have attached the full output
> of "dmesg | grep iwlwifi" for both kernel versions as text files). I
> have also tried downgrading the firmware, but it did not resolve the
> issue. The problem occurs across different Linux distributions,
> indicating that it is related to the default kernel.
> 
> Hardware Details:
> 
> Laptop Model: Acer Nitro 5 AN-515-58
> Network Card: Intel® Wi-Fi 6 AX203, REV=0x370
> CPU: Intel i7-12700H
> Bluetooth: Intel Corp. AX201 Bluetooth
> 
> Additional Information:
> 
> lspci -nnkv | sed -n ‘/Network/,/^$/p’:
> 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]
>         Flags: bus master, fast devsel, latency 0, IRQ 16, IOMMU group 10
>         Memory at 6105274000 (64-bit, non-prefetchable) [size=16K]
>         Capabilities: <access denied>
>         Kernel driver in use: iwlwifi
>         Kernel modules: iwlwifi
> 
> lsusb | grep Bluetooth:
> Bus 003 Device 003: ID 8087:0026 Intel Corp. AX201 Bluetooth
> 
> Thank you for your assistance.

See the ticket for more details and the bisection. Note, you have to use
bugzilla to reach the reporter, as I sadly[1] can not CCed them in mails
like this.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

[1] because bugzilla.kernel.org tells users upon registration their
"email address will never be displayed to logged out users"

P.S.: let me use this mail to also add the report to the list of tracked
regressions to ensure it's doesn't fall through the cracks:

#regzbot introduced: 099a47dbe71b75
#regzbot title: wifi: iwlwifi: WiFi Speed Reduction on Intel Wi-Fi 6 AX203
#regzbot from: siero.o.p.33
#regzbot duplicate: https://bugzilla.kernel.org/show_bug.cgi?id=219114
#regzbot ignore-activity

Re: [regression] Significant WiFi Speed Reduction with Kernel Versions > 6.8.12 on Intel Wi-Fi 6 AX203

[Linux regression tracking (Thorsten Leemhuis)]

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

Ciao, Thorsten

Re: [regression] Significant WiFi Speed Reduction with Kernel Versions > 6.8.12 on Intel Wi-Fi 6 AX203

[Bjorn Helgaas]

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.

Maybe regzbot will notice the correct commit below?

#regzbot introduced: 84ec2d2e960f ("wifi: iwlwifi: disable 160 MHz based on subsystem device ID")

Re: [regression] Significant WiFi Speed Reduction with Kernel Versions > 6.8.12 on Intel Wi-Fi 6 AX203

[Bjorn Helgaas]

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

Re: [regression] Significant WiFi Speed Reduction with Kernel Versions > 6.8.12 on Intel Wi-Fi 6 AX203

[Johannes Berg]

[removing folks no longer involved]

Hi,

So ... it's complicated, but I think it's a bug.

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

I'm not even entirely sure this logic is correct; however, it doesn't
really matter.

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

According to our internal information (SKUMAP-362, for the Intel folks
who know what that means), this name is correct, it should be 160 Mhz.

> 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():

I've also found information elsewhere (WREQ-269994) that the whole
IWL_SUBDEVICE_NO_160 (now actually a bit different to take no-320 into
account on newer hardware) is *not* applicable to "Killer" branded
devices at all.

So I think it's a bug, but I'm not sure right now *how* we can fix it.
It looks like our matching must skip the bandwidth restriction thing for
Killer devices.

johannes