On Thu, Apr 18, 2019 at 01:01:52PM +0200, Petr Mladek wrote:
> On Thu 2019-04-18 17:00:44, Feng Tang wrote:
> > Hi Petr,
> >
> > On Thu, Apr 18, 2019 at 09:45:52AM +0200, Petr Mladek wrote:
> > > On Thu 2019-04-18 09:00:14, Sergey Senozhatsky wrote:
> > > > I think that PANIC_PRINT_ALL_PRINTK_MSG
On Thu 2019-04-18 17:00:44, Feng Tang wrote:
> Hi Petr,
>
> On Thu, Apr 18, 2019 at 09:45:52AM +0200, Petr Mladek wrote:
> > On Thu 2019-04-18 09:00:14, Sergey Senozhatsky wrote:
> > > I think that PANIC_PRINT_ALL_PRINTK_MSG is a debugging option; a quite
> > > specific one. So people who ask the
On (04/18/19 09:45), Petr Mladek wrote:
> The following functions are currently called from panic_print_sys_info():
>
> + show_state():
> printk(KERN_INFO
> " taskPC stack pid father\n");
> + show_mem():
> printk("Mem-Info:\n");
>
> + sysrq_tim
Hi Petr,
On Thu, Apr 18, 2019 at 09:45:52AM +0200, Petr Mladek wrote:
> On Thu 2019-04-18 09:00:14, Sergey Senozhatsky wrote:
> > I think that PANIC_PRINT_ALL_PRINTK_MSG is a debugging option; a quite
> > specific one. So people who ask the kernel to PANIC_PRINT_ALL_PRINTK_MSG
> > they know what t
On Thu 2019-04-18 09:00:14, Sergey Senozhatsky wrote:
> I think that PANIC_PRINT_ALL_PRINTK_MSG is a debugging option; a quite
> specific one. So people who ask the kernel to PANIC_PRINT_ALL_PRINTK_MSG
> they know what they are doing, and we probably will not cofuse anyone.
> After all, we don't pr
On (04/17/19 23:18), Feng Tang wrote:
> > > +++ b/kernel/printk/printk.c
> > > @@ -2549,6 +2549,14 @@ void console_flush_on_panic(void)
> > >*/
> > > console_trylock();
> > > console_may_schedule = 0;
> > > + if (flush_mode == CONSOLE_FLUSH_ALL) {
> > > + /*
> > > + * Can b
On Wed, Apr 17, 2019 at 02:24:58PM +0200, Petr Mladek wrote:
> On Wed 2019-04-17 19:50:10, Sergey Senozhatsky wrote:
> > On (04/17/19 18:46), Sergey Senozhatsky wrote:
> > >
> > > Does not look too complex/ugly.
> >
> > Looks simpler than adding one more global state to the
> > console_unlock() p
On Wed 2019-04-17 19:50:10, Sergey Senozhatsky wrote:
> On (04/17/19 18:46), Sergey Senozhatsky wrote:
> >
> > Does not look too complex/ugly.
>
> Looks simpler than adding one more global state to the
> console_unlock() printing loop.
>
> // Not tested at all //
>
> diff --git a/kernel/panic.c
On (04/17/19 18:46), Sergey Senozhatsky wrote:
>
> Does not look too complex/ugly.
Looks simpler than adding one more global state to the
console_unlock() printing loop.
// Not tested at all //
---
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 1fd45a8650e1..0fb78
On (04/17/19 11:18), Petr Mladek wrote:
> > My instant thought would be put the console_unlcok() and similar funcs
> > under CONFIG_PRINTK protection, while adding nop functions in the "else"
> > segment.
> >
> > But complexer question will be when CONFIG_PRINTK=n, how those console_xxx
> > functi
On Wed 2019-04-17 14:48:44, Feng Tang wrote:
> Hi Andrew,
>
> On Tue, Apr 16, 2019 at 09:19:22PM -0700, Andrew Morton wrote:
> > On Wed, 10 Apr 2019 23:37:18 +0800 Feng Tang wrote:
> >
> > > Currently on panic, kernel will lower the loglevel and print out
> > > new printk msg only with console_f
Hi Andrew,
On Tue, Apr 16, 2019 at 09:19:22PM -0700, Andrew Morton wrote:
> On Wed, 10 Apr 2019 23:37:18 +0800 Feng Tang wrote:
>
> > Currently on panic, kernel will lower the loglevel and print out
> > new printk msg only with console_flush_on_panic().
> >
> > Add an option for users to config
On Wed, 10 Apr 2019 23:37:18 +0800 Feng Tang wrote:
> Currently on panic, kernel will lower the loglevel and print out
> new printk msg only with console_flush_on_panic().
>
> Add an option for users to configure the "panic_print" to see
> all dmesg in buffer, some of which they may have never s
Currently on panic, kernel will lower the loglevel and print out
new printk msg only with console_flush_on_panic().
Add an option for users to configure the "panic_print" to see
all dmesg in buffer, some of which they may have never seen due
to the loglevel setting, which will help debugging too.
14 matches
Mail list logo