Hi Steven,

On Tue, Nov 27, 2018 at 01:23:18PM -0500, Steven Rostedt wrote:
> On Tue, 27 Nov 2018 15:15:20 +0800
> Feng Tang <[email protected]> wrote:
> 
> > Kernel panic issues are always painful to debug, partially
> > because it's not easy to get enough information of the
> > context when panic happens.
> > 
> > And we have ramoops and kdump for that, while this commit
> > tries to provide a easier way to show the system info by adding
> > a cmdline parameter, referring some idea from sysrq handler.
> > 
> > Signed-off-by: Feng Tang <[email protected]>
> > Cc: Thomas Gleixner <[email protected]>
> > Cc: John Stultz <[email protected]>
> > Cc: Ingo Molnar <[email protected]>
> > Cc: Peter Zijlstra <[email protected]>
> > Cc: Steven Rostedt <[email protected]>
> > ---
> > Changelog:
> >  v2:
> >     - change text "dump/DUMP" to "print/PRINT" which
> >       is more accurate, suggested by Andrew Morton 
> >     - add code to print ftrace buffer 
> > 
> >  Documentation/admin-guide/kernel-parameters.txt |  8 +++++++
> >  kernel/panic.c                                  | 28 
> > +++++++++++++++++++++++++
> >  2 files changed, 36 insertions(+)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index 19f4423..80c819a 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -3081,6 +3081,14 @@
> >                     timeout < 0: reboot immediately
> >                     Format: <timeout>
> >  
> > +   panic_print=    Bitmask for printing system info when panic happens.
> > +                   User can chose combination of the following bits:
> > +                   bit 0: print all tasks info
> > +                   bit 1: print system memory info
> > +                   bit 2: print timer info
> > +                   bit 3: print locks info if CONFIG_LOCKDEP is on
> 
> > +                   bit 4: print ftrace buffer
> 
> Note, "ftrace_dump_on_oops" accomplishes the same thing.
> 
> Should this be a sysctl setting as well?

Thanks for the suggestion and note. I will add sysctl part in next version.

- Feng

Reply via email to