From: Wen Gong <wgong@codeaurora.org>
To: Brian Norris <briannorris@chromium.org>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
ath10k <ath10k@lists.infradead.org>
Subject: Re: [PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size
Date: Wed, 10 Feb 2021 10:24:14 +0800 [thread overview]
Message-ID: <79f57b7531b862648afdfc5531b2effd@codeaurora.org> (raw)
In-Reply-To: <CA+ASDXNYO+w254D2Uh3OSfTGjJEkbOCX=hq+XaWe9DtjbuOy3g@mail.gmail.com>
On 2021-02-10 10:14, Brian Norris wrote:
> On Tue, Feb 9, 2021 at 6:12 PM Wen Gong <wgong@codeaurora.org> wrote:
>> On 2021-02-10 03:35, Brian Norris wrote:
>> so this patch is to dump the top 1024 bytes only,
>> its 1st goal is make log smaller.
>
> Agreed. I wasn't objecting to this patch. I just wanted to highlight
> the second part should probably also be considered as not exclusively
> an ath10k bug:
>
>> its 2nd effect is fix the crash issue,
>
> but I guess if you're not testing the latest upstream, it's a little
> hard to tell for sure whether the crash still exist at all anyway...
>
Yes.
It is hard for me to test with the latest upstream, because the kernel
is v4.19 for my SDIO chip.
I do not have the environment with latest kernel.:).
If someone use the other environment(not V4.19+SDIO) which is the latest
kernel,
and if it not crash, it can not conclude it also will not crash on my
v4.19 for SDIO chip without this patch.:)
It will not crash with this patch on my v4.19 for SDIO, this have been
verified my me.
If someone want to check the same crash with latest kernel, he/she can
generate a simulate test and analyze with latest kernel.:)
> Brian
_______________________________________________
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: Brian Norris <briannorris@chromium.org>
Cc: ath10k <ath10k@lists.infradead.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size
Date: Wed, 10 Feb 2021 10:24:14 +0800 [thread overview]
Message-ID: <79f57b7531b862648afdfc5531b2effd@codeaurora.org> (raw)
In-Reply-To: <CA+ASDXNYO+w254D2Uh3OSfTGjJEkbOCX=hq+XaWe9DtjbuOy3g@mail.gmail.com>
On 2021-02-10 10:14, Brian Norris wrote:
> On Tue, Feb 9, 2021 at 6:12 PM Wen Gong <wgong@codeaurora.org> wrote:
>> On 2021-02-10 03:35, Brian Norris wrote:
>> so this patch is to dump the top 1024 bytes only,
>> its 1st goal is make log smaller.
>
> Agreed. I wasn't objecting to this patch. I just wanted to highlight
> the second part should probably also be considered as not exclusively
> an ath10k bug:
>
>> its 2nd effect is fix the crash issue,
>
> but I guess if you're not testing the latest upstream, it's a little
> hard to tell for sure whether the crash still exist at all anyway...
>
Yes.
It is hard for me to test with the latest upstream, because the kernel
is v4.19 for my SDIO chip.
I do not have the environment with latest kernel.:).
If someone use the other environment(not V4.19+SDIO) which is the latest
kernel,
and if it not crash, it can not conclude it also will not crash on my
v4.19 for SDIO chip without this patch.:)
It will not crash with this patch on my v4.19 for SDIO, this have been
verified my me.
If someone want to check the same crash with latest kernel, he/she can
generate a simulate test and analyze with latest kernel.:)
> Brian
next prev parent reply other threads:[~2021-02-10 2:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 2:59 [PATCH] ath10k: change len of trace_ath10k_log_dbg_dump for large buffer size Wen Gong
2021-02-09 2:59 ` Wen Gong
2021-02-09 7:34 ` Kalle Valo
2021-02-09 7:34 ` Kalle Valo
2021-02-09 19:35 ` Brian Norris
2021-02-09 19:35 ` Brian Norris
2021-02-09 19:55 ` Steven Rostedt
2021-02-09 19:55 ` Steven Rostedt
2021-02-09 21:34 ` Steven Rostedt
2021-02-09 21:34 ` Steven Rostedt
2021-02-10 2:01 ` Wen Gong
2021-02-10 2:01 ` Wen Gong
2021-02-10 16:30 ` Steven Rostedt
2021-02-10 16:30 ` Steven Rostedt
2021-02-10 16:48 ` Steven Rostedt
2021-02-10 16:48 ` Steven Rostedt
2021-02-10 16:53 ` Steven Rostedt
2021-02-10 16:53 ` Steven Rostedt
2021-03-08 7:22 ` Wen Gong
2021-03-08 7:22 ` Wen Gong
2021-02-10 2:11 ` Wen Gong
2021-02-10 2:11 ` Wen Gong
2021-02-10 2:14 ` Brian Norris
2021-02-10 2:14 ` Brian Norris
2021-02-10 2:24 ` Wen Gong [this message]
2021-02-10 2:24 ` 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=79f57b7531b862648afdfc5531b2effd@codeaurora.org \
--to=wgong@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=briannorris@chromium.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rostedt@goodmis.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.