Date:   Mon, 15 Feb 2021 06:55:02 +0100
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Qais Yousef <qais.yousef@....com>
Cc:     Jonathan Corbet <corbet@....net>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        Sasha Levin <sashal@...nel.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Joerg Roedel <joro@...tes.org>,
        Damian Tometzki <linux@...etzki.de>
Subject: Re: [PATCH] docs: reporting-issues.rst: explain how to decode stack
 traces

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@....com>

Great, thx, will do!

Ciao, Thorsten

Powered by blists - more mailing lists