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
