From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Kalle Valo <kvalo@codeaurora.org>, Felix Fietkau <nbd@nbd.name>,
Sujith Manoharan <c_manoha@qca.qualcomm.com>,
ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
"John W . Linville" <linville@tuxdriver.com>,
Felix Fietkau <nbd@openwrt.org>,
Simon Wunderlich <sw@simonwunderlich.de>,
Sven Eckelmann <sven@narfation.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] ath9k: interrupt fixes on queue reset
Date: Wed, 15 Sep 2021 11:23:43 +0200 [thread overview]
Message-ID: <YUG7n24qcn/AmuT8@sellars> (raw)
In-Reply-To: <87a6kf6iip.fsf@toke.dk>
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
next prev parent reply other threads:[~2021-09-15 9:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-14 19:25 [PATCH 0/3] ath9k: interrupt fixes on queue reset Linus Lüssing
2021-09-14 19:25 ` [PATCH 1/3] ath9k: add option to reset the wifi chip via debugfs Linus Lüssing
2021-10-05 14:27 ` Kalle Valo
2021-09-14 19:25 ` [PATCH 2/3] ath9k: Fix potential interrupt storm on queue reset Linus Lüssing
2021-09-14 19:25 ` [PATCH 3/3] ath9k: Fix potential hw interrupt resume during reset Linus Lüssing
2021-09-15 9:48 ` Felix Fietkau
2021-09-15 19:18 ` Linus Lüssing
2021-09-14 19:53 ` [PATCH 0/3] ath9k: interrupt fixes on queue reset Toke Høiland-Jørgensen
2021-09-15 9:23 ` Linus Lüssing [this message]
2021-10-05 14:12 ` Linus Lüssing
2021-10-05 14:24 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YUG7n24qcn/AmuT8@sellars \
--to=linus.luessing@c0d3.blue \
--cc=ath9k-devel@qca.qualcomm.com \
--cc=c_manoha@qca.qualcomm.com \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=nbd@nbd.name \
--cc=nbd@openwrt.org \
--cc=netdev@vger.kernel.org \
--cc=sven@narfation.org \
--cc=sw@simonwunderlich.de \
--cc=toke@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).