Messages in this thread | | | Date | Fri, 1 Mar 2019 11:06:14 +0100 | From | Petr Mladek <> | Subject | Re: [PATCH v6] panic: Avoid the extra noise dmesg |
| |
On Fri 2019-03-01 16:49:46, Feng Tang wrote: > When kernel panic happens, it will first print the panic call stack, > then the ending msg like: > > [ 35.743249] ---[ end Kernel panic - not syncing: Fatal exception > [ 35.749975] ------------[ cut here ]------------ > > The above message are very useful for debugging. > > But if system is configured to not reboot on panic, say the "panic_timeout" > parameter equals 0, it will likely print out many noisy message like > WARN() call stack for each and every CPU except the panic one, messages > like below: > > WARNING: CPU: 1 PID: 280 at kernel/sched/core.c:1198 set_task_cpu+0x183/0x190 > Call Trace: > <IRQ> > try_to_wake_up > default_wake_function > autoremove_wake_function > __wake_up_common > __wake_up_common_lock > __wake_up > wake_up_klogd_work_func > irq_work_run_list > irq_work_tick > update_process_times > tick_sched_timer > __hrtimer_run_queues > hrtimer_interrupt > smp_apic_timer_interrupt > apic_timer_interrupt > > For people working in console mode, the screen will first show the panic > call stack, but immediately overridden by these noisy extra messages, which > makes debugging much more difficult, as the original context gets lost on > screen. > > Also these noisy messages will confuse some users, as I have seen many bug > reporters posted the noisy message into bugzilla, instead of the real panic > call stack and context. > > Adding a flag "suppress_printk" which gets set in panic() to avoid those > noisy messages, without changing current kernel behavior that both panic > blinking and sysrq magic key can work as is, suggested by Petr Mladek. > > To verify this, make sure kernel is not configured to reboot on panic and > in console > # echo c > /proc/sysrq-trigger > to see if console only prints out the panic call stack. > > Suggested-by: Petr Mladek <pmladek@suse.com> > Signed-off-by: Feng Tang <feng.tang@intel.com>
The patch looks fine to me:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards, Petr
| |