linux.git/include/asm-powerpc/kexec.h, branch master

powerpc: Move include files to arch/powerpc/include/asm

2008-08-04T02:02:00+00:00

from include/asm-powerpc.  This is the result of a

mkdir arch/powerpc/include/asm
git mv include/asm-powerpc/* arch/powerpc/include/asm

Followed by a few documentation/comment fixups and a couple of places
where  was being used explicitly.  Of the latter only
one was outside the arch code and it is a driver only built for powerpc.

Signed-off-by: Stephen Rothwell 
Signed-off-by: Paul Mackerras

powerpc: Provide dummy crash_shutdown_register

2008-06-30T12:30:55+00:00

When kexec is disabled, the crash_shutdown_{un,}register
functions are not available in the kernel.
This provides dummy inline functions for those so that
the callers don't have to worry about it.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Paul Mackerras

[POWERPC] kdump shutdown hook support

2008-01-25T11:52:50+00:00

This adds hooks into the default_machine_crash_shutdown so drivers can
register a function to be run in the first kernel before we hand off
to the second kernel.  This should only be used in exceptional
circumstances, like where the device can't be reset in the second
kernel alone (as is the case with eHEA).  To emphasize this, the
number of handles allowed to be registered is currently #def to 1.

This uses the setjmp/longjmp code around the call out to the
registered hooks, so any bogus exceptions we encounter will hopefully
be recoverable.

Tested with bogus data and instruction exceptions.

Signed-off-by: Michael Neuling 
Signed-off-by: Paul Mackerras

kdump/kexec: calculate note size at compile time

2007-05-08T18:15:07+00:00

Currently the size of the per-cpu region reserved to save crash notes is
set by the per-architecture value MAX_NOTE_BYTES.  Which in turn is
currently set to 1024 on all supported architectures.

While testing ia64 I recently discovered that this value is in fact too
small.  The particular setup I was using actually needs 1172 bytes.  This
lead to very tedious failure mode where the tail of one elf note would
overwrite the head of another if they ended up being alocated sequentially
by kmalloc, which was often the case.

It seems to me that a far better approach is to caclculate the size that
the area needs to be.  This patch does just that.

If a simpler stop-gap patch for ia64 to be squeezed into 2.6.21(.X) is
needed then this should be as easy as making MAX_NOTE_BYTES larger in
arch/asm-ia64/kexec.h.  Perhaps 2048 would be a good choice.  However, I
think that the approach in this patch is a much more robust idea.

Acked-by:  Vivek Goyal 
Signed-off-by: Simon Horman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[POWERPC] Make crash.c work on 32-bit and 64-bit

2006-08-17T06:41:10+00:00

To compile kexec on 32-bit we need a few more bits and pieces. Rather
than add empty definitions, we can make crash.c work on 32-bit, with
only a couple of kludges.

Signed-off-by: Michael Ellerman 
Signed-off-by: Paul Mackerras

[POWERPC] Add the use of the firmware soft-reset-nmi to kdump.

2006-06-28T05:18:52+00:00

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: Haren Myneni 
Signed-off-by: David Wilder 
Signed-off-by: Paul Mackerras

[POWERPC] Make kexec_setup() a regular initcall

2006-06-28T01:59:47+00:00

There's no reason kexec_setup() needs to be called explicitly from
setup_system(), it can just be a regular initcall.

Signed-off-by: Michael Ellerman 
Signed-off-by: Paul Mackerras

[PATCH] powerpc: Move crashkernel= handling into the kernel.

2006-05-19T05:02:18+00:00

This was missing a quilt ref.

Signed-off-by: Paul Mackerras

[PATCH] powerpc: Unify mem= handling

2006-05-19T05:02:15+00:00

We currently do mem= handling in three seperate places. And as benh pointed out
I wrote two of them. Now that we parse command line parameters earlier we can
clean this mess up.

Moving the parsing out of prom_init means the device tree might be allocated
above the memory limit. If that happens we'd have to move it. As it happens
we already have logic to do that for kdump, so just genericise it.

This also means we might have reserved regions above the memory limit, if we
do the bootmem allocator will blow up, so we have to modify
lmb_enforce_memory_limit() to truncate the reserves as well.

Tested on P5 LPAR, iSeries, F50, 44p. Tested moving device tree on P5 and
44p and F50.

Signed-off-by: Michael Ellerman 
Signed-off-by: Paul Mackerras

[PATCH] fix kexec asm

2006-03-08T22:15:04+00:00

While testing kexec and kdump we hit problems where the new kernel would
freeze or instantly reboot.  The easiest way to trigger it was to kexec a
kernel compiled for CONFIG_M586 on an athlon cpu.  Compiling for CONFIG_MK7
instead would work fine.

The patch fixes a few problems with the kexec inline asm.

Signed-off-by: Chris Mason 
Acked-by: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds