Bug 219974

[    3.556788] iwlwifi 0000:85:00.0: Detected crf-id 0x2001910, cnv-id 0x2001910 wfpm id 0x80000000
[    3.556795] iwlwifi 0000:85:00.0: PCI dev 272b/1774, rev=0x472, rfid=0x112200
[    3.556796] iwlwifi 0000:85:00.0: Detected Intel(R) Wi-Fi 7 BE202 160MHz
[    3.557027] Adding 1761276k swap on /dev/sdb2.  Priority:-2 extents:1 across:1761276k SS
[    3.560299] systemd[1]: Activated swap dev-disk-by\x2duuid-7fffba54\x2d448a\x2d49af\x2d8a6a\x2d6fea7692940c.swap - /dev/disk/by-uuid/7fffba54-448a-49af-8a6a-6fea7692940c.
[    3.560342] systemd[1]: Reached target swap.target - Swaps.
[    3.561972] iwlwifi 0000:85:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.4.191
[    3.562194] iwlwifi 0000:85:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[    3.562198] iwlwifi 0000:85:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[    3.562202] iwlwifi 0000:85:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[    3.562203] iwlwifi 0000:85:00.0: loaded firmware version 94.62990553.0 gl-c0-fm-c0-94.ucode op_mode iwlmvm
[    3.592959] Bluetooth: Core ver 2.22
[    3.592972] NET: Registered PF_BLUETOOTH protocol family
[    3.592973] Bluetooth: HCI device and connection manager initialized
[    3.592975] Bluetooth: HCI socket layer initialized
[    3.592976] Bluetooth: L2CAP socket layer initialized
[    3.592978] Bluetooth: SCO socket layer initialized

Yes, that's a Killer (branded) NIC:

"Killer(TM) Wi-Fi 7 BE1750x 320MHz Wireless Network Adapter (BE200NGW)"

Not sure we can fix that so easily on that kernel version, but I'll see about adding it.

Erm... Killer branded (no-vPro) are basically just normal BE200. While you also have BE200 with vPro and without. So 3 devices under BE200. Kernel 6.13.8 already has this commit and you also added support for new BE213: https://github.com/torvalds/linux/commit/16a8d9a739430bec9c11eda69226c5a39f3478aa

It should just work... But it does not and checking for crf-id 0x2001910 leads to BE202 iwl_mtp_name instead of iwl_gl_name, this codepath: https://github.com/torvalds/linux/blob/a2cc6ff5ec8f91bc463fd3b0c26b61166a07eb11/drivers/net/wireless/intel/iwlwifi/pcie/drv.c#L1174

I am afraid that 320 vs 160 has some effect on my Wifi 7...

Though iw list shows 320 everywhere. So probably kust cosmetic.

BTW, why there can you fix this: Bug 208421


I believe it as easy as reverting the commit

https://github.com/torvalds/linux/commit/8fc3015d0d35f42ee57c04bfe3c17f112afce5fe

Otherwise the bug is probably in firmware_request_nowarn, it is weird how it is printed 3 times nowadays if you look at my dmesg again...

Tried simple hack to enable what I want in /drivers/net/wireless/intel/iwlwifi/pcie/drv.c:

 /* Ga (Gl) */
        IWL_DEV_INFO(iwl_cfg_bz, iwl_gl_name, MAC_TYPE(GL), RF_TYPE(FM),
                     BW_NOT_LIMITED, NO_CDB),
-       IWL_DEV_INFO(iwl_cfg_bz_160mhz, iwl_mtp_name, MAC_TYPE(GL), RF_TYPE(FM),
-                    BW_LIMITED, NO_CDB),
+       IWL_DEV_INFO(iwl_cfg_bz, iwl_gl_name, MAC_TYPE(GL), RF_TYPE(FM),
+                    BW_NOT_LIMITED, NO_CDB),
 
 /* Sc */
        IWL_DEV_INFO(iwl_cfg_sc, iwl_ax211_name, MAC_TYPE(SC), RF_TYPE(GF)),


Did not work, it now says 

[    3.909209] Intel(R) Wireless WiFi driver for Linux
[    3.909256] iwlwifi 0000:85:00.0: enabling device (0000 -> 0002)
[    3.911472] iwlwifi 0000:85:00.0: Detected crf-id 0x2001910, cnv-id 0x2001910 wfpm id 0x80000000
[    3.911479] iwlwifi 0000:85:00.0: PCI dev 272b/1774, rev=0x472, rfid=0x112200
[    3.911481] iwlwifi: No config found for PCI dev 272b/1774, rev=0x472, rfid=0x112200
[    3.911492] iwlwifi 0000:85:00.0: probe with driver iwlwifi failed with error -22

Now I will try to add Intel Killer BE1750x 320MHz name circa how it is done in https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/commit/?id=9afe21e501f7201ae32b15fc931b4514f3f444ab

If 'iw list' shows 320 capability then it should be fine, just the name.

I'm working on cross-referencing our device/SKU database with the driver, but there are ~2.5k combinations (not even counting old devices), so it's not that simple.

Created attachment 307937 [details]
Output of iw list

Well, after exit from S3 (LOL) I just see this, I cannot see 320 anymore.

Also, I do not think iw list is reliable, iw dev would be reliable. See Bug 219114

Created attachment 307938 [details]
Older driver from stable kernel 6.12.13

320 is broken now on master! Even without S3. This is output from older driver.

Bisected!! First bad commit fa64fc525a370d9f774f8fe0c51d584b91ef98b2 (wifi: iwlwifi: add support for BE213), iw list still worked good on commit 3ffd272aa678f0144863c74dc991ebcc0c480c57 wifi: iwlwifi: make no_160 more generic and commit 7207b1a567777393d6c7c6a50f8743b98fc7c62c

Okay, lets try and cleanly revert this BE213 patch

How to cleanly revert this, due to this very bug I imagine trans->bw_limit has value 160 when it should be 320:

https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/commit/?id=fa64fc525a370d9f774f8fe0c51d584b91ef98b2

I have to remove trans->bw_limit >= 320 and trans->bw_limit < 320 condtions.

@@ -953,8 +953,7 @@ iwl_nvm_fixup_sband_iftd(struct iwl_trans *trans,
                                       IEEE80211_EHT_MAC_CAP0_MAX_MPDU_LEN_MASK);
                break;
        case NL80211_BAND_6GHZ:
-               if (!trans->reduced_cap_sku &&
-                   (!trans->cfg->bw_limit || trans->cfg->bw_limit >= 320)) {
+               if (!trans->reduced_cap_sku) {
                        iftype_data->eht_cap.eht_cap_elem.phy_cap_info[0] |=
                                IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ;
                        iftype_data->eht_cap.eht_cap_elem.phy_cap_info[1] |=
@@ -1108,19 +1107,16 @@ iwl_nvm_fixup_sband_iftd(struct iwl_trans *trans,
                iftype_data->he_cap.he_cap_elem.phy_cap_info[0] &=
                        ~IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G;
 
-       if ((trans->cfg->bw_limit && trans->cfg->bw_limit < 320) ||
-           trans->reduced_cap_sku) {
+       if (trans->reduced_cap_sku) {
                memset(&iftype_data->eht_cap.eht_mcs_nss_supp.bw._320, 0,
                       sizeof(iftype_data->eht_cap.eht_mcs_nss_supp.bw._320));
-               iftype_data->eht_cap.eht_cap_elem.phy_cap_info[2] &=
-                       ~IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK;
-       }
 
-       if (trans->reduced_cap_sku) {
                iftype_data->eht_cap.eht_mcs_nss_supp.bw._80.rx_tx_mcs13_max_nss = 0;
                iftype_data->eht_cap.eht_mcs_nss_supp.bw._160.rx_tx_mcs13_max_nss = 0;
                iftype_data->eht_cap.eht_cap_elem.phy_cap_info[8] &=
                        ~IEEE80211_EHT_PHY_CAP8_RX_4096QAM_WIDER_BW_DL_OFDMA;
+               iftype_data->eht_cap.eht_cap_elem.phy_cap_info[2] &=
+                       ~IEEE80211_EHT_PHY_CAP2_SOUNDING_DIM_320MHZ_MASK;
        }
 
        if (fw_has_capa(&fw->ucode_capa, IWL_UCODE_TLV_CAPA_RESTRICTED_TWT_SUPPORT))


And now it works. 

			EHT bw=160 MHz, max NSS for MCS 8-9: Rx=2, Tx=2
			EHT bw=160 MHz, max NSS for MCS 10-11: Rx=2, Tx=2
			EHT bw=160 MHz, max NSS for MCS 12-13: Rx=2, Tx=2
			EHT bw=320 MHz, max NSS for MCS 8-9: Rx=2, Tx=2
			EHT bw=320 MHz, max NSS for MCS 10-11: Rx=2, Tx=2
			EHT bw=320 MHz, max NSS for MCS 12-13: Rx=2, Tx=2

I thought when I removed myself once from CC list that was obvious. Please stop CC'ing me.

It's more complicated, you're missing a lot of other devices that _do_ require this... so we probably shouldn't unconditionally remove it, though perhaps we could revert it for now, assuming those aren't really shipping yet ...

In any case, I had been working on cleaning this up for a while, and just did a large number of other cleanups on top of it.

You can find a snapshot here:

https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/log/?h=config-cleanup

If you want to try, please let me know how it goes. Pretty sure it should be working OK for your device, according to our list of devices.

Created attachment 307946 [details]
iwlist320

Yes, fixed! Is the missing Configured antennas after Available Antennas: TX 0x3 RX 0x3 expected? It was present before:  Comment 8
 This would be nice to backport as fix for https://github.com/torvalds/linux/commit/16a8d9a739430bec9c11eda69226c5a39f3478aa

After git checkout 82d656e4fa337f124dbdca4885d2b81beb338fdb

[    4.061153] Intel(R) Wireless WiFi driver for Linux
[    4.061200] iwlwifi 0000:85:00.0: enabling device (0000 -> 0002)
[    4.064540] iwlwifi 0000:85:00.0: Detected crf-id 0x2001910, cnv-id 0x2001910 wfpm id 0x80000000
[    4.064550] iwlwifi 0000:85:00.0: PCI dev 272b/1774, rev=0x472, rfid=0x112200
[    4.064552] iwlwifi 0000:85:00.0: Detected Killer(TM) Wi-Fi 7 BE1750x 320MHz Wireless Network Adapter (BE200NGW)
[    4.064594] iwlwifi 0000:85:00.0: firmware: failed to load iwl-dbg-cfg.ini (-2)
[    4.064598] iwlwifi 0000:85:00.0: firmware: failed to load iwl-dbg-cfg.ini (-2)
[    4.064601] iwlwifi 0000:85:00.0: firmware: failed to load iwl-dbg-cfg.ini (-2)
[    4.065074] iwlwifi 0000:85:00.0: firmware: failed to load iwlwifi-gl-c0-fm-c0-100.ucode (-2)
[    4.065079] iwlwifi 0000:85:00.0: firmware: failed to load iwlwifi-gl-c0-fm-c0-100.ucode (-2)
[    4.065083] iwlwifi 0000:85:00.0: firmware: failed to load iwlwifi-gl-c0-fm-c0-100.ucode (-2)
[    4.065083] iwlwifi 0000:85:00.0: Direct firmware load for iwlwifi-gl-c0-fm-c0-100.ucode failed with error -2
[    4.065091] iwlwifi 0000:85:00.0: firmware: failed to load iwlwifi-gl-c0-fm-c0-99.ucode (-2)
[    4.065094] iwlwifi 0000:85:00.0: firmware: failed to load iwlwifi-gl-c0-fm-c0-99.ucode (-2)
[    4.065097] iwlwifi 0000:85:00.0: firmware: failed to load iwlwifi-gl-c0-fm-c0-99.ucode (-2)
[    4.065097] iwlwifi 0000:85:00.0: Direct firmware load for iwlwifi-gl-c0-fm-c0-99.ucode failed with error -2
[    4.065102] iwlwifi 0000:85:00.0: firmware: failed to load iwlwifi-gl-c0-fm-c0-98.ucode (-2)
[    4.065105] iwlwifi 0000:85:00.0: firmware: failed to load iwlwifi-gl-c0-fm-c0-98.ucode (-2)
[    4.065109] iwlwifi 0000:85:00.0: firmware: failed to load iwlwifi-gl-c0-fm-c0-98.ucode (-2)
[    4.065109] iwlwifi 0000:85:00.0: Direct firmware load for iwlwifi-gl-c0-fm-c0-98.ucode failed with error -2
[    4.071878] iwlwifi 0000:85:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.4.196
[    4.072050] iwlwifi 0000:85:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[    4.072053] iwlwifi 0000:85:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[    4.072055] iwlwifi 0000:85:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[    4.072056] iwlwifi 0000:85:00.0: loaded firmware version 97.8049d69b.0 gl-c0-fm-c0-97.ucode op_mode iwlmld

Yeah it _would_ be nice, but this is >2k changed lines, so ... not likely.

And the fix isn't in anything simple that's just part of it, it's in reworking the entire system.

We might revert that and reland it together with the other fixes, but then some other devices might not work right that do need the BW limit ... not sure, we'll need to decide.

Oh and regarding the antennas, looks like that switched you from "op_mode iwlmvm" to "op_mode iwlmld" now, so I guess that's an oversight there. Shouldn't have an effect on functionality though unless you were planning to actively *change* the antennas to just one of them.

Yes, you are right! Removing 97 ucode so that this happens:

[    4.059081] iwlwifi 0000:85:00.0: loaded firmware version 96.44729d4e.0 gl-c0-fm-c0-96.ucode op_mode iwlmvm


allows to see the antennas again. diff other than antennas between iwlmvm and iwlmld is:



in iwlmvm this is present:

		* [ PROT_RANGE_NEGO_AND_MEASURE ]: support for MFP in range measurement negotiation/procedure

in iwlmvm this is shown

		 * #{ managed } <= 1, #{ P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
		   total <= 3, #channels <= 2
		 * #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
		   total <= 3, #channels <= 1

PROT_RANGE_NEGO_AND_MEASURE should show up soon, it's already been implemented/ported. Probably hard to use though :)

the interface combinations should be there, but perhaps they're a bit different now that it's only newer devices?

>they're a bit different now 

Yes. (Compare to comment 13 attachment.)

This should also be fixed, for now perhaps with wrong names, with these reverts:

https://lore.kernel.org/linux-wireless/20250420090150.3508273-1-miriam.rachel.korenblit@intel.com/

The other work will take more time, but of course feel free to continue using it (so far we've only done some renaming as we merge it now.)

The issue with very big ping at 97 ucode is also fixed now on top of cleanup branch and in fact 98 ucode seems to improve on all min/avg/max/mdev.

(1 lost packet is just a bug in iputils https://github.com/iputils/iputils/issues/484 )
root@kali:~# ping -f 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 56(84) bytes of data.
.^C
--- 192.168.1.254 ping statistics ---
5765 packets transmitted, 5764 received, 0.0173461% packet loss, time 6267ms
rtt min/avg/max/mdev = 0.808/1.078/16.981/0.630 ms, ipg/ewma 1.087/0.930 ms

(mdev is population standard deviation)

without -f ping is also fine. Now ideally I would compare it to my main Realtek 4x4:3 device but I am lazy :)