From: Wen Gong <wgong@codeaurora.org>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: [PATCH v2] ath10k: add fw coredump for sdio when firmware assert
Date: Mon, 23 Sep 2019 20:12:11 +0800 [thread overview]
Message-ID: <e61e7cbe3fd9dfad4679bd1d686bc44d@codeaurora.org> (raw)
In-Reply-To: <87v9tj6y5p.fsf@codeaurora.org>
On 2019-09-23 19:37, Kalle Valo wrote:
> Wen Gong <wgong@codeaurora.org> writes:
>
>> On 2019-09-21 19:38, Kalle Valo wrote:
>>>
>>> What's wrong with ath10k_sdio_hif_diag_read()? AFAICS this whole
>>> function duplicates just what it does.
>>
>> ath10k_sdio_hif_diag_read's buffer size is limit,
>> and the dump memory/register's buffer size is larger than the diag
>> window's limit,
>> if use it directly will trigger crash like this for every time.
>
> You shouldn't blindly add extra code to ath10k workaround issues. And
> if
> you really need to use a workaround, then it needs to properly
> explained
> in the commit and as well as commented in the code. But before that the
> issue needs to be thoroughly investigated and understood where the
> problem is coming from. Because it might be even completely unrelated
> to
> ath10k.
>
>> [ 149.947624] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read
>> buf_len :4
>> [ 149.954741] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read
>> buf_len :240
>> [ 151.005143] Unable to handle kernel paging request at virtual
>> [ 151.114537] Process swapper/0 (pid: 0, stack limit =
>> 0x00000000e30dc665)
、
>
> Did you investigate this? Is the buffer you reading to DMA accessible?
> What about the alignment? Is there a certain length which is the limit
> for crashes? And so on...
the limit is 4 byte.
for 5 bytes, it will crash.
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Wen Gong <wgong@codeaurora.org>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] ath10k: add fw coredump for sdio when firmware assert
Date: Mon, 23 Sep 2019 20:12:11 +0800 [thread overview]
Message-ID: <e61e7cbe3fd9dfad4679bd1d686bc44d@codeaurora.org> (raw)
In-Reply-To: <87v9tj6y5p.fsf@codeaurora.org>
On 2019-09-23 19:37, Kalle Valo wrote:
> Wen Gong <wgong@codeaurora.org> writes:
>
>> On 2019-09-21 19:38, Kalle Valo wrote:
>>>
>>> What's wrong with ath10k_sdio_hif_diag_read()? AFAICS this whole
>>> function duplicates just what it does.
>>
>> ath10k_sdio_hif_diag_read's buffer size is limit,
>> and the dump memory/register's buffer size is larger than the diag
>> window's limit,
>> if use it directly will trigger crash like this for every time.
>
> You shouldn't blindly add extra code to ath10k workaround issues. And
> if
> you really need to use a workaround, then it needs to properly
> explained
> in the commit and as well as commented in the code. But before that the
> issue needs to be thoroughly investigated and understood where the
> problem is coming from. Because it might be even completely unrelated
> to
> ath10k.
>
>> [ 149.947624] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read
>> buf_len :4
>> [ 149.954741] ath10k_sdio mmc1:0001:1: ath10k_sdio_hif_diag_read
>> buf_len :240
>> [ 151.005143] Unable to handle kernel paging request at virtual
>> [ 151.114537] Process swapper/0 (pid: 0, stack limit =
>> 0x00000000e30dc665)
、
>
> Did you investigate this? Is the buffer you reading to DMA accessible?
> What about the alignment? Is there a certain length which is the limit
> for crashes? And so on...
the limit is 4 byte.
for 5 bytes, it will crash.
next prev parent reply other threads:[~2019-09-23 12:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-30 2:32 [PATCH v2] ath10k: add fw coredump for sdio when firmware assert Wen Gong
2019-08-30 2:32 ` Wen Gong
2019-09-21 11:26 ` Kalle Valo
2019-09-21 11:26 ` Kalle Valo
2019-09-21 11:35 ` Kalle Valo
2019-09-21 11:35 ` Kalle Valo
2019-09-23 11:07 ` Wen Gong
2019-09-23 11:07 ` Wen Gong
2019-09-24 3:38 ` Wen Gong
2019-09-24 3:38 ` Wen Gong
2019-09-21 11:38 ` Kalle Valo
2019-09-21 11:38 ` Kalle Valo
2019-09-23 11:09 ` Wen Gong
2019-09-23 11:09 ` Wen Gong
2019-09-23 11:37 ` Kalle Valo
2019-09-23 11:37 ` Kalle Valo
2019-09-23 12:12 ` Wen Gong [this message]
2019-09-23 12:12 ` Wen Gong
2019-09-21 11:49 ` Kalle Valo
2019-09-21 11:49 ` Kalle Valo
2019-09-23 11:10 ` Wen Gong
2019-09-23 11:10 ` 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=e61e7cbe3fd9dfad4679bd1d686bc44d@codeaurora.org \
--to=wgong@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=kvalo@codeaurora.org \
--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.