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

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

[Julius Bairaktaris]

On IPQ8074 every firmware assert takes the whole SoC down. The DP NAPI
keeps polling while ath11k_core_reconfigure_on_crash() frees the data
path underneath it, and dereferences a ring the teardown has already
cleared.

The interrupts used to be disabled at the top of that function.
commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
moved the disable into ath11k_core_reset(), which AHB parts never reach
on a real firmware crash: reset_work is queued only from mhi.c and from
the debugfs hw-restart handler. Patch 2 puts the disable back on the
crash path. Patch 1 is a prerequisite - the CE half of the quiesce is a
no-op on AHB today because the bus never implemented the hif ops.

Reproduced and fixed on a Xiaomi AX3600 (IPQ8074 hw2.0), with no
out-of-tree modules loaded, using the debugfs simulate_fw_crash
'assert' trigger:

  before: 2/2 asserts panic in ath11k_dp_rx_process_mon_status() and
          reboot the SoC
  after:  3/3 asserts recover, 5 firmware boots across a single 397 s
          uptime, no panics, both radios stay up

Note the debugfs 'hw-restart' trigger does not reproduce this, since it
goes through ath11k_core_reset() - the one path that still disables the
interrupts. Only a real firmware assert does.

Patch 1 is by inspection: it makes ath11k_hif_ce_irq_disable() take
effect on AHB, which also fixes the existing call in
ath11k_core_reset(). I have not managed to trigger a CE-side crash on
its own, so if you would rather see that split out or dropped, say so.

Changes in v2 (no functional change, review comments from Jeff on 2/2):
- separate the ath-specific Tested-on tag from the upstream tags with a
  blank line
- use the standard kernel block comment style, with /* on its own line

v1: https://lore.kernel.org/ath11k/20260725141757.1316877-1-julius@bairaktaris.de/

Julius Bairaktaris (2):
  wifi: ath11k: implement CE interrupt enable/disable for AHB
  wifi: ath11k: disable interrupts during firmware crash recovery

 drivers/net/wireless/ath/ath11k/ahb.c  |  9 ++++++++-
 drivers/net/wireless/ath/ath11k/core.c | 10 ++++++++++
 2 files changed, 18 insertions(+), 1 deletion(-)

-- 
2.53.0

[PATCH ath-next v2 1/2] wifi: ath11k: implement CE interrupt enable/disable for AHB

[Julius Bairaktaris]

ath11k_core_reset() calls ath11k_hif_ce_irq_disable() right before it
powers the target down, but ath11k_ahb_hif_ops_ipq8074 never set the
ce_irq_enable/ce_irq_disable pair, and ath11k_hif_ce_irq_disable() does
nothing when the op is NULL. On AHB the copy engine interrupts and their
tasklets therefore stay live across rproc_shutdown(), where the register
space they touch is no longer accessible.

Wire the ops up. The sequence is the one ath11k_ahb_stop() already runs,
factored into a helper and reused, so behaviour on the stop path is
unchanged. wcn6750 is not affected: it uses the pcic ops, which
implement the pair already.

Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
---
 drivers/net/wireless/ath/ath11k/ahb.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
index f566d699d074..72da6919c277 100644
--- a/drivers/net/wireless/ath/ath11k/ahb.c
+++ b/drivers/net/wireless/ath/ath11k/ahb.c
@@ -391,12 +391,17 @@ static void ath11k_ahb_ext_irq_disable(struct ath11k_base *ab)
 	ath11k_ahb_sync_ext_irqs(ab);
 }
 
-static void ath11k_ahb_stop(struct ath11k_base *ab)
+static void ath11k_ahb_ce_irq_disable_sync(struct ath11k_base *ab)
 {
 	if (!test_bit(ATH11K_FLAG_CRASH_FLUSH, &ab->dev_flags))
 		ath11k_ahb_ce_irqs_disable(ab);
 	ath11k_ahb_sync_ce_irqs(ab);
 	ath11k_ahb_kill_tasklets(ab);
+}
+
+static void ath11k_ahb_stop(struct ath11k_base *ab)
+{
+	ath11k_ahb_ce_irq_disable_sync(ab);
 	timer_delete_sync(&ab->rx_replenish_retry);
 	ath11k_ce_cleanup_pipes(ab);
 }
@@ -773,6 +778,8 @@ static const struct ath11k_hif_ops ath11k_ahb_hif_ops_ipq8074 = {
 	.map_service_to_pipe = ath11k_ahb_map_service_to_pipe,
 	.power_down = ath11k_ahb_power_down,
 	.power_up = ath11k_ahb_power_up,
+	.ce_irq_enable = ath11k_ahb_ce_irqs_enable,
+	.ce_irq_disable = ath11k_ahb_ce_irq_disable_sync,
 };
 
 static const struct ath11k_hif_ops ath11k_ahb_hif_ops_wcn6750 = {
-- 
2.53.0

[PATCH ath-next v2 2/2] wifi: ath11k: disable interrupts during firmware crash recovery

[Julius Bairaktaris]

On IPQ8074 a firmware assert reboots the SoC:

  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]
   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]
   __napi_poll+0x38/0x188
   net_rx_action+0x120/0x2c0

ath11k_core_reconfigure_on_crash() tears the data path down with
ath11k_dp_pdev_free(), ath11k_dp_free() and ath11k_hal_srng_clear(),
which memsets the ring list. The DP NAPI is still running while that
happens, so it services a ring whose address pointer has just been
cleared.

That function used to disable the interrupts first, until
commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
moved the disable into ath11k_core_reset(). reset_work is only queued
from mhi.c and from the debugfs hw-restart handler, so AHB parts never
run it on a real firmware crash. Their recovery goes QMI server exit ->
restart_work -> ath11k_core_reconfigure_on_crash() ->
ath11k_core_qmi_firmware_ready(), and nothing disables the interrupts
anywhere along it.

Disable them again on the crash path. The reset path has already done
so by the time it gets here, hence the ab->is_reset check.

This is also why the debugfs hw-restart trigger never showed the
problem: it goes through ath11k_core_reset(), the one path that still
had the disable.

Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1

Fixes: d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
---
 drivers/net/wireless/ath/ath11k/core.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
index 8039124e7832..d2ed6a0ea7e3 100644
--- a/drivers/net/wireless/ath/ath11k/core.c
+++ b/drivers/net/wireless/ath/ath11k/core.c
@@ -2334,6 +2334,16 @@ static int ath11k_core_reconfigure_on_crash(struct ath11k_base *ab)
 
 	mutex_lock(&ab->core_lock);
 	ath11k_thermal_unregister(ab);
+
+	/*
+	 * ath11k_core_reset() already disabled the interrupts on the reset
+	 * path; only the firmware crash path reaches here with them live.
+	 */
+	if (!ab->is_reset) {
+		ath11k_hif_irq_disable(ab);
+		ath11k_hif_ce_irq_disable(ab);
+	}
+
 	ath11k_dp_pdev_free(ab);
 	ath11k_cfr_deinit(ab);
 	ath11k_spectral_deinit(ab);
-- 
2.53.0

Re: [PATCH ath-next v2 2/2] wifi: ath11k: disable interrupts during firmware crash recovery

[Marek Szyprowski]

On 27.07.2026 00:19, Julius Bairaktaris wrote:
> On IPQ8074 a firmware assert reboots the SoC:
>
>   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]
>    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]
>    __napi_poll+0x38/0x188
>    net_rx_action+0x120/0x2c0
>
> ath11k_core_reconfigure_on_crash() tears the data path down with
> ath11k_dp_pdev_free(), ath11k_dp_free() and ath11k_hal_srng_clear(),
> which memsets the ring list. The DP NAPI is still running while that
> happens, so it services a ring whose address pointer has just been
> cleared.
>
> That function used to disable the interrupts first, until
> commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
> moved the disable into ath11k_core_reset(). reset_work is only queued
> from mhi.c and from the debugfs hw-restart handler, so AHB parts never
> run it on a real firmware crash. Their recovery goes QMI server exit ->
> restart_work -> ath11k_core_reconfigure_on_crash() ->
> ath11k_core_qmi_firmware_ready(), and nothing disables the interrupts
> anywhere along it.
>
> Disable them again on the crash path. The reset path has already done
> so by the time it gets here, hence the ab->is_reset check.
>
> This is also why the debugfs hw-restart trigger never showed the
> problem: it goes through ath11k_core_reset(), the one path that still
> had the disable.
>
> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
>
> Fixes: d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
> Assisted-by: Claude:claude-opus-5
> Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>


This patch landed recently in linux-next as commit f7a74e131d3f ("wifi: ath11k:
disable interrupts during firmware crash recovery"). In my tests I found that it
causes a regression on QCOM RB5 board during system suspend/resume cycle
(s2idle):


# time rtcwake -s10 -mmem
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:05:43 1970
PM: suspend entry (s2idle)
Filesystems sync: 0.037 seconds
Freezing user space processes
Freezing user space processes completed (elapsed 0.008 seconds)
OOM killer disabled.
Freezing remaining freezable tasks
Freezing remaining freezable tasks completed (elapsed 0.004 seconds)
printk: Suspending console(s) (use no_console_suspend to debug)
dwc3-qcom-legacy a6f8800.usb: port-1 HS-PHY not in L2
qcom-pcie 1c08000.pcie: Device not found
qcom-pcie 1c10000.pcie: Device not found
qcom-pcie 1c00000.pcie: PCIe Gen.2 x1 link up
mhi mhi0: Requested to power ON
mhi mhi0: Power on setup success
mhi mhi0: Wait for device to enter SBL or Mission mode
ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x4 soc_id 0xffffffff
ath11k_pci 0000:01:00.0: fw_version 0x10121492 fw_build_timestamp 2021-11-04 11:23 fw_build_id
ath11k_pci 0000:01:00.0: failed to receive control response completion, polling..
ath11k_pci 0000:01:00.0: Service connect timeout
ath11k_pci 0000:01:00.0: failed to connect to HTT: -110
ath11k_pci 0000:01:00.0: failed to start core: -110
ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery
ax88179_178a 2-1.1:1.0 eth0: ax88179 - Link status is: 1
ath11k_pci 0000:01:00.0: timeout while waiting for restart complete
ath11k_pci 0000:01:00.0: failed to resume core: -110
ath11k_pci 0000:01:00.0: PM: dpm_run_callback(): pci_pm_resume returns -110
ath11k_pci 0000:01:00.0: PM: failed to resume async: error -110
ath11k_pci 0000:01:00.0: failed to send WMI_PDEV_SET_PARAM cmd
ath11k_pci 0000:01:00.0: failed to enable PMF QOS: (-108
------------[ cut here ]------------
Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
WARNING: net/mac80211/util.c:1957 at ieee80211_reconfig+0x508/0x1ed0 [mac80211], CPU#0: kworker/u32:1/61
Modules linked in: ...
CPU: 0 UID: 0 PID: 61 Comm: kworker/u32:1 Not tainted 7.2.0+ #13652 PREEMPT
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
Workqueue: async async_run_entry_fn
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ieee80211_reconfig+0x508/0x1ed0 [mac80211]
lr : ieee80211_reconfig+0x508/0x1ed0 [mac80211]
..
Call trace:
 ieee80211_reconfig+0x508/0x1ed0 [mac80211] (P)
 ieee80211_resume+0x4c/0x68 [mac80211]
 wiphy_resume+0xb0/0x28c [cfg80211]
 dpm_run_callback+0x8c/0x158
 device_resume+0x128/0x36c
 async_resume+0x24/0x3c
 async_run_entry_fn+0x34/0xe0
 process_one_work+0x24c/0x844
 worker_thread+0x1bc/0x368
 kthread+0x134/0x140
 ret_from_fork+0x10/0x20
irq event stamp: 701092
hardirqs last  enabled at (701091): [<ffffac645b5ec938>] vprintk_store+0x3e4/0x49c
hardirqs last disabled at (701092): [<ffffac645c7dc11c>] el1_brk64+0x20/0x60
softirqs last  enabled at (701078): [<ffffac640ef2c358>] ath11k_htc_send+0x264/0x2f0 [ath11k]
softirqs last disabled at (701076): [<ffffac640ef2c344>] ath11k_htc_send+0x250/0x2f0 [ath11k]
---[ end trace 0000000000000000 ]---
------------[ cut here ]------------
WARNING: net/mac80211/driver-ops.c:41 at drv_stop+0x24c/0x264 [mac80211], CPU#0: kworker/u32:1/61
Modules linked in: ...
CPU: 0 UID: 0 PID: 61 Comm: kworker/u32:1 Tainted: G        W           7.2.0+ #13652 PREEMPT
Tainted: [W]=WARN
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
Workqueue: async async_run_entry_fn
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drv_stop+0x24c/0x264 [mac80211]
lr : drv_stop+0x23c/0x264 [mac80211]
...
Call trace:
 drv_stop+0x24c/0x264 [mac80211] (P)
 ieee80211_stop_device+0x80/0x90 [mac80211]
 ieee80211_do_stop+0x614/0x960 [mac80211]
 ieee80211_stop+0x68/0xd8 [mac80211]
 __dev_close_many+0xe0/0x224
 netif_close_many+0x8c/0x1c0
 netif_close+0x70/0x84
 dev_close+0x38/0x60
 cfg80211_shutdown_all_interfaces+0x4c/0x138 [cfg80211]
 wiphy_resume+0xec/0x28c [cfg80211]
 dpm_run_callback+0x8c/0x158
 device_resume+0x128/0x36c
 async_resume+0x24/0x3c
 async_run_entry_fn+0x34/0xe0
 process_one_work+0x24c/0x844
 worker_thread+0x1bc/0x368
 kthread+0x134/0x140
 ret_from_fork+0x10/0x20
irq event stamp: 701378
hardirqs last  enabled at (701377): [<ffffac645c7f21e4>] _raw_spin_unlock_irqrestore+0x6c/0x70
hardirqs last disabled at (701378): [<ffffac645c7dc11c>] el1_brk64+0x20/0x60
softirqs last  enabled at (701366): [<ffffac640ed4dedc>] ieee80211_stop_device+0x2c/0x90 [mac80211]
softirqs last disabled at (701360): [<ffffac640ed4dec8>] ieee80211_stop_device+0x18/0x90 [mac80211]
---[ end trace 0000000000000000 ]---
ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume [cfg80211] returns -108
ieee80211 phy0: PM: failed to resume async: error -108
OOM killer enabled.
Restarting tasks: Starting
Restarting tasks: Done
random: crng reseeded on system resumption
PM: suspend exit


Before that commit it worked fine:

# time rtcwake -s10 -mmem
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:05:42 1970
PM: suspend entry (s2idle)
Filesystems sync: 0.042 seconds
Freezing user space processes
Freezing user space processes completed (elapsed 0.005 seconds)
OOM killer disabled.
Freezing remaining freezable tasks
Freezing remaining freezable tasks completed (elapsed 0.003 seconds)
printk: Suspending console(s) (use no_console_suspend to debug)
dwc3-qcom-legacy a6f8800.usb: port-1 HS-PHY not in L2
qcom-pcie 1c08000.pcie: Device not found
qcom-pcie 1c10000.pcie: Device not found
qcom-pcie 1c00000.pcie: PCIe Gen.2 x1 link up
mhi mhi0: Requested to power ON
mhi mhi0: Power on setup success
mhi mhi0: Wait for device to enter SBL or Mission mode
ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x4 soc_id 0xffffffff
ath11k_pci 0000:01:00.0: fw_version 0x10121492 fw_build_timestamp 2021-11-04 11:23 fw_build_id
OOM killer enabled.
Restarting tasks: Starting
Restarting tasks: Done
random: crng reseeded on system resumption
PM: suspend exit


> ---
>  drivers/net/wireless/ath/ath11k/core.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> index 8039124e7832..d2ed6a0ea7e3 100644
> --- a/drivers/net/wireless/ath/ath11k/core.c
> +++ b/drivers/net/wireless/ath/ath11k/core.c
> @@ -2334,6 +2334,16 @@ static int ath11k_core_reconfigure_on_crash(struct ath11k_base *ab)
>  
>  	mutex_lock(&ab->core_lock);
>  	ath11k_thermal_unregister(ab);
> +
> +	/*
> +	 * ath11k_core_reset() already disabled the interrupts on the reset
> +	 * path; only the firmware crash path reaches here with them live.
> +	 */
> +	if (!ab->is_reset) {
> +		ath11k_hif_irq_disable(ab);
> +		ath11k_hif_ce_irq_disable(ab);
> +	}
> +
>  	ath11k_dp_pdev_free(ab);
>  	ath11k_cfr_deinit(ab);
>  	ath11k_spectral_deinit(ab);

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH ath-next v2 2/2] wifi: ath11k: disable interrupts during firmware crash recovery

[Jeff Johnson]

On 9/11/2026 12:53 AM, Marek Szyprowski wrote:
> On 27.07.2026 00:19, Julius Bairaktaris wrote:
>> On IPQ8074 a firmware assert reboots the SoC:
>>
>>   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]
>>    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]
>>    __napi_poll+0x38/0x188
>>    net_rx_action+0x120/0x2c0
>>
>> ath11k_core_reconfigure_on_crash() tears the data path down with
>> ath11k_dp_pdev_free(), ath11k_dp_free() and ath11k_hal_srng_clear(),
>> which memsets the ring list. The DP NAPI is still running while that
>> happens, so it services a ring whose address pointer has just been
>> cleared.
>>
>> That function used to disable the interrupts first, until
>> commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
>> moved the disable into ath11k_core_reset(). reset_work is only queued
>> from mhi.c and from the debugfs hw-restart handler, so AHB parts never
>> run it on a real firmware crash. Their recovery goes QMI server exit ->
>> restart_work -> ath11k_core_reconfigure_on_crash() ->
>> ath11k_core_qmi_firmware_ready(), and nothing disables the interrupts
>> anywhere along it.
>>
>> Disable them again on the crash path. The reset path has already done
>> so by the time it gets here, hence the ab->is_reset check.
>>
>> This is also why the debugfs hw-restart trigger never showed the
>> problem: it goes through ath11k_core_reset(), the one path that still
>> had the disable.
>>
>> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
>>
>> Fixes: d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
>> Assisted-by: Claude:claude-opus-5
>> Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
> 
> 
> This patch landed recently in linux-next as commit f7a74e131d3f ("wifi: ath11k:
> disable interrupts during firmware crash recovery"). In my tests I found that it
> causes a regression on QCOM RB5 board during system suspend/resume cycle
> (s2idle):
> 
> 
> # time rtcwake -s10 -mmem
> rtcwake: assuming RTC uses UTC ...
> rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:05:43 1970
> PM: suspend entry (s2idle)
> Filesystems sync: 0.037 seconds
> Freezing user space processes
> Freezing user space processes completed (elapsed 0.008 seconds)
> OOM killer disabled.
> Freezing remaining freezable tasks
> Freezing remaining freezable tasks completed (elapsed 0.004 seconds)
> printk: Suspending console(s) (use no_console_suspend to debug)
> dwc3-qcom-legacy a6f8800.usb: port-1 HS-PHY not in L2
> qcom-pcie 1c08000.pcie: Device not found
> qcom-pcie 1c10000.pcie: Device not found
> qcom-pcie 1c00000.pcie: PCIe Gen.2 x1 link up
> mhi mhi0: Requested to power ON
> mhi mhi0: Power on setup success
> mhi mhi0: Wait for device to enter SBL or Mission mode
> ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x4 soc_id 0xffffffff
> ath11k_pci 0000:01:00.0: fw_version 0x10121492 fw_build_timestamp 2021-11-04 11:23 fw_build_id
> ath11k_pci 0000:01:00.0: failed to receive control response completion, polling..
> ath11k_pci 0000:01:00.0: Service connect timeout
> ath11k_pci 0000:01:00.0: failed to connect to HTT: -110
> ath11k_pci 0000:01:00.0: failed to start core: -110
> ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery
> ax88179_178a 2-1.1:1.0 eth0: ax88179 - Link status is: 1
> ath11k_pci 0000:01:00.0: timeout while waiting for restart complete
> ath11k_pci 0000:01:00.0: failed to resume core: -110
> ath11k_pci 0000:01:00.0: PM: dpm_run_callback(): pci_pm_resume returns -110
> ath11k_pci 0000:01:00.0: PM: failed to resume async: error -110
> ath11k_pci 0000:01:00.0: failed to send WMI_PDEV_SET_PARAM cmd
> ath11k_pci 0000:01:00.0: failed to enable PMF QOS: (-108
> ------------[ cut here ]------------
> Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue.
> WARNING: net/mac80211/util.c:1957 at ieee80211_reconfig+0x508/0x1ed0 [mac80211], CPU#0: kworker/u32:1/61
> Modules linked in: ...
> CPU: 0 UID: 0 PID: 61 Comm: kworker/u32:1 Not tainted 7.2.0+ #13652 PREEMPT
> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
> Workqueue: async async_run_entry_fn
> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : ieee80211_reconfig+0x508/0x1ed0 [mac80211]
> lr : ieee80211_reconfig+0x508/0x1ed0 [mac80211]
> ..
> Call trace:
>  ieee80211_reconfig+0x508/0x1ed0 [mac80211] (P)
>  ieee80211_resume+0x4c/0x68 [mac80211]
>  wiphy_resume+0xb0/0x28c [cfg80211]
>  dpm_run_callback+0x8c/0x158
>  device_resume+0x128/0x36c
>  async_resume+0x24/0x3c
>  async_run_entry_fn+0x34/0xe0
>  process_one_work+0x24c/0x844
>  worker_thread+0x1bc/0x368
>  kthread+0x134/0x140
>  ret_from_fork+0x10/0x20
> irq event stamp: 701092
> hardirqs last  enabled at (701091): [<ffffac645b5ec938>] vprintk_store+0x3e4/0x49c
> hardirqs last disabled at (701092): [<ffffac645c7dc11c>] el1_brk64+0x20/0x60
> softirqs last  enabled at (701078): [<ffffac640ef2c358>] ath11k_htc_send+0x264/0x2f0 [ath11k]
> softirqs last disabled at (701076): [<ffffac640ef2c344>] ath11k_htc_send+0x250/0x2f0 [ath11k]
> ---[ end trace 0000000000000000 ]---
> ------------[ cut here ]------------
> WARNING: net/mac80211/driver-ops.c:41 at drv_stop+0x24c/0x264 [mac80211], CPU#0: kworker/u32:1/61
> Modules linked in: ...
> CPU: 0 UID: 0 PID: 61 Comm: kworker/u32:1 Tainted: G        W           7.2.0+ #13652 PREEMPT
> Tainted: [W]=WARN
> Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
> Workqueue: async async_run_entry_fn
> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> pc : drv_stop+0x24c/0x264 [mac80211]
> lr : drv_stop+0x23c/0x264 [mac80211]
> ...
> Call trace:
>  drv_stop+0x24c/0x264 [mac80211] (P)
>  ieee80211_stop_device+0x80/0x90 [mac80211]
>  ieee80211_do_stop+0x614/0x960 [mac80211]
>  ieee80211_stop+0x68/0xd8 [mac80211]
>  __dev_close_many+0xe0/0x224
>  netif_close_many+0x8c/0x1c0
>  netif_close+0x70/0x84
>  dev_close+0x38/0x60
>  cfg80211_shutdown_all_interfaces+0x4c/0x138 [cfg80211]
>  wiphy_resume+0xec/0x28c [cfg80211]
>  dpm_run_callback+0x8c/0x158
>  device_resume+0x128/0x36c
>  async_resume+0x24/0x3c
>  async_run_entry_fn+0x34/0xe0
>  process_one_work+0x24c/0x844
>  worker_thread+0x1bc/0x368
>  kthread+0x134/0x140
>  ret_from_fork+0x10/0x20
> irq event stamp: 701378
> hardirqs last  enabled at (701377): [<ffffac645c7f21e4>] _raw_spin_unlock_irqrestore+0x6c/0x70
> hardirqs last disabled at (701378): [<ffffac645c7dc11c>] el1_brk64+0x20/0x60
> softirqs last  enabled at (701366): [<ffffac640ed4dedc>] ieee80211_stop_device+0x2c/0x90 [mac80211]
> softirqs last disabled at (701360): [<ffffac640ed4dec8>] ieee80211_stop_device+0x18/0x90 [mac80211]
> ---[ end trace 0000000000000000 ]---
> ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume [cfg80211] returns -108
> ieee80211 phy0: PM: failed to resume async: error -108
> OOM killer enabled.
> Restarting tasks: Starting
> Restarting tasks: Done
> random: crng reseeded on system resumption
> PM: suspend exit
> 
> 
> Before that commit it worked fine:
> 
> # time rtcwake -s10 -mmem
> rtcwake: assuming RTC uses UTC ...
> rtcwake: wakeup from "mem" using /dev/rtc0 at Thu Jan  1 00:05:42 1970
> PM: suspend entry (s2idle)
> Filesystems sync: 0.042 seconds
> Freezing user space processes
> Freezing user space processes completed (elapsed 0.005 seconds)
> OOM killer disabled.
> Freezing remaining freezable tasks
> Freezing remaining freezable tasks completed (elapsed 0.003 seconds)
> printk: Suspending console(s) (use no_console_suspend to debug)
> dwc3-qcom-legacy a6f8800.usb: port-1 HS-PHY not in L2
> qcom-pcie 1c08000.pcie: Device not found
> qcom-pcie 1c10000.pcie: Device not found
> qcom-pcie 1c00000.pcie: PCIe Gen.2 x1 link up
> mhi mhi0: Requested to power ON
> mhi mhi0: Power on setup success
> mhi mhi0: Wait for device to enter SBL or Mission mode
> ath11k_pci 0000:01:00.0: chip_id 0x0 chip_family 0xb board_id 0x4 soc_id 0xffffffff
> ath11k_pci 0000:01:00.0: fw_version 0x10121492 fw_build_timestamp 2021-11-04 11:23 fw_build_id
> OOM killer enabled.
> Restarting tasks: Starting
> Restarting tasks: Done
> random: crng reseeded on system resumption
> PM: suspend exit

Baochen, can you look into this?

Thanks!
/jeff

Re: [PATCH ath-next v2 2/2] wifi: ath11k: disable interrupts during firmware crash recovery

[Baochen Qiang]

On 9/11/2026 3:53 PM, Marek Szyprowski wrote:
> On 27.07.2026 00:19, Julius Bairaktaris wrote:
>> On IPQ8074 a firmware assert reboots the SoC:
>>
>>   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]
>>    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]
>>    __napi_poll+0x38/0x188
>>    net_rx_action+0x120/0x2c0
>>
>> ath11k_core_reconfigure_on_crash() tears the data path down with
>> ath11k_dp_pdev_free(), ath11k_dp_free() and ath11k_hal_srng_clear(),
>> which memsets the ring list. The DP NAPI is still running while that
>> happens, so it services a ring whose address pointer has just been
>> cleared.
>>
>> That function used to disable the interrupts first, until
>> commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
>> moved the disable into ath11k_core_reset(). reset_work is only queued
>> from mhi.c and from the debugfs hw-restart handler, so AHB parts never
>> run it on a real firmware crash. Their recovery goes QMI server exit ->
>> restart_work -> ath11k_core_reconfigure_on_crash() ->
>> ath11k_core_qmi_firmware_ready(), and nothing disables the interrupts
>> anywhere along it.
>>
>> Disable them again on the crash path. The reset path has already done
>> so by the time it gets here, hence the ab->is_reset check.
>>
>> This is also why the debugfs hw-restart trigger never showed the
>> problem: it goes through ath11k_core_reset(), the one path that still
>> had the disable.
>>
>> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
>>
>> Fixes: d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
>> Assisted-by: Claude:claude-opus-5
>> Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
> 
> 
> This patch landed recently in linux-next as commit f7a74e131d3f ("wifi: ath11k:
> disable interrupts during firmware crash recovery"). In my tests I found that it
> causes a regression on QCOM RB5 board during system suspend/resume cycle
> (s2idle):

Hi @Marek, can you please try if below diff can fix this regression? Also, @Julis, can you
please also confirm if it can address your original issue as well?

diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
index d2ed6a0ea7e3..1ad0a47653de 100644
--- a/drivers/net/wireless/ath/ath11k/core.c
+++ b/drivers/net/wireless/ath/ath11k/core.c
@@ -1275,9 +1275,6 @@ int ath11k_core_suspend_late(struct ath11k_base *ab)
 	if (ab->actual_pm_policy == ATH11K_PM_WOW)
 		return 0;

-	ath11k_hif_irq_disable(ab);
-	ath11k_hif_ce_irq_disable(ab);
-
 	ath11k_hif_power_down(ab, true);

 	return 0;
@@ -2333,17 +2330,9 @@ static int ath11k_core_reconfigure_on_crash(struct ath11k_base *ab)
 	int ret;

 	mutex_lock(&ab->core_lock);
+	ath11k_hif_irq_disable(ab);
+	ath11k_hif_ce_irq_disable(ab);
 	ath11k_thermal_unregister(ab);
-
-	/*
-	 * ath11k_core_reset() already disabled the interrupts on the reset
-	 * path; only the firmware crash path reaches here with them live.
-	 */
-	if (!ab->is_reset) {
-		ath11k_hif_irq_disable(ab);
-		ath11k_hif_ce_irq_disable(ab);
-	}
-
 	ath11k_dp_pdev_free(ab);
 	ath11k_cfr_deinit(ab);
 	ath11k_spectral_deinit(ab);
@@ -2605,9 +2594,6 @@ static void ath11k_core_reset(struct work_struct *work)
 	time_left = wait_for_completion_timeout(&ab->recovery_start,
 						ATH11K_RECOVER_START_TIMEOUT_HZ);

-	ath11k_hif_irq_disable(ab);
-	ath11k_hif_ce_irq_disable(ab);
-
 	ath11k_hif_power_down(ab, false);
 	ath11k_hif_power_up(ab);

-- 
2.34.1

Re: [PATCH ath-next v2 2/2] wifi: ath11k: disable interrupts during firmware crash recovery

[Julius Bairaktaris]

Hi Baochen,

I am without my router until 21 September 2026 and will report back
then.

Julius


Am Mo., 14. Sept. 2026 um 06:32 Uhr schrieb Baochen Qiang
<baochen.qiang@oss.qualcomm.com>:
>
>
>
> On 9/11/2026 3:53 PM, Marek Szyprowski wrote:
> > On 27.07.2026 00:19, Julius Bairaktaris wrote:
> >> On IPQ8074 a firmware assert reboots the SoC:
> >>
> >>   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]
> >>    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]
> >>    __napi_poll+0x38/0x188
> >>    net_rx_action+0x120/0x2c0
> >>
> >> ath11k_core_reconfigure_on_crash() tears the data path down with
> >> ath11k_dp_pdev_free(), ath11k_dp_free() and ath11k_hal_srng_clear(),
> >> which memsets the ring list. The DP NAPI is still running while that
> >> happens, so it services a ring whose address pointer has just been
> >> cleared.
> >>
> >> That function used to disable the interrupts first, until
> >> commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
> >> moved the disable into ath11k_core_reset(). reset_work is only queued
> >> from mhi.c and from the debugfs hw-restart handler, so AHB parts never
> >> run it on a real firmware crash. Their recovery goes QMI server exit ->
> >> restart_work -> ath11k_core_reconfigure_on_crash() ->
> >> ath11k_core_qmi_firmware_ready(), and nothing disables the interrupts
> >> anywhere along it.
> >>
> >> Disable them again on the crash path. The reset path has already done
> >> so by the time it gets here, hence the ab->is_reset check.
> >>
> >> This is also why the debugfs hw-restart trigger never showed the
> >> problem: it goes through ath11k_core_reset(), the one path that still
> >> had the disable.
> >>
> >> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
> >>
> >> Fixes: d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
> >> Assisted-by: Claude:claude-opus-5
> >> Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
> >
> >
> > This patch landed recently in linux-next as commit f7a74e131d3f ("wifi: ath11k:
> > disable interrupts during firmware crash recovery"). In my tests I found that it
> > causes a regression on QCOM RB5 board during system suspend/resume cycle
> > (s2idle):
>
> Hi @Marek, can you please try if below diff can fix this regression? Also, @Julis, can you
> please also confirm if it can address your original issue as well?
>
> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> index d2ed6a0ea7e3..1ad0a47653de 100644
> --- a/drivers/net/wireless/ath/ath11k/core.c
> +++ b/drivers/net/wireless/ath/ath11k/core.c
> @@ -1275,9 +1275,6 @@ int ath11k_core_suspend_late(struct ath11k_base *ab)
>         if (ab->actual_pm_policy == ATH11K_PM_WOW)
>                 return 0;
>
> -       ath11k_hif_irq_disable(ab);
> -       ath11k_hif_ce_irq_disable(ab);
> -
>         ath11k_hif_power_down(ab, true);
>
>         return 0;
> @@ -2333,17 +2330,9 @@ static int ath11k_core_reconfigure_on_crash(struct ath11k_base *ab)
>         int ret;
>
>         mutex_lock(&ab->core_lock);
> +       ath11k_hif_irq_disable(ab);
> +       ath11k_hif_ce_irq_disable(ab);
>         ath11k_thermal_unregister(ab);
> -
> -       /*
> -        * ath11k_core_reset() already disabled the interrupts on the reset
> -        * path; only the firmware crash path reaches here with them live.
> -        */
> -       if (!ab->is_reset) {
> -               ath11k_hif_irq_disable(ab);
> -               ath11k_hif_ce_irq_disable(ab);
> -       }
> -
>         ath11k_dp_pdev_free(ab);
>         ath11k_cfr_deinit(ab);
>         ath11k_spectral_deinit(ab);
> @@ -2605,9 +2594,6 @@ static void ath11k_core_reset(struct work_struct *work)
>         time_left = wait_for_completion_timeout(&ab->recovery_start,
>                                                 ATH11K_RECOVER_START_TIMEOUT_HZ);
>
> -       ath11k_hif_irq_disable(ab);
> -       ath11k_hif_ce_irq_disable(ab);
> -
>         ath11k_hif_power_down(ab, false);
>         ath11k_hif_power_up(ab);
>
> --
> 2.34.1
>

Re: [PATCH ath-next v2 2/2] wifi: ath11k: disable interrupts during firmware crash recovery

[Marek Szyprowski]

On 14.09.2026 08:32, Baochen Qiang wrote:
> On 9/11/2026 3:53 PM, Marek Szyprowski wrote:
>> On 27.07.2026 00:19, Julius Bairaktaris wrote:
>>> On IPQ8074 a firmware assert reboots the SoC:
>>>
>>>   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]
>>>    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]
>>>    __napi_poll+0x38/0x188
>>>    net_rx_action+0x120/0x2c0
>>>
>>> ath11k_core_reconfigure_on_crash() tears the data path down with
>>> ath11k_dp_pdev_free(), ath11k_dp_free() and ath11k_hal_srng_clear(),
>>> which memsets the ring list. The DP NAPI is still running while that
>>> happens, so it services a ring whose address pointer has just been
>>> cleared.
>>>
>>> That function used to disable the interrupts first, until
>>> commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
>>> moved the disable into ath11k_core_reset(). reset_work is only queued
>>> from mhi.c and from the debugfs hw-restart handler, so AHB parts never
>>> run it on a real firmware crash. Their recovery goes QMI server exit ->
>>> restart_work -> ath11k_core_reconfigure_on_crash() ->
>>> ath11k_core_qmi_firmware_ready(), and nothing disables the interrupts
>>> anywhere along it.
>>>
>>> Disable them again on the crash path. The reset path has already done
>>> so by the time it gets here, hence the ab->is_reset check.
>>>
>>> This is also why the debugfs hw-restart trigger never showed the
>>> problem: it goes through ath11k_core_reset(), the one path that still
>>> had the disable.
>>>
>>> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
>>>
>>> Fixes: d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
>>> Assisted-by: Claude:claude-opus-5
>>> Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
>>
>> This patch landed recently in linux-next as commit f7a74e131d3f ("wifi: ath11k:
>> disable interrupts during firmware crash recovery"). In my tests I found that it
>> causes a regression on QCOM RB5 board during system suspend/resume cycle
>> (s2idle):
> Hi @Marek, can you please try if below diff can fix this regression? Also, @Julis, can you
> please also confirm if it can address your original issue as well?


Works fine in my tests, feel free to add:

Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>


> diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> index d2ed6a0ea7e3..1ad0a47653de 100644
> --- a/drivers/net/wireless/ath/ath11k/core.c
> +++ b/drivers/net/wireless/ath/ath11k/core.c
> @@ -1275,9 +1275,6 @@ int ath11k_core_suspend_late(struct ath11k_base *ab)
>  	if (ab->actual_pm_policy == ATH11K_PM_WOW)
>  		return 0;
>
> -	ath11k_hif_irq_disable(ab);
> -	ath11k_hif_ce_irq_disable(ab);
> -
>  	ath11k_hif_power_down(ab, true);
>
>  	return 0;
> @@ -2333,17 +2330,9 @@ static int ath11k_core_reconfigure_on_crash(struct ath11k_base *ab)
>  	int ret;
>
>  	mutex_lock(&ab->core_lock);
> +	ath11k_hif_irq_disable(ab);
> +	ath11k_hif_ce_irq_disable(ab);
>  	ath11k_thermal_unregister(ab);
> -
> -	/*
> -	 * ath11k_core_reset() already disabled the interrupts on the reset
> -	 * path; only the firmware crash path reaches here with them live.
> -	 */
> -	if (!ab->is_reset) {
> -		ath11k_hif_irq_disable(ab);
> -		ath11k_hif_ce_irq_disable(ab);
> -	}
> -
>  	ath11k_dp_pdev_free(ab);
>  	ath11k_cfr_deinit(ab);
>  	ath11k_spectral_deinit(ab);
> @@ -2605,9 +2594,6 @@ static void ath11k_core_reset(struct work_struct *work)
>  	time_left = wait_for_completion_timeout(&ab->recovery_start,
>  						ATH11K_RECOVER_START_TIMEOUT_HZ);
>
> -	ath11k_hif_irq_disable(ab);
> -	ath11k_hif_ce_irq_disable(ab);
> -
>  	ath11k_hif_power_down(ab, false);
>  	ath11k_hif_power_up(ab);
>
Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH ath-next v2 2/2] wifi: ath11k: disable interrupts during firmware crash recovery

[Julius Bairaktaris]

Hi @Baochen,

tested 5 times and it solves the problem. Thanks!

Julius


Am Mo., 14. Sept. 2026 um 07:22 Uhr schrieb Marek Szyprowski
<m.szyprowski@samsung.com>:
>
> On 14.09.2026 08:32, Baochen Qiang wrote:
> > On 9/11/2026 3:53 PM, Marek Szyprowski wrote:
> >> On 27.07.2026 00:19, Julius Bairaktaris wrote:
> >>> On IPQ8074 a firmware assert reboots the SoC:
> >>>
> >>>   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]
> >>>    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]
> >>>    __napi_poll+0x38/0x188
> >>>    net_rx_action+0x120/0x2c0
> >>>
> >>> ath11k_core_reconfigure_on_crash() tears the data path down with
> >>> ath11k_dp_pdev_free(), ath11k_dp_free() and ath11k_hal_srng_clear(),
> >>> which memsets the ring list. The DP NAPI is still running while that
> >>> happens, so it services a ring whose address pointer has just been
> >>> cleared.
> >>>
> >>> That function used to disable the interrupts first, until
> >>> commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
> >>> moved the disable into ath11k_core_reset(). reset_work is only queued
> >>> from mhi.c and from the debugfs hw-restart handler, so AHB parts never
> >>> run it on a real firmware crash. Their recovery goes QMI server exit ->
> >>> restart_work -> ath11k_core_reconfigure_on_crash() ->
> >>> ath11k_core_qmi_firmware_ready(), and nothing disables the interrupts
> >>> anywhere along it.
> >>>
> >>> Disable them again on the crash path. The reset path has already done
> >>> so by the time it gets here, hence the ab->is_reset check.
> >>>
> >>> This is also why the debugfs hw-restart trigger never showed the
> >>> problem: it goes through ath11k_core_reset(), the one path that still
> >>> had the disable.
> >>>
> >>> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.12-01460-QCAHKSWPL_SILICONZ-1
> >>>
> >>> Fixes: d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
> >>> Assisted-by: Claude:claude-opus-5
> >>> Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
> >>
> >> This patch landed recently in linux-next as commit f7a74e131d3f ("wifi: ath11k:
> >> disable interrupts during firmware crash recovery"). In my tests I found that it
> >> causes a regression on QCOM RB5 board during system suspend/resume cycle
> >> (s2idle):
> > Hi @Marek, can you please try if below diff can fix this regression? Also, @Julis, can you
> > please also confirm if it can address your original issue as well?
>
>
> Works fine in my tests, feel free to add:
>
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
>
> > diff --git a/drivers/net/wireless/ath/ath11k/core.c b/drivers/net/wireless/ath/ath11k/core.c
> > index d2ed6a0ea7e3..1ad0a47653de 100644
> > --- a/drivers/net/wireless/ath/ath11k/core.c
> > +++ b/drivers/net/wireless/ath/ath11k/core.c
> > @@ -1275,9 +1275,6 @@ int ath11k_core_suspend_late(struct ath11k_base *ab)
> >       if (ab->actual_pm_policy == ATH11K_PM_WOW)
> >               return 0;
> >
> > -     ath11k_hif_irq_disable(ab);
> > -     ath11k_hif_ce_irq_disable(ab);
> > -
> >       ath11k_hif_power_down(ab, true);
> >
> >       return 0;
> > @@ -2333,17 +2330,9 @@ static int ath11k_core_reconfigure_on_crash(struct ath11k_base *ab)
> >       int ret;
> >
> >       mutex_lock(&ab->core_lock);
> > +     ath11k_hif_irq_disable(ab);
> > +     ath11k_hif_ce_irq_disable(ab);
> >       ath11k_thermal_unregister(ab);
> > -
> > -     /*
> > -      * ath11k_core_reset() already disabled the interrupts on the reset
> > -      * path; only the firmware crash path reaches here with them live.
> > -      */
> > -     if (!ab->is_reset) {
> > -             ath11k_hif_irq_disable(ab);
> > -             ath11k_hif_ce_irq_disable(ab);
> > -     }
> > -
> >       ath11k_dp_pdev_free(ab);
> >       ath11k_cfr_deinit(ab);
> >       ath11k_spectral_deinit(ab);
> > @@ -2605,9 +2594,6 @@ static void ath11k_core_reset(struct work_struct *work)
> >       time_left = wait_for_completion_timeout(&ab->recovery_start,
> >                                               ATH11K_RECOVER_START_TIMEOUT_HZ);
> >
> > -     ath11k_hif_irq_disable(ab);
> > -     ath11k_hif_ce_irq_disable(ab);
> > -
> >       ath11k_hif_power_down(ab, false);
> >       ath11k_hif_power_up(ab);
> >
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>

Re: [PATCH ath-next v2 2/2] wifi: ath11k: disable interrupts during firmware crash recovery

[Baochen Qiang]

On 9/21/2026 12:42 AM, Julius Bairaktaris wrote:
> Hi @Baochen,
> 
> tested 5 times and it solves the problem. Thanks!

Thanks. Can I have below tag when I submit the fix ?

Tested-by: Julius Bairaktaris <julius@bairaktaris.de>

Re: [PATCH ath-next v2 2/2] wifi: ath11k: disable interrupts during firmware crash recovery

[Julius Bairaktaris]

Yes, sure

Am Mo., 21. Sept. 2026 um 03:17 Uhr schrieb Baochen Qiang
<baochen.qiang@oss.qualcomm.com>:
>
>
>
> On 9/21/2026 12:42 AM, Julius Bairaktaris wrote:
> > Hi @Baochen,
> >
> > tested 5 times and it solves the problem. Thanks!
>
> Thanks. Can I have below tag when I submit the fix ?
>
> Tested-by: Julius Bairaktaris <julius@bairaktaris.de>

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

[Baochen Qiang]

On 7/27/2026 6:19 AM, Julius Bairaktaris wrote:
> On IPQ8074 every firmware assert takes the whole SoC down. The DP NAPI
> keeps polling while ath11k_core_reconfigure_on_crash() frees the data
> path underneath it, and dereferences a ring the teardown has already
> cleared.
> 
> The interrupts used to be disabled at the top of that function.
> commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
> moved the disable into ath11k_core_reset(), which AHB parts never reach
> on a real firmware crash: reset_work is queued only from mhi.c and from
> the debugfs hw-restart handler. Patch 2 puts the disable back on the
> crash path. Patch 1 is a prerequisite - the CE half of the quiesce is a
> no-op on AHB today because the bus never implemented the hif ops.
> 
> Reproduced and fixed on a Xiaomi AX3600 (IPQ8074 hw2.0), with no
> out-of-tree modules loaded, using the debugfs simulate_fw_crash
> 'assert' trigger:
> 
>   before: 2/2 asserts panic in ath11k_dp_rx_process_mon_status() and
>           reboot the SoC
>   after:  3/3 asserts recover, 5 firmware boots across a single 397 s
>           uptime, no panics, both radios stay up
> 
> Note the debugfs 'hw-restart' trigger does not reproduce this, since it
> goes through ath11k_core_reset() - the one path that still disables the
> interrupts. Only a real firmware assert does.
> 
> Patch 1 is by inspection: it makes ath11k_hif_ce_irq_disable() take
> effect on AHB, which also fixes the existing call in
> ath11k_core_reset(). I have not managed to trigger a CE-side crash on
> its own, so if you would rather see that split out or dropped, say so.
> 
> Changes in v2 (no functional change, review comments from Jeff on 2/2):
> - separate the ath-specific Tested-on tag from the upstream tags with a
>   blank line
> - use the standard kernel block comment style, with /* on its own line
> 
> v1: https://lore.kernel.org/ath11k/20260725141757.1316877-1-julius@bairaktaris.de/
> 
> Julius Bairaktaris (2):
>   wifi: ath11k: implement CE interrupt enable/disable for AHB
>   wifi: ath11k: disable interrupts during firmware crash recovery
> 
>  drivers/net/wireless/ath/ath11k/ahb.c  |  9 ++++++++-
>  drivers/net/wireless/ath/ath11k/core.c | 10 ++++++++++
>  2 files changed, 18 insertions(+), 1 deletion(-)
> 

Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>

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

[Julius Bairaktaris]

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

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

[Rameshkumar Sundaram]

On 7/27/2026 3:49 AM, Julius Bairaktaris wrote:
> On IPQ8074 every firmware assert takes the whole SoC down. The DP NAPI
> keeps polling while ath11k_core_reconfigure_on_crash() frees the data
> path underneath it, and dereferences a ring the teardown has already
> cleared.
> 
> The interrupts used to be disabled at the top of that function.
> commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
> moved the disable into ath11k_core_reset(), which AHB parts never reach
> on a real firmware crash: reset_work is queued only from mhi.c and from
> the debugfs hw-restart handler. Patch 2 puts the disable back on the
> crash path. Patch 1 is a prerequisite - the CE half of the quiesce is a
> no-op on AHB today because the bus never implemented the hif ops.
> 
> Reproduced and fixed on a Xiaomi AX3600 (IPQ8074 hw2.0), with no
> out-of-tree modules loaded, using the debugfs simulate_fw_crash
> 'assert' trigger:
> 
>    before: 2/2 asserts panic in ath11k_dp_rx_process_mon_status() and
>            reboot the SoC
>    after:  3/3 asserts recover, 5 firmware boots across a single 397 s
>            uptime, no panics, both radios stay up
> 
> Note the debugfs 'hw-restart' trigger does not reproduce this, since it
> goes through ath11k_core_reset() - the one path that still disables the
> interrupts. Only a real firmware assert does.
> 
> Patch 1 is by inspection: it makes ath11k_hif_ce_irq_disable() take
> effect on AHB, which also fixes the existing call in
> ath11k_core_reset(). I have not managed to trigger a CE-side crash on
> its own, so if you would rather see that split out or dropped, say so.
> 
> Changes in v2 (no functional change, review comments from Jeff on 2/2):
> - separate the ath-specific Tested-on tag from the upstream tags with a
>    blank line
> - use the standard kernel block comment style, with /* on its own line
> 
> v1: https://lore.kernel.org/ath11k/20260725141757.1316877-1-julius@bairaktaris.de/
> 
> Julius Bairaktaris (2):
>    wifi: ath11k: implement CE interrupt enable/disable for AHB
>    wifi: ath11k: disable interrupts during firmware crash recovery
> 
>   drivers/net/wireless/ath/ath11k/ahb.c  |  9 ++++++++-
>   drivers/net/wireless/ath/ath11k/core.c | 10 ++++++++++
>   2 files changed, 18 insertions(+), 1 deletion(-)
> 


Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>

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

[Jeff Johnson]

On Mon, 27 Jul 2026 00:19:06 +0200, Julius Bairaktaris wrote:
> On IPQ8074 every firmware assert takes the whole SoC down. The DP NAPI
> keeps polling while ath11k_core_reconfigure_on_crash() frees the data
> path underneath it, and dereferences a ring the teardown has already
> cleared.
> 
> The interrupts used to be disabled at the top of that function.
> commit d455e805de70 ("wifi: ath11k: rearrange IRQ enable/disable in reset path")
> moved the disable into ath11k_core_reset(), which AHB parts never reach
> on a real firmware crash: reset_work is queued only from mhi.c and from
> the debugfs hw-restart handler. Patch 2 puts the disable back on the
> crash path. Patch 1 is a prerequisite - the CE half of the quiesce is a
> no-op on AHB today because the bus never implemented the hif ops.
> 
> [...]

Applied, thanks!

[1/2] wifi: ath11k: implement CE interrupt enable/disable for AHB
      commit: a7ab5c835e4253b6577e4137367c05bfddd79fa2
[2/2] wifi: ath11k: disable interrupts during firmware crash recovery
      commit: f7a74e131d3f0de04335dbe278bfb82bdafcdb3e

Best regards,
-- 
Jeff Johnson <jeff.johnson@oss.qualcomm.com>