[PATCH] 2 of 3 kdump-ppc64-soft-reset-fixes

[David Wilder]

- When a system hangs, user will activate the soft-reset to initiate the 
kdump boot. But, soft-reset behavior is indeterminate on sending FWNMI 
to all CPUS. i.e, all CPUs will not get FW NMI at the same time. When 
the first CPU entered (calling primary CPU here onwards) kdump using 
crash_kexec(), sends an IPI to other CPUs. Some CPUs will respond to 
this IPI and execute crash_ipi_callback()  before receive NMI. When they 
receive FW NMI, will execute die() and waiting forever since no more 
kdump IPI coming from the primary CPU. This issue will be fixed by 
invoking crash_kexec_secondary() directly from die().

Since the secondary CPUs will enter the IPI_callback function two times, 
CPU states have to be saved only once and the primary CPU has to start 
kdump boot after all CPUs are stopped. Hence, cpus_in_crash bitmap is 
used to determine whether pt_regs is saved. If the bit is not set, regs 
will be saved. Introduced cpus_in_sr bitmap and enter_on_soft_reset 
counter which are used to let the primary CPU know that all secondary 
CPUs entered via soft-reset and ready to do down.

- For the crash scenario, when a CPU hangs with interrupts disabled and 
the other CPUs panic or user invoked kdump boot using sysrq-c. In this 
case, the hung CPU can not be stopped and causes the kdump boot not 
successful. This case can be treated as complete system hang and asks 
the user to activate soft-reset if all secondary CPUs are not stopped.

Please pick-up this patch. (Note this patch is dependent on 
kdump-image-rm-static.patch, see my earlier posting)

-- 
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: kdump-ppc64-soft-reset-fixes.patch
Type: text/x-patch
Size: 10588 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20060410/987d817e/attachment.bin>