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