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:

quoted

- * 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.

quoted

+   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.

quoted

+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.

quoted

+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 <redacted>

Great, thx, will do!

Ciao, Thorsten