On (12/05/18 09:53), Feng Tang wrote:
I think that we could simply clear panic_blinking from __handle_sysrq(). The user will still be able to capture the screen before touching the keyboard. But it will keep the things simple.
I hope that we did not miss anything else. Anyway, the approach with making printk a nop still looks like the best maintainable solution to me.
I will setup a platform which can handle sysrq request and try your suggestion. thanks,
I don't entirely understand this patch series, sorry. So you want to keep local IRQs disabled to, supposedly, have less printk-s between dump_stack() from panic CPU and "end Kernel panic" marker; yet at the same time you add *significantly* more printk-s between dump_stack() from panic CPU and "end Kernel panic" marker.
panic_print_sys_info() can be very verbose, and it happens much later than dump_stack() from panic CPU. So you are guaranteed to have same problems you are trying to avoid: "the original context gets lost on screen" and "confused people post bad bug reports".
Am I missing something?
Dunno. Just a bunch of ideas (raw ideas). Is something like below going to work for you instead?
---
@@ -327,6 +327,9 @@ void panic(const char *fmt, ...) #endif pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf); local_irq_enable(); + + dump_stack(); + for (i = 0; ; i += PANIC_TIMER_STEP) { touch_softlockup_watchdog(); if (i >= i_next) {
---
Or... *Maybe* you can even do a ratelimited dump_stack() from that PANIC_TIMER_STEP loop. Say, one dump_stack() every 10 minutes. The WARN_ON noise should stop at some point.
-ss