Hi Toke, On Tue, Sep 14, 2021 at 09:53:34PM +0200, Toke Høiland-Jørgensen wrote: > Linus Lüssing <linus.luessing@xxxxxxxxx> 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
