Hi Sergey,
On Tue, Dec 11, 2018 at 05:07:43PM +0900, Sergey Senozhatsky wrote:
On (12/10/18 16:57), Petr Mladek wrote:
(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.
Yes, this is very valid concern. And after Petr and you raised it, I did some experiments with 3 x86 platforms at my hand, one Apollolake IOT device with serial console, one IvyBridge laptop and one Kabylake NUC, the magic key all works well before panic, and fails after panic. But I did remember the PageUp/PageDown key worked on some laptop years ago. And you actually raised a good question: what do we expect for the post-panic kernel?
I am not sure why it does not work. But it would be nice if sysrq worked.
Absolutely.
[..]
I still think that calming down printk() is acceptable when it can be restored from sysrq.
I would agree; peeking one of the two solutions, printk patch is probably preferable.
I think that only few people might be interested into debugging post-panic problems. We could print a warning for them about that printk() has got disabled.
Dunno. This _maybe_ (speculation!) can upset folks on those platforms that have sysrq working after panic. printk is a common code.
I'm probably missing a lot of things here, but just in case, I'm not sure at which point the idea of patching some files under arch/x86 directory was ruled out and why.
Here is the v1 patch: https://lkml.org/lkml/2018/10/11/304
And actually no one ruled out the v1 patch :), I don't have HW of other archs like arm/ppc, so I just read some of the arch code, and found most of them use the similar flow like x86, that's why I chosed to finding a soluton inside panic.c itself.
Thanks, Feng