[Bug 300064] iwlwifi AX210 (fw 89): firmware assert 0x2010350B on RX BA start (ADDBA from AP) with the default firmware-package tunables

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=300064

            Bug ID: 300064
           Summary: iwlwifi AX210 (fw 89): firmware assert 0x2010350B on
                    RX BA start (ADDBA from AP) with the default
                    firmware-package tunables
           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
------------------------------------------------------------------------

On an Intel AX210 (pci 8086:2725 sub 8086:0024) with firmware
89.735b75a4.0 (ty-a0-gf-a0-89.ucode), the firmware crashes a few seconds
after every association as soon as the AP starts an RX block-ack session.
This happens with the tunables shipped by wifi-firmware-iwlwifi-kmod-ax210
(/boot/loader.conf.d/iwlwifi-ax210.conf):

  compat.linuxkpi.80211.hw_crypto=1
  compat.linuxkpi.iwlwifi_11n_disable=0
  compat.linuxkpi.iwlwifi_disable_11n=0
  compat.linuxkpi.iwlwifi_disable_11ac=0

(The third line does not correspond to an existing sysctl:
compat.linuxkpi.iwlwifi_disable_11n is reported as an unknown oid.)

Reproduced on purpose on 2026-10-25, 3 s after CTRL-EVENT-CONNECTED:

  iwlwifi0: Microcode SW error detected. Restarting 0x0.
  iwlwifi0: 0x00000071 | NMI_INTERRUPT_UMAC_FATAL
  iwlwifi0: 0x2010350B | ADVANCED_SYSASSERT
  iwlwifi0: UMAC CURRENT PC: 0x804a5aec
  iwlwifi0: FW error in SYNC CMD UNKNOWN
  #1 iwl_trans_pcie_send_hcmd+0x3f0
  #2 iwl_trans_send_cmd+0x6a
  #3 iwl_mvm_send_cmd_status+0x4e
  #4 iwl_mvm_sta_rx_agg+0x296
  #5 iwl_mvm_mac_ampdu_action+0x253
  #6 lkpi_ic_ampdu_rx_start+0x151
  #7 ht_recv_action_ba_addba_request+0x148
  #8 lkpi_iv_sta_recv_mgmt+0x19
  #9 sta_input+0xbc8
  #10 ieee80211_input_mimo+0x1f0
  #11 lkpi_80211_lhw_rxq_task+0x145
  iwlwifi0: lkpi_ic_ampdu_rx_start: mo_ampdu_action returned -5.
  iwlwifi0: Device error - SW reset

i.e. the firmware asserts while processing the RX BAID allocation
(RX_BAID_ALLOCATION_CONFIG_CMD, BAID_ML_SUPPORT path) sent from
iwl_mvm_sta_rx_agg() for the AP's ADDBA request.  Before the deliberate
reproduction it happened on every boot (9 of 9 boots over 3 days, the
same assert each time).

The same assert happened earlier with hw_crypto=1 and default ifconfig
flags.  It does NOT happen with:
 - hw_crypto=1 and `ifconfig wlan0 -ampdurx` (no RX BA): no firmware
   crash, about 1.4 MB/s download;
 - hw_crypto=0 (LinuxKPI then clears IEEE80211_FHT_AMPDU_RX itself, see
   lkpi_ic_vap_create()): no firmware crash, about 1.4 MB/s.
So the trigger is the RX BA session start, not hardware crypto itself.
Without RX aggregation, 2.4 GHz HT20 download is limited to about
11 Mbit/s at a 130 Mbit/s PHY rate.

------------------------------------------------------------------------
Throughput without RX aggregation, and 5 GHz
------------------------------------------------------------------------

All download numbers below were measured over wlan0 only (host routes via
the AP, checked with the wlan0 byte counters).

- The download ceiling is about 1400 frames/s (about 1.4 MB/s).  During
  a download there were about 1290 iwlwifi interrupts/s for about 1450
  RX frames/s, i.e. roughly one frame per interrupt, and about 1000
  TX frames/s (TCP ACKs).
- The ceiling does not depend on the PHY rate: it is the same at 130M
  (2.4 GHz HT20) and at 360M (5 GHz VHT).  Without RX A-MPDU every MPDU
  is a separate exchange, so only a working RX BA session can raise it.
  (Upload, where the firmware aggregates, reached about 39 Mbit/s.)
- 5 GHz (same AP, DFS channel 100, VHT) with hw_crypto=0 is essentially
  unusable: TCP download stalls (11 kB/s at VHT160, 44 kB/s at VHT80,
  nothing with -vht), with no firmware crash.
- 5 GHz with hw_crypto=1 and -ampdurx works: the first ~45 s were very
  slow (about 76 kB/s), then 25 MB downloaded at 1.37 MB/s.  That is the
  same ceiling as on 2.4 GHz.  Software crypto therefore appears to
  break the VHT data path, separately from the RX BA assert.
- `ifconfig wlan0 -vht160` followed by `wpa_cli reassociate` did not
  change the negotiated width (it stayed vht/160).

Regulatory note: wlan0 came up with regdomain FCC / country US by
default.  DFS channels (where this AP's 5 GHz is) only became visible
after `ifconfig wlan0 create wlandev iwlwifi0 country PL regdomain ETSI`.

------------------------------------------------------------------------
What I checked (code reading, main 175595ba6)
------------------------------------------------------------------------

lkpi_ic_ampdu_rx_start() passes buf_size (BAPS_BUFSIZ, 0 -> 64, clamped to
IEEE80211_MAX_AMPDU_BUF_HT and max_rx_aggregation_subframes), ssn, tid,
timeout and amsdu, and calls mo_ampdu_action() before net80211 sends the
ADDBA response, which is the same order as mac80211.  iwl_mvm_fw_baid_op_cmd()
sends sta_id_mask = BIT(deflink.sta_id), tid, ssn, win_size.  I found no
obviously wrong parameter, so the difference from Linux (where the same
firmware works with RX aggregation) is probably in the station/link state
programmed before the ADDBA (for example the AUTHORIZED transition is
sent when entering RUN; see the IMPROVE() notes in lkpi_sta_assoc_to_run()).
Tracing the STA_CONFIG / RX_BAID commands would be the next step.

------------------------------------------------------------------------
Packaging note
------------------------------------------------------------------------

Since the firmware package ships hw_crypto=1 + 11n for AX210, a fresh
install crashes the firmware on the first ADDBA.  A user workaround that
survives package upgrades is `-ampdurx` in ifconfig_wlan0, and/or
compat.linuxkpi.80211.hw_crypto=0 in /boot/loader.conf.local.

------------------------------------------------------------------------
Environment
------------------------------------------------------------------------

Machine:  Lenovo ThinkPad T14 Gen 2a (20XLS34M00)
Package:  wifi-firmware-iwlwifi-kmod-ax210-20260410
Kernel:   packaged GENERIC main-n290312-91bff7d7ed46 (original crashes) and
          main 175595ba6 (reproduction; + LinuxKPI NAPI change,
          freebsd-src PR #2497)
AP:       WPA2-PSK CCMP, 2.4 GHz ch 6, HT20, no PMF

After the crash the system stayed usable this time: vap teardown with the
dead firmware (LINK_CONFIG_CMD/MAC_CONFIG_CMD action 3) completed in 1 s.
On 2026-10-25 12:23 the same situation hung the whole machine on the
packaged kernel (see freebsd-src PR #2497).

-- 
You are receiving this mail because:
You are the assignee for the bug.