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
