[Bug 300075] iwlwifi/LinuxKPI: RX nearly stalls on a VHT160 association (~120 kB/s vs ~16 MB/s at VHT80); TX unaffected
Date: Sun, 25 Oct 2026 23:09:09 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=300075
Bug ID: 300075
Summary: iwlwifi/LinuxKPI: RX nearly stalls on a VHT160
association (~120 kB/s vs ~16 MB/s at VHT80); TX
unaffected
Product: Base System
Version: CURRENT
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: bugs@FreeBSD.org
Reporter: michal+freebsd@kilijanek.pl
CC: bz@FreeBSD.org
------------------------------------------------------------------------
Description
------------------------------------------------------------------------
With an Intel AX210 (iwlwifi, fw 89) associated to a VHT AP that offers
160 MHz on 5 GHz, receive throughput collapses, while transmit throughput
stays normal. Forcing 80 MHz with `ifconfig wlan0 -vht160` (set before
association) makes everything work at full speed.
Same session, same AP/BSS, card freshly re-attached for each run, and only
the vht160 flag changed (ifconfig_wlan0 in rc.conf). Measurements were
taken over wlan0 only (host routes via the AP, checked with the wlan0
byte counters):
VHT160 (vht/160) VHT80 (-vht160, vht/80+)
download 100 MiB 121 kB/s (only 11 MB 16.2 MB/s (6.5 s)
(proof.ovh.net) in 90 s, aborted)
RX packets/s 167 11690
RX packets per IRQ <1 9
upload 25 MB 11.4 MB/s 14.5 MB/s
TX rate after test 13M 360M
firmware errors none none
Earlier runs at VHT160 showed the same pattern: one 25 MB download was very
slow for about 45 s and then ran at about 1.4 MB/s. With
compat.linuxkpi.80211.hw_crypto=0, the VHT160 download stalled almost
completely (11 kB/s). Small packets (ping) work in all cases.
------------------------------------------------------------------------
AP / channel
------------------------------------------------------------------------
DFS channel 100, primary 5500 MHz, region PL/ETSI. The AP advertises:
VHTCAP<cap 0x0f8b79f6 rx_mcs_map 0xffaa tx_mcs_map 0xffaa>
-> supported channel width set = 1 (160 MHz, no 80+80),
EXT_NSS_BW = 0, 2 SS (MCS 0-9)
VHTOPMODE<chw 1 freq0_idx 106 freq1_idx 114>
-> 802.11-2016 style 160 MHz signaling (CCFS0 106, CCFS1 114)
What I ruled out from the code (main 175595ba6):
- net80211 set_vht_extchan() derives the 160 MHz center from
vht160_chan_ranges (5490-5650 for 5500 MHz), which gives a midpoint of
5570 MHz = channel 114. That matches the AP's CCFS1, so the 160 MHz
block itself appears correct.
- ieee80211_ht.c accepts this as VHT160 (|CCFS1 - CCFS0| == 8).
- EXT_NSS_BW is 0, so the EXT_NSS_BW branch in lkpi_sta_sync_vht_from_ni()
(which selects 160 MHz without considering reduced NSS) is not involved.
So I could not identify the cause. Because TX works and RX collapses, it
looks like the receive side or rate selection for 160 MHz (station
bandwidth / PHY context as programmed into the firmware), not channel
selection. I am happy to collect traces with a debug setting if that
would help.
Minor, related: changing vht160 with ifconfig on an already associated
vap and then running `wpa_cli reassociate` did not change the negotiated
width; the flag only takes effect when set before association.
------------------------------------------------------------------------
Environment / workaround
------------------------------------------------------------------------
Machine: Lenovo ThinkPad T14 Gen 2a, Intel AX210 (8086:2725 sub 8086:0024)
Firmware: 89.735b75a4.0 (wifi-firmware-iwlwifi-kmod-ax210-20260410)
Config: compat.linuxkpi.80211.hw_crypto=1,
ifconfig_wlan0="WPA DHCP -ampdurx -vht160 -vht80p80"
(-ampdurx because of bug 300064)
Kernel: main 175595ba6 + LinuxKPI NAPI change (freebsd-src PR #2497) and
the linux_pci.c fix from bug 300062; config = GENERIC + platform
devices (details in bug 300064 comments)
Workaround: -vht160 (VHT80): 100 MiB download at 16 MB/s, upload 14.5 MB/s.
--
You are receiving this mail because:
You are the assignee for the bug.