[0/3] ath9k: interrupt fixes on queue reset

Hi,

The following are two patches for ath9k to fix a potential interrupt
storm (PATCH 2/3) and to fix potentially resetting the wifi chip while
its interrupts were accidentally reenabled (PATCH 3/3).

PATCH 1/3 adds the possibility to trigger the ath9k queue reset through
the ath9k reset file in debugfs. Which was helpful to reproduce and debug
this issue and might help for future debugging.

PATCH 2/3 and PATCH 3/3 should be applicable for stable.

Regards, Linus

Linus Lüssing <linus.luessing@c0d3.blue> writes:

> Hi,
>
> The following are two patches for ath9k to fix a potential interrupt
> storm (PATCH 2/3) and to fix potentially resetting the wifi chip while
> its interrupts were accidentally reenabled (PATCH 3/3).

Uhh, interesting - nice debugging work! What's the user-level symptom of
this? I.e., when this triggers does the device just appear to hang, or
does it cause reboots, or?

-Toke

Hi Toke,

On Tue, Sep 14, 2021 at 09:53:34PM +0200, Toke Høiland-Jørgensen wrote:
> Linus Lüssing <linus.luessing@c0d3.blue> writes:
> 
> > Hi,
> >
> > The following are two patches for ath9k to fix a potential interrupt
> > storm (PATCH 2/3) and to fix potentially resetting the wifi chip while
> > its interrupts were accidentally reenabled (PATCH 3/3).
> 
> Uhh, interesting - nice debugging work! What's the user-level symptom of
> this? I.e., when this triggers does the device just appear to hang, or
> does it cause reboots, or?
> 
> -Toke
> 

For PATCH 2/3 the user-level symptom was that the system would
hang for a few seconds and would then silently reboot without any notice
on the serial console. And after disabling CONFIG_ATH79_WDT the
system would "hang" indefinitely without any notice on the console
without a reboot (while JTAG/gdb showed that it was entering ath_isr()
again and again and wasn't doing anything else).

For PATCH 3/3 I don't have a specific user-level symptom. But from
looking at the git history it seemed to me that the ath9k hw
interrupts (AR_IER, AR_INTR_ASYNC_ENABLE and AR_INTR_ASYNC_ENABLE off)
should be disabled during a reset:

  4668cce527ac ath9k: disable the tasklet before taking the PCU lock
  eaf04a691566 ath9k: Disable beacon tasklet during reset
  872b5d814f99 ath9k: do not access hardware on IRQs during reset
  e3f31175a3ee ath9k: fix race condition in irq processing during hardware reset

Maybe someone else on these lists might know what issues this can
cause exactly?

Regards, Linus

Linus Lüssing <linus.luessing@c0d3.blue> writes:

> On Tue, Sep 14, 2021 at 09:25:12PM +0200, Linus Lüssing wrote:

>> Hi,

>> 

>> The following are two patches for ath9k to fix a potential interrupt

>> storm (PATCH 2/3) and to fix potentially resetting the wifi chip while

>> its interrupts were accidentally reenabled (PATCH 3/3).

>> 

>> PATCH 1/3 adds the possibility to trigger the ath9k queue reset through

>> the ath9k reset file in debugfs. Which was helpful to reproduce and debug

>> this issue and might help for future debugging.

>> 

>> PATCH 2/3 and PATCH 3/3 should be applicable for stable.

>> 

>> Regards, Linus

>> 

>

> I've marked PATCH 3/3 as "rejected" in Patchwork now due to

> Felix's legitimate remarks.


BTW I prefer to mark patches as rejected myself in patchwork so that I
know what's happening (patchwork is lacking in this respect as it
doesn't notify me if there are any changes in patches). But good that
you mentioned this via email so I didn't need to wonder what happened.

> For patches 1/3 and and 2/3 I'd still like to see them merged upstream

> if there is no objection to those.


Thanks, I was about to ask what I should do with this patchset.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches