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