Re: + panic-avoid-the-extra-noise-dmesg.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 05, 2018 at 11:46:20PM +0800, Feng Tang wrote:
> On Wed, Dec 05, 2018 at 05:00:44PM +0900, Sergey Senozhatsky wrote:
> > On (12/05/18 14:29), Sergey Senozhatsky wrote:
> > > On (12/05/18 11:57), Sergey Senozhatsky wrote:
> > > > On (12/05/18 10:47), Feng Tang wrote:
> > >
> > > OK... So, apparently, what's happening is panic() calls smp_send_stop().
> > > And smp_send_stop()->native_stop_other_cpus() on x86 disables local APIC.
> > > So no fun anymore.
> > >
> > > If I keep APIC enabled on panic CPU, then I have my keyboard working,
> > > including PageUp-PageDown scrolling, sysrq handling, and so on.
> > 
> > Meeh, it's much harder than this. Worked on one machine only.
> 
> Same here, I tried on several platforms and hardly get the sysrq magic key
> working, though it works while system is running.
> 
> And it make me wondering if those workqueue dependent led blinking code
> can still really work.

Also, IMHO, if we need a panic blink method, it should better be simple
and robust with only HW registers access plus delay function, as I'm not
sure if the scheduling can still work. 

Anyway, can I propose to make the "local_irq_enable" conditional and off
by default, and add a warning.

@@ -295,7 +295,10 @@ void panic(const char *fmt, ...)
 	}
 #endif
 	pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
-	local_irq_enable();
+	if (panic_keep_irq_on)
+		local_irq_enable();
+	else
+		pr_emerg("Please add panic_keep_irq_on to cmdline, if you want blink/sysrq work");
 	for (i = 0; ; i += PANIC_TIMER_STEP) {
 		touch_softlockup_watchdog();
 		if (i >= i_next) {

Any comments? thanks!

- Feng

> 
> > 
> > > PeterZ,
> > >   for those folks who sometimes have to use framebuffer for debugging
> > >   (just a trivial "let me scrollback and see the panic backtrace") and
> > >   not always have access to serial console, can we have local APIC
> > >   enabled on the panic_cpu? Or is it a terrible thing to ask for?
> > 
> > The question remains: can we have input irqs on panic_cpu after panic?
> 
> With current kernel, the irq is still enabled for the panic CPU, I did
> see timer and some device's ISR get called, but they will only fire IRQ
> one time after panic triggered.
> 



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux