Hi Sergey, On Wed, Dec 05, 2018 at 12:05:55PM +0900, Sergey Senozhatsky wrote: > On (12/05/18 11:50), Sergey Senozhatsky wrote: > > > > panic_print_sys_info() can be very verbose, and it happens much later > > than dump_stack() from panic CPU. So you are guaranteed to have same > > problems you are trying to avoid: "the original context gets > > lost on screen" and "confused people post bad bug reports". > > > > And it probably would be _a bit_ better to do panic_print_sys_info() > before console_flush_on_panic(). > > --- > debug_locks_off(); > - console_flush_on_panic(); > - > panic_print_sys_info(); > + console_flush_on_panic(); > --- Current situation of kernel panic print is like this: 1. local_irq_disable() 2. panic stack dump ----> Msg A 3. local_irq_enable() 4. lots of WARN() ----> Msg B Msg A is what we need, and Msg B is want we want to eliminate. https://lkml.org/lkml/2018/11/27/459 has the example log for kernel panic. My v3 patch is to remove the step 3, keep the IRQ disabled to avoid Msg B. Given the sysrq and led blinking concerns brought by you and Petr, I'm trying to test the panic_blink way while keeping the step 3 of local_irq_enable() Thanks, Feng
