Hi Thorsten On 02/15/21 06:55, Thorsten Leemhuis wrote: > 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. Cool. Works for me. Thanks -- Qais Yousef
