On (12/03/18 23:15), akpm@xxxxxxxxxxxxxxxxxxxx wrote: [..] > Feng Tang wrote: > [..] > > For people working in console mode, the screen will first show the panic > call stack, but immediately overridded 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. > > Removing the "local_irq_enable" will avoid the noisy message. > > The justification for the removing is: when code runs to this point, it > means user has chosed to not reboot, or do any special handling by using > the panic notifier method, no much point in re-enabling the interrupt. [..] > @@ -322,7 +322,6 @@ void panic(const char *fmt, ...) > } > #endif > pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf); > - local_irq_enable(); > for (i = 0; ; i += PANIC_TIMER_STEP) { > touch_softlockup_watchdog(); > if (i >= i_next) { Hmm, looking at 2.4 kernel: --- panic() --- ... sti(); for(;;) { #if defined(CONFIG_X86) && defined(CONFIG_VT) extern void panic_blink(void); panic_blink(); #endif CHECK_EMERGENCY_SYNC } ---------------- CHECK_EMERGENCY_SYNC is #define CHECK_EMERGENCY_SYNC \ if (emergency_sync_scheduled) \ do_emergency_sync(); And emergency_sync_scheduled is set by sysrq. I wonder if this is still the case - sysrq over serial, for instance, we want local irqs for that. -ss