A problem we encounter with using ftrace-dump-on-oops is that our tracing overflows the pstore, losing the vital information of what caused the panic. Let's print that information after the traces instead of before so it should end up in the pstore for post-mortem.
Signed-off-by: Chris Wilson <[email protected]> Cc: Martin Peres <[email protected]> --- kernel/panic.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/kernel/panic.c b/kernel/panic.c index 9f35f1e31d06..3d8cfadeb098 100644 --- a/kernel/panic.c +++ b/kernel/panic.c @@ -172,10 +172,6 @@ void panic(const char *fmt, ...) console_verbose(); bust_spinlocks(1); - va_start(args, fmt); - vsnprintf(buf, sizeof(buf), fmt, args); - va_end(args); - pr_emerg("Kernel panic - not syncing: %s\n", buf); #ifdef CONFIG_DEBUG_BUGVERBOSE /* * Avoid nested stack-dumping if a panic occurs during oops processing @@ -217,6 +213,11 @@ void panic(const char *fmt, ...) */ atomic_notifier_call_chain(&panic_notifier_list, 0, buf); + va_start(args, fmt); + vsnprintf(buf, sizeof(buf), fmt, args); + va_end(args); + pr_emerg("Kernel panic - not syncing: %s\n", buf); + /* Call flush even twice. It tries harder with a single online CPU */ printk_safe_flush_on_panic(); kmsg_dump(KMSG_DUMP_PANIC); -- 2.18.0.rc2 _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
