Re: [PATCH ath-next v2 0/2] wifi: ath11k: fix SoC reboot on firmware crash on AHB

Julius Bairaktaris <[email protected]> Wed, 5 Aug 2026 12:48:00 +0200
Newsgroups org.kernel.vger.linux-wireless,org.infradead.lists.ath11k,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Ping, and some extra data since v1 only had my own bring-up tree behind it.

I have now reproduced this on a stock ath11k with no out-of-tree modules
loaded at all, on an otherwise unmodified OpenWrt mac80211 backports
6.18.39 build for the Xiaomi AX3600 (IPQ8074 hw2.0), firmware
WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1:

  # grep -c ath11k_nss /proc/kallsyms
  0
  # lsmod | grep -c qca
  0

Driving the debugfs simulate_fw_crash 'assert' trigger, panic captured
via ramoops:

  without this series: 1 assert  -> panic, SoC reboot
  with this series:    5 asserts -> 5 recoveries, boot_id unchanged,
                                    both radios back up

The panic is the one from the cover letter, verbatim:

  Unable to handle kernel read from unreadable memory at virtual address 0
  pc : ath11k_hal_srng_access_begin+0xc/0x60 [ath11k]
  lr : ath11k_dp_rx_process_mon_status+0x15c/0xd84 [ath11k]
  Call trace:
   ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P)
   ath11k_dp_rx_process_mon_rings+0xa0/0x5d4 [ath11k]
   ath11k_dp_service_srng+0x1f4/0x348 [ath11k]
   ath11k_ahb_ext_grp_napi_poll+0x34/0xd4 [ath11k_ahb]

So the AHB crash path really does reach ath11k_core_reconfigure_on_crash()
with the interrupts live on a plain upstream driver, not only on mine.

Two things I found while doing that run, both separate from this series
and neither ready to send:

 - the recovery leaves a list_del() warning from finish_wait() in
   ath11k_wmi_cmd_send(), once per recovery. ath11k_wmi_pdev_attach()
   re-runs init_waitqueue_head() on tx_ce_desc_wq on every recovery,
   under a task that is still queued on it.

 - once ath11k_core_reconfigure_on_crash() takes its err_hal_srng_deinit
   path, nothing calls ath11k_hal_srng_init() again, so srng_config stays
   freed and every later restart faults. A recovery that fails once looks
   unrecoverable by construction.

I will send those separately once I have them properly narrowed; flagging
them here only in case they are already known.

Thanks,
Julius