powerpc: Adding the use of the firmware soft-reset-nmi to kdump.

[David Wilder]

This is a reposting of the patch posted on June 14.
http://ozlabs.org/pipermail/linuxppc-dev/2006-June/023705.html
I had no comments on my previous posting. It should be ready to pickup 
by Andrew or Paul.
The attached patch applies clean to the torvalds/linux-2.6.git
Thanks

- Patch Description
With this patch, kdump uses the firmware soft-rest NMI for two purposes:
1) Initiate the kdump (take a crash dump) by issuing a soft-reset.
2) Break a CPU out of a deadlock condition that is detected during kdump 
processing.

When a soft-reset is initiated each CPU will enter 
system_reset_exception() and set its corresponding bit in the global 
bit-array cpus_in_sr then call die(). When die() finds the CPU’s bit set 
in cpu_in_sr crash_kexec() is called to initiate a crash dump. The first 
CPU to enter crash_kexec() is called the “crashing CPU”. All other CPUs 
are “secondary CPUs”. The secondary CPU’s pass through to 
crash_kexec_secondary() and sleep. The crashing CPU waits for all CPUs 
to enter via soft-reset then boots the kdump kernel (see 
crash_soft_reset_check())

When the system crashes due to a panic or exception, crash_kexec() is 
called by panic() or die(). The crashing CPU sends an IPI to all other 
CPUs to notify them of the pending shutdown. If a CPU is in a deadlock 
or hung state with interrupts disabled, the IPI will not be delivered. 
The result being, that the kdump kernel is not booted. This problem is 
solved with the use of a firmware generated soft-reset. After the 
crashing_cpu has issued the IPI, it waits for 10 sec for all CPUs to 
enter crash_ipi_callback(). A CPU signifies its entry to 
crash_ipi_callback() by setting its corresponding bit in the 
cpus_in_crash bit array. After 10 sec, if one or more CPUs have not set 
their bit in cpus_in_crash we assume that the CPU(s) is deadlocked. The 
operator is then prompted to generate a soft-reset to break the 
deadlock. Each CPU enters the soft reset handler as described above.

Two conditions must be handled at this point:
1) The system crashed because the operator generated a soft-reset. See 
#1 above.
2) The system had crashed before the soft-reset was generated ( in the 
case of a Panic or oops…).

The first CPU to enter crash_kexec() uses the state of the kexec_lock to 
determine this state. If kexec_lock is already held then condition 2 is 
true and crash_kexec_secondary() is called, else; this CPU is flagged as 
the crashing CPU, the kexec_lock is acquired and crash_kexec() proceeds 
as described above.

Each additional CPUs responding to the soft-reset will pass through 
crash_kexec() to kexec_secondary(). All secondary CPUs call 
crash_ipi_callback() readying them self's for the shutdown. When ready 
they clear their bit in cpus_in_sr. The crashing CPU waits in 
kexec_secondary() until all other CPUs have cleared their bits in 
cpus_in_sr. The kexec kernel boot is then started.

Signed-off-by: Haren Myneni <haren at us.ibm.com <https://ozlabs.org/mailman/listinfo/linuxppc-dev>>
Signed-off-by: David Wilder <dwilder at us.ibm.com <https://ozlabs.org/mailman/listinfo/linuxppc-dev>>
-- 




-- 
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA 
dwilder at us.ibm.com
(503)578-3789

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppc64-softreset-in-k-dump-2.6.17-git.patch
Type: text/x-patch
Size: 10067 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20060623/68b5860a/attachment.bin>