From acda13733c82a9a429393238a0bb3aff5cea1675 Mon Sep 17 00:00:00 2001 From: David Wilder Date: Thu, 29 Jun 2006 15:17:30 -0700 Subject: [PATCH] --- yaml --- r: 33382 b: refs/heads/master c: eac8392f9591b359847b8a6abb75ca60967bcecd h: refs/heads/master v: v3 --- [refs] | 2 +- trunk/arch/powerpc/kernel/traps.c | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/[refs] b/[refs] index 0b622ce11e01..8cff0e26e1e1 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: 81b73dd92b97423b8f5324a59044da478c04f4c4 +refs/heads/master: eac8392f9591b359847b8a6abb75ca60967bcecd diff --git a/trunk/arch/powerpc/kernel/traps.c b/trunk/arch/powerpc/kernel/traps.c index 2105767fcc57..5147175f921c 100644 --- a/trunk/arch/powerpc/kernel/traps.c +++ b/trunk/arch/powerpc/kernel/traps.c @@ -211,6 +211,19 @@ void system_reset_exception(struct pt_regs *regs) die("System Reset", regs, SIGABRT); + /* + * Some CPUs when released from the debugger will execute this path. + * These CPUs entered the debugger via a soft-reset. If the CPU was + * hung before entering the debugger it will return to the hung + * state when exiting this function. This causes a problem in + * kdump since the hung CPU(s) will not respond to the IPI sent + * from kdump. To prevent the problem we call crash_kexec_secondary() + * here. If a kdump had not been initiated or we exit the debugger + * with the "exit and recover" command (x) crash_kexec_secondary() + * will return after 5ms and the CPU returns to its previous state. + */ + crash_kexec_secondary(regs); + /* Must die if the interrupt is not recoverable */ if (!(regs->msr & MSR_RI)) panic("Unrecoverable System Reset");