summaryrefslogtreecommitdiffstats
path: root/arch/powerpc/xmon
diff options
context:
space:
mode:
authorMichael Ellerman <mpe@ellerman.id.au>2018-05-02 23:07:26 +1000
committerMichael Ellerman <mpe@ellerman.id.au>2018-06-03 20:43:42 +1000
commit7b08729cb272b4cd5c657cd5ac0dddae15a593ff (patch)
treec6f727c760e0bc39cf30aae936b5aa0f63ada55d /arch/powerpc/xmon
parent3e3786801b701cf03ee028fca786848d4865563e (diff)
downloadlinux-7b08729cb272b4cd5c657cd5ac0dddae15a593ff.tar.bz2
powerpc/64: Save stack pointer when we hard disable interrupts
A CPU that gets stuck with interrupts hard disable can be difficult to debug, as on some platforms we have no way to interrupt the CPU to find out what it's doing. A stop-gap is to have the CPU save it's stack pointer (r1) in its paca when it hard disables interrupts. That way if we can't interrupt it, we can at least trace the stack based on where it last disabled interrupts. In some cases that will be total junk, but the stack trace code should handle that. In the simple case of a CPU that disable interrupts and then gets stuck in a loop, the stack trace should be informative. We could clear the saved stack pointer when we enable interrupts, but that loses information which could be useful if we have nothing else to go on. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Diffstat (limited to 'arch/powerpc/xmon')
-rw-r--r--arch/powerpc/xmon/xmon.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 0561c14b276b..47166ad2a669 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -1172,6 +1172,10 @@ static int cpu_cmd(void)
/* try to switch to cpu specified */
if (!cpumask_test_cpu(cpu, &cpus_in_xmon)) {
printf("cpu 0x%lx isn't in xmon\n", cpu);
+#ifdef CONFIG_PPC64
+ printf("backtrace of paca[0x%lx].saved_r1 (possibly stale):\n", cpu);
+ xmon_show_stack(paca_ptrs[cpu]->saved_r1, 0, 0);
+#endif
return 0;
}
xmon_taken = 0;