lkml.org 
[lkml]   [2021]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] docs: reporting-issues.rst: explain how to decode stack traces
Date
Hi! Many thx for looking into this, much appreciated!

Am 14.02.21 um 17:00 schrieb Qais Yousef:
> On 02/10/21 06:48, Thorsten Leemhuis wrote:
>
>> - * If the failure includes a stack dump, like an Oops does, consider decoding
>> - it to find the offending line of code.
>> + * If your failure involves a 'panic', 'oops', or 'warning', consider decoding
> or 'BUG'? There are similar other places below that could benefit from this
> addition too.

Good point. In fact there are other places in the document where this is
needed as well. Will address those in another patch.

>> + the kernel log to find the line of code that trigger the error.
>>
>> * If your problem is a regression, try to narrow down when the issue was
>> introduced as much as possible.
>> @@ -869,6 +869,15 @@ pick up the configuration of your current kernel and then tries to adjust it
>> somewhat for your system. That does not make the resulting kernel any better,
>> but quicker to compile.
>>
>> +Note: If you are dealing with a kernel panic, oops, or warning, please make
>> +sure to enable CONFIG_KALLSYMS when configuring your kernel. Additionally,
>
> s/make sure/try/

I did that, but ignored...

> s/kernel./kernel if you can./

...this. Yes, you have a point with...

> Less demanding wording in case the user doesn't have the capability to rebuild
> or deploy such a kernel where the problem happens. Maybe you can tweak it more
> if you like too :-)

...that, but that section in the document is about building your own
kernel, so I'd say we don't have to be that careful here.

>> +enable CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO, too; the latter is the
>> +relevant one of those two, but can only be reached if you enable the former. Be
>> +aware CONFIG_DEBUG_INFO increases the storage space required to build a kernel
>> +by quite a bit. But that's worth it, as these options will allow you later to
>> +pinpoint the exact line of code that triggers your issue. The section 'Decode
>> +failure messages' below explains this in more detail.
>
> I think worth mentioning too that the user should keep a log of the problem
> when first encountered and then attempt the above. Just in case the problem is
> not reproducible easily so the info is not lost.
>
> Maybe something like below:
>
> '''
> Always keep a record of the issue encountered in case it is hard to reproduce.
> Sending undecoded report is better than not sending a report at all.
> '''

Very good point, added.

>> +your kernel. If you did so, consider to decode the information from the
>> +kernel's log. That will make it a lot easier to understand what lead to the
>> +'panic', 'oops', or 'warning', which increases the chances enormously that
>> +someone can provide a fix.
> I suggest removing the word enormously. It helps, but it all depends on the
> particular circumstances. Sometimes it does, others it doesn't.

Done.

> This looks good to me in general. With the above minor nits fixed, feel free to
> add my
> Reviewed-by: Qais Yousef <qais.yousef@arm.com>

Great, thx, will do!

Ciao, Thorsten

\
 
 \ /
  Last update: 2021-02-15 06:56    [W:0.156 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site