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 <ch...@chris-wilson.co.uk>
Cc: Martin Peres <martin.pe...@linux.intel.com>
---
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
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
