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

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (12/06/18 11:58), Feng Tang wrote:
> > 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.

I'm not sure what to do about this. I think that the behaviour is platform
specific. For instance, arm64 keeps secondary CPUs in a busy loop
	while (1)
		cpu_relax();

(masked out) and on panic_cpu disables only SDEI (interrupts from firmware,
if I got it right); so it seems that arm64 can handle IRQs after panic. And
if there are platforms that handle IRQ (including sysrq) after panic, then
both options - making printk a noop or keeping local irqs off - maybe can
cause some problems. Or maybe not. We better ask arch people.

Personally, on my x86 laptop, I'd prefer the srollback to work after panic.
Just my 5 cents.

	-ss