| Message ID | 20210914192515.9273-1-linus.luessing@c0d3.blue (mailing list archive) |
|---|---|
| Headers | show |
| Series | ath9k: interrupt fixes on queue reset | expand |
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
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. For patches 1/3 and and 2/3 I'd still like to see them merged upstream if there is no objection to those. Regars, 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.