On (12/03/18 23:15), akpm@linux-foundation.org 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