linux-toradex.git/arch/powerpc/kernel/machine_kexec_64.c, branch v4.2.7

kexec: add IND_FLAGS macro

2015-02-17T22:34:51+00:00

Add a new kexec preprocessor macro IND_FLAGS, which is the bitwise OR of
all the possible kexec IND_ kimage_entry indirection flags.  Having this
macro allows for simplified code in the prosessing of the kexec
kimage_entry items.  Also, remove the local powerpc definition and use the
generic one.

Signed-off-by: Geoff Levand 
Acked-by: Benjamin Herrenschmidt 
Acked-by: Vivek Goyal 
Cc: Arnd Bergmann 
Cc: Maximilian Attems 
Cc: Michal Marek 
Cc: H. Peter Anvin 
Cc: Paul Bolle 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

powerpc/kdump: Ignore failure in enabling big endian exception during crash

2014-12-29T04:44:53+00:00

In LE kernel, we currently have a hack for kexec that resets the exception
endian before starting a new kernel as the kernel that is loaded could be a
big endian or a little endian kernel. In kdump case, resetting exception
endian fails when one or more cpus is disabled. But we can ignore the failure
and still go ahead, as in most cases crashkernel will be of same endianess
as primary kernel and reseting endianess is not even needed in those cases.
This patch adds a new inline function to say if this is kdump path. This
function is used at places where such a check is needed.

Signed-off-by: Hari Bathini 
[mpe: Rename to kdump_in_progress(), use bool, and edit comment]
Signed-off-by: Michael Ellerman

powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode

2014-05-28T03:24:26+00:00

If we try to perform a kexec when the machine is in ST (Single-Threaded) mode
(ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we
get the following messages during boot:

[    0.089866] POWER8 performance monitor hardware support registered
[    0.089985] power8-pmu: PMAO restore workaround active.
[    5.095419] Processor 1 is stuck.
[   10.097933] Processor 2 is stuck.
[   15.100480] Processor 3 is stuck.
[   20.102982] Processor 4 is stuck.
[   25.105489] Processor 5 is stuck.
[   30.108005] Processor 6 is stuck.
[   35.110518] Processor 7 is stuck.
[   40.113369] Processor 9 is stuck.
[   45.115879] Processor 10 is stuck.
[   50.118389] Processor 11 is stuck.
[   55.120904] Processor 12 is stuck.
[   60.123425] Processor 13 is stuck.
[   65.125970] Processor 14 is stuck.
[   70.128495] Processor 15 is stuck.
[   75.131316] Processor 17 is stuck.

Note that only the sibling threads are stuck, while the primary threads (0, 8,
16 etc) boot just fine. Looking closer at the previous step of kexec, we observe
that kexec tries to wakeup (bring online) the sibling threads of all the cores,
before performing kexec:

[ 9464.131231] Starting new kernel
[ 9464.148507] kexec: Waking offline cpu 1.
[ 9464.148552] kexec: Waking offline cpu 2.
[ 9464.148600] kexec: Waking offline cpu 3.
[ 9464.148636] kexec: Waking offline cpu 4.
[ 9464.148671] kexec: Waking offline cpu 5.
[ 9464.148708] kexec: Waking offline cpu 6.
[ 9464.148743] kexec: Waking offline cpu 7.
[ 9464.148779] kexec: Waking offline cpu 9.
[ 9464.148815] kexec: Waking offline cpu 10.
[ 9464.148851] kexec: Waking offline cpu 11.
[ 9464.148887] kexec: Waking offline cpu 12.
[ 9464.148922] kexec: Waking offline cpu 13.
[ 9464.148958] kexec: Waking offline cpu 14.
[ 9464.148994] kexec: Waking offline cpu 15.
[ 9464.149030] kexec: Waking offline cpu 17.

Instrumenting this piece of code revealed that the cpu_up() operation actually
fails with -EBUSY. Thus, only the primary threads of all the cores are online
during kexec, and hence this is a sure-shot receipe for disaster, as explained
in commit e8e5c2155b (powerpc/kexec: Fix orphaned offline CPUs across kexec),
as well as in the comment above wake_offline_cpus().

It turns out that cpu_up() was returning -EBUSY because the variable
'cpu_hotplug_disabled' was set to 1; and this disabling of CPU hotplug was done
by migrate_to_reboot_cpu() inside kernel_kexec().

Now, migrate_to_reboot_cpu() was originally written with the assumption that
any further code will not need to perform CPU hotplug, since we are anyway in
the reboot path. However, kexec is clearly not such a case, since we depend on
onlining CPUs, atleast on powerpc.

So re-enable cpu-hotplug after returning from migrate_to_reboot_cpu() in the
kexec path, to fix this regression in kexec on powerpc.

Also, wrap the cpu_up() in powerpc kexec code within a WARN_ON(), so that we
can catch such issues more easily in the future.

Fixes: c97102ba963 (kexec: migrate to reboot cpu)
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat 
Signed-off-by: Benjamin Herrenschmidt

powerpc: Fix endian issues in kexec and crash dump code

2014-02-11T00:24:52+00:00

We expose a number of OF properties in the kexec and crash dump code
and these need to be big endian.

Cc: stable@vger.kernel.org # v3.13
Signed-off-by: Anton Blanchard 
Signed-off-by: Benjamin Herrenschmidt

powerpc/kexec: kexec_sequence() is in misc_64.S

2013-10-30T05:02:18+00:00

Correct reference to the location of the kexec_sequence() assembly helper.
There never was a kexec_stub.S in mainline.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Benjamin Herrenschmidt

powerpc/kexec: Fix kexec when using VMX optimised memcpy

2013-05-14T04:36:23+00:00

commit b3f271e86e5a (powerpc: POWER7 optimised memcpy using VMX and
enhanced prefetch) uses VMX when it is safe to do so (ie not in
interrupt). It also looks at the task struct to decide if we have to
save the current tasks' VMX state.

kexec calls memcpy() at a point where the task struct may have been
overwritten by the new kexec segments. If it has been overwritten
then when memcpy -> enable_altivec looks up current->thread.regs->msr
we get a cryptic oops or lockup.

I also notice we aren't initialising thread_info->cpu, which means
smp_processor_id is broken. Fix that too.

Signed-off-by: Anton Blanchard 
Cc:  # 3.6+
Signed-off-by: Benjamin Herrenschmidt

powerpc/kexec: Disable hard IRQ before kexec

2013-02-23T16:49:28+00:00

Disable hard IRQ before kexec a new kernel image.
Not doing it can result in corrupted data in the memory segments
reserved for the new kernel.

Signed-off-by: Phileas Fogg 
CC: 
Signed-off-by: Benjamin Herrenschmidt

powerpc+of: Rename the drivers/of prom_* functions to of_*

2012-11-15T01:56:52+00:00

Rename the prom_*_property routines of the generic OF code to of_*_property.
This brings them in line with the naming used by the rest of the OF code.

Signed-off-by: Nathan Fontenot 
Acked-by: Geoff Levand 
Acked-by: Rob Herring 
Acked-by: Grant Likely 
Signed-off-by: Benjamin Herrenschmidt

treewide: convert uses of ATTRIB_NORETURN to __noreturn

2012-01-13T04:13:03+00:00

Use the more commonly used __noreturn instead of ATTRIB_NORETURN.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Joe Perches 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Haavard Skinnemoen 
Cc: Hans-Christian Egtvedt 
Cc: Tony Luck 
Cc: Fenghua Yu 
Acked-by: Geert Uytterhoeven 
Acked-by: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Chris Metcalf 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

treewide: remove useless NORET_TYPE macro and uses

2012-01-13T04:13:03+00:00

It's a very old and now unused prototype marking so just delete it.

Neaten panic pointer argument style to keep checkpatch quiet.

Signed-off-by: Joe Perches 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Haavard Skinnemoen 
Cc: Hans-Christian Egtvedt 
Cc: Tony Luck 
Cc: Fenghua Yu 
Acked-by: Geert Uytterhoeven 
Acked-by: Ralf Baechle 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Chris Metcalf 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds