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.you...@arm.com> Great, thx, will do! Ciao, Thorsten
