• David Wilder's avatar
    [POWERPC] Add the use of the firmware soft-reset-nmi to kdump. · c0ce7d08
    David Wilder authored
    With this patch, kdump uses the firmware soft-reset 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
    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: default avatarHaren Myneni <haren@us.ibm.com>
    Signed-off-by: default avatarDavid Wilder <dwilder@us.ibm.com>
    Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
    c0ce7d08
kexec.c 27.5 KB