From: Wen Gong <wgong@codeaurora.org>
To: Krishna Chaitanya <chaitanya.mgit@gmail.com>
Cc: ath10k <ath10k@lists.infradead.org>,
linux-wireless <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH v2] ath10k: add flag to protect napi operation to avoid dead loop hang for SDIO
Date: Mon, 24 Aug 2020 18:44:41 +0800 [thread overview]
Message-ID: <2d6362ce85956d0f7df2e596b89a7028@codeaurora.org> (raw)
In-Reply-To: <CABPxzYKvPwtQwxMfRcv9jT+d92ErhYGR91SKBH86T3Rd2QH9Qg@mail.gmail.com>
On 2020-08-24 18:03, Krishna Chaitanya wrote:
> On Mon, Aug 24, 2020 at 3:10 PM Wen Gong <wgong@codeaurora.org> wrote:
>>
>> On 2020-08-24 16:35, Krishna Chaitanya wrote:
>> > On Mon, Aug 24, 2020 at 10:03 AM Wen Gong <wgong@codeaurora.org> wrote:
>> >>
>> >> It happened "Kernel panic - not syncing: hung_task: blocked tasks"
>> >> when
>> >> test simulate crash and ifconfig down/rmmod meanwhile.
>> >>
>> ...
>> >>
>> >> #ifdef CONFIG_PM
>> > Even though your DUT is SDIO based we should be doing this in general
>> > for all, no?
>> > core_restart + hif_stop is common to all.
>> this patch does not have core_restart.
> I was referring to the combination which is causing the issue.
>
>> I dit not hit the issue for others bus(PCIe,SNOC...), so I can not
>> change them with a
>> assumption they also have this issue.
> But that doesn't make sense, the combination is being hit for others
> also.
> (they should also endup calling napi_disable twice?) or they are using
> some other check to avoid this (doesn't appear so from a quick look at
> the
> code).
Because I only use SDIO, I did not use others BUS, so I did not hit the
issue
on other BUS.
>
> So, I am back to my initial guess that the SDIO specific async_rx_work
> is
> causing/aggravating this issue.
the commit log of this patch has explain the reason, it is not caused by
the
async_rx_work and I have started the "ath10k: cancel rx worker in
hif_stop for SDIO"
for async_rx_work.
WARNING: multiple messages have this Message-ID (diff)
From: Wen Gong <wgong@codeaurora.org>
To: Krishna Chaitanya <chaitanya.mgit@gmail.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
ath10k <ath10k@lists.infradead.org>
Subject: Re: [PATCH v2] ath10k: add flag to protect napi operation to avoid dead loop hang for SDIO
Date: Mon, 24 Aug 2020 18:44:41 +0800 [thread overview]
Message-ID: <2d6362ce85956d0f7df2e596b89a7028@codeaurora.org> (raw)
In-Reply-To: <CABPxzYKvPwtQwxMfRcv9jT+d92ErhYGR91SKBH86T3Rd2QH9Qg@mail.gmail.com>
On 2020-08-24 18:03, Krishna Chaitanya wrote:
> On Mon, Aug 24, 2020 at 3:10 PM Wen Gong <wgong@codeaurora.org> wrote:
>>
>> On 2020-08-24 16:35, Krishna Chaitanya wrote:
>> > On Mon, Aug 24, 2020 at 10:03 AM Wen Gong <wgong@codeaurora.org> wrote:
>> >>
>> >> It happened "Kernel panic - not syncing: hung_task: blocked tasks"
>> >> when
>> >> test simulate crash and ifconfig down/rmmod meanwhile.
>> >>
>> ...
>> >>
>> >> #ifdef CONFIG_PM
>> > Even though your DUT is SDIO based we should be doing this in general
>> > for all, no?
>> > core_restart + hif_stop is common to all.
>> this patch does not have core_restart.
> I was referring to the combination which is causing the issue.
>
>> I dit not hit the issue for others bus(PCIe,SNOC...), so I can not
>> change them with a
>> assumption they also have this issue.
> But that doesn't make sense, the combination is being hit for others
> also.
> (they should also endup calling napi_disable twice?) or they are using
> some other check to avoid this (doesn't appear so from a quick look at
> the
> code).
Because I only use SDIO, I did not use others BUS, so I did not hit the
issue
on other BUS.
>
> So, I am back to my initial guess that the SDIO specific async_rx_work
> is
> causing/aggravating this issue.
the commit log of this patch has explain the reason, it is not caused by
the
async_rx_work and I have started the "ath10k: cancel rx worker in
hif_stop for SDIO"
for async_rx_work.
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2020-08-24 10:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 4:33 [PATCH v2] ath10k: add flag to protect napi operation to avoid dead loop hang for SDIO Wen Gong
2020-08-24 4:33 ` Wen Gong
2020-08-24 8:35 ` Krishna Chaitanya
2020-08-24 8:35 ` Krishna Chaitanya
2020-08-24 9:39 ` Wen Gong
2020-08-24 9:39 ` Wen Gong
2020-08-24 10:03 ` Krishna Chaitanya
2020-08-24 10:03 ` Krishna Chaitanya
2020-08-24 10:44 ` Wen Gong [this message]
2020-08-24 10:44 ` Wen Gong
2020-08-24 11:15 ` Krishna Chaitanya
2020-08-24 11:15 ` Krishna Chaitanya
2020-08-25 3:41 ` Wen Gong
2020-08-25 3:41 ` Wen Gong
2020-08-25 8:24 ` Krishna Chaitanya
2020-08-25 8:24 ` Krishna Chaitanya
2020-08-25 9:58 ` Wen Gong
2020-08-25 9:58 ` Wen Gong
2020-08-28 12:23 ` Wen Gong
2020-08-28 12:23 ` Wen Gong
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=2d6362ce85956d0f7df2e596b89a7028@codeaurora.org \
--to=wgong@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=chaitanya.mgit@gmail.com \
--cc=linux-wireless@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.