ath12k: WCN7850 fw stats permanently wedge after AP channel switch (v7.1.3, includes 8f153eb74546)

[Baochen Qiang]

On 7/16/2026 11:36 AM, Mike Garuccio wrote:
> Hi,
> 
>   On WCN7850, an AP channel switch (CSA) can permanently wedge the
>   firmware stats path: after the CSA, every WMI_REQUEST_VDEV_STAT
>   request times out with
> 
>     ath12k_wifi7_pci 0000:0d:00.0: time out while waiting for fw stats done
> 
>   repeating on every request until reboot or driver reload. The data
>   path is unaffected (still associated, traffic flows). Because
>   ath12k_mac_op_sta_statistics() falls back to the fw stats path exactly
>   when the cached rssi_comb is 0 (the post-CSA state), every station
>   statistics poll from NetworkManager then blocks ~6s in the driver,
>   producing a continuous stream of these messages (~14k/day) and
>   D-state polling processes.
> 
>   Environment:
>   - WCN7850 hw2.0 PCI, chip_id 0x2 chip_family 0x4 board_id 0xff
>     soc_id 0x40170200
>   - fw_version 0x1103006c fw_build_timestamp 2026-03-06 09:10
>     fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HMT.1.1.c7-00108-
>     QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
>   - Observed on 7.0.12 and 7.1.3 (distro-built stable kernels,
>     CachyOS). I verified v7.1.3 already contains 8f153eb74546
>     ("wifi: ath12k: use correct pdev id when requesting firmware
>     stats") and 7259b1a0e54c, so the duplicate-reply issue fixed
>     there is not the cause here.
>   - STA mode, single vdev, 5 GHz.
> 
>   Reproducer / correlation: three occurrences over five days, each one
>   starting seconds after a CSA from the AP, e.g.:
> 
>     Jul 14 03:48:01 wpa_supplicant[1403]: wlan0:
> CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5765 ht_enabled=1 ch_offset=0
> ch_width=20 MHz cf1=5765 cf2=0
>     Jul 14 03:48:02 wpa_supplicant[1403]: wlan0:
> CTRL-EVENT-CHANNEL-SWITCH freq=5765 ht_enabled=1 ch_offset=0
> ch_width=20 MHz cf1=5765 cf2=0
>     Jul 14 03:48:06 kernel: ath12k_wifi7_pci 0000:0d:00.0: time out
> while waiting for fw stats done
>     (then repeats every ~6s for the remaining 4h20m of that boot)
> 
>     Jul 15 00:10:01 wpa_supplicant[1273]: wlan0:
> CTRL-EVENT-STARTED-CHANNEL-SWITCH freq=5765 ht_enabled=1 ch_offset=-1
> ch_width=80 MHz cf1=5775 cf2=0
>     Jul 15 00:10:02 wpa_supplicant[1273]: wlan0:
> CTRL-EVENT-CHANNEL-SWITCH freq=5765 ht_enabled=1 ch_offset=-1
> ch_width=80 MHz cf1=5775 cf2=0
>     Jul 15 00:10:10 kernel: ath12k_wifi7_pci 0000:0d:00.0: time out
> while waiting for fw stats done
>     (then repeats every ~6s for ~23h until I reloaded the module)
> 
>   Boots without a CSA never show a single timeout. Uptime before the
>   CSA doesn't matter (one wedge happened 40 minutes into a boot, one
>   after ~2 days).
> 
>   Additional observations:
>   - It is always "time out while waiting for fw stats done", never
>     "time out while waiting for get fw stats" — i.e. fw_stats_complete
>     still fires, firmware is still sending WMI_UPDATE_STATS_EVENTID.
>   - The WMI pdev temperature path keeps working while wedged.
>   - Recovery: reloading the driver modules recovers immediately.
>     From code reading, nothing in the SSR/restart path resets
>     ar->fw_stats, so firmware recovery would not clear it.
> 
>   Analysis: this looks like ar->fw_stats.num_vdev_recvd getting out of
>   sync. In ath12k_wmi_fw_stats_process():
> 
>     is_end = ((++ar->fw_stats.num_vdev_recvd) == total_vdevs_started);
> 
>   num_vdev_recvd is only zeroed by ath12k_fw_stats_reset(), which
>   callers invoke only on the success path, and ath12k_mac_get_fw_stats()
>   does not reset it at request start. A CSA is executed as a vdev
>   restart; if a stats event is lost/late or arrives while
>   num_started_vdevs is transitioning, the request times out (no reset)
>   or a stray event increments the counter with no consumer. Either way
>   the counter is left non-zero, and since completion requires exact
>   equality and the counter only ever increments, no subsequent request
>   can ever complete — matching the observed permanent wedge on a kernel
>   that already has 8f153eb74546.
> 
>   Happy to test patches — the AP in question does a CSA roughly daily,
>   so I can usually confirm within a day or two.

Hi Mike, great report and analysis. I think the root cause is the unconditional increment
on num_started_vdevs even for the CSA case. In your single-vdev case: after a CSA
ar->num_started_vdevs becomes 2, but firmware still sends one VDEV_STAT event, so
++num_vdev_recvd reaches only 1, is_end never becomes true, and fw_stats_done never completes.

Can you try below diff ?

diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index ae874114dc51..83b3c68f328e 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -11447,7 +11447,9 @@ ath12k_mac_vdev_start_restart(struct ath12k_link_vif *arvif,
                                                   &arvif->reg_tpc_info);
        }

-       ar->num_started_vdevs++;
+       if (!restart)
+               ar->num_started_vdevs++;
+
        ath12k_dbg(ab, ATH12K_DBG_MAC,  "vdev %pM started, vdev_id %d\n",
                   ahvif->vif->addr, arvif->vdev_id);


> 
>   Thanks,
>   Mike Garuccio