| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Newer versions of the GNU assembler (observed with binutils 2.41) will
complain about the ".arch i386" in files assembled with "as --64",
with the message "Error: 64bit mode not supported on 'i386'".
Fix by moving ".arch i386" below the relevant ".code32" directive, so
that the assembler is no longer expecting 64-bit instructions to be used
by the time that the ".arch i386" directive is encountered.
Based on similar iPXE fix:
https://github.com/ipxe/ipxe/commit/6ca597eee
Signed-off-by: Michel Lind <michel@michel-slm.name>
Signed-off-by: Simon Horman <horms@kernel.org>
|
|
Add purgatory framework code, no specific implementation, just consistent
with other architectures.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@kernel.org>
|
|
Redhat CKI reported kdump kernel will hang a while very early after crash
triggered, then reset to firmware to reboot.
This failure can only be observed with kdump or kexec reboot via
kexec_load system call. With kexec_file_load interface, both kdump and
kexec reboot work very well. And further investigation shows that gcc
version 11 doesn't have this issue, while gcc version 12 does.
After checking the release notes of the latest gcc, Dave found out it's
because gcc 12 enables auto-vectorization for -O2 optimization level.
Please see below link for more information:
https://www.phoronix.com/scan.php?page=news_item&px=GCC-12-Auto-Vec-O2
Adding -fno-tree-vectorize to Makefile of purgatory can fix the issue.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
-mcmodel=large there
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add option to allow purgatory printing on arm64 hardware
by passing the console name which should be used.
Based on a patch by Geoff Levand.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There has been a lot of workarounds for purgatory disabling many
specified CFLAGS that will break purgatory. It will be better to not
let the CFLAGS used to compile purgatory honor the CFLAGS from
environment variables. So we will have stable CFLAGS for purgatory.
If anyone still wants to change purgatory CFLAGS, PURGATORY_EXTRA_CFLAGS
is still honored.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a new option --no-checks to kexec that allows for a fast
reboot by avoiding the purgatory integrity checks. This option is
intended for use by kexec based bootloaders that load a new
image and then immediately transfer control to it.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes warnings like these when building kexec for powerpc (32 bit):
console-ppc64.c: warning: ‘*((void *)&buff+8)’ may be used uninitialized
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
As seen in GCC's gcc/config/aarch64/aarch64.c, -fPIC with large
code model is unsupported. This fixes the "sorry, unimplemented"
errors when building with compilers defaulting to -fPIC.
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David Michael <david.michael@coreos.com>
|
|
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Change the default purgatory sha256 code optimization from -O0 to -O2, and add a
new arch specific makefile variable $(ARCH)_PURGATORY_SHA256_CFLAGS which can
over ride this default. Set ia64_PURGATORY_SHA256_CFLAGS to -O0 to retain the
previous optimization level for ia64.
The purgatory sha256 code needs the be built with -O0 for the ia64
architecture. Currently this code is built with -O0 for all architectures,
which slows down the calculations for architectures which could otherwise
use -O2.
On arm64, it takes around 20 second to verify SHA in purgatory when
vmlinuz image is around 13MB and initramfs is around 30M with -O2
enabled. Otherwise, it takes more than 2 minutes.
Cc: Pratyush Anand <panand@redhat.com>
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add kexec reboot support for ARM64 platforms.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Tested-By: Pratyush Anand <panand@redhat.com>
Tested-By: Matthias Brugger <mbrugger@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Commit a304e2d82a8c3 ("ppc64: purgatory: Reset primary cpu endian to
big-endian) changed bctr to rfid. rfid is book3s-only and will cause a
fatal exception on book3e.
Purgatory is an isolated environment which makes importing information
about the subarch awkward, so instead rely on the fact that MSR_LE
should never be set on book3e, and the rfid is only needed if MSR_LE is
set (and thus needs to be cleared). In theory that MSR bit is reserved
on book3e, rather than zero, but in practice I have not seen it set.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Reviewed-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Tested-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
meaning if we kexec from a little-endian kernel the target kernel will
fail to boot.
Returning to big-endian before we enter the target kernel ensures that
the target kernel can boot whether or not it includes FIXUP_ENDIAN.
This mirrors commit 150b14e7 in kexec-lite.
Signed-off-by: Samuel Mendoza-Jonas <sam.mj@au1.ibm.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 5edcbfd1368e84fce913ceeeca7b712c524dc20d.
Yinghai Lu has reported on the kexec mailing list that this causes
the following problem when using kexec load with kexec built on
openSUSE 13.1 64bit.
overflow in relocation type R_X86_64_32 val 21dffc020
|
|
If the toolchain has these things turned on automatically, then the
purgatory code might be miscompiled leading to runtime errors like:
Unhandled rela relocation: R_X86_64_GOTPC64
It might look like the problem is with the kernel when in reality,
kexec is complaining about the purgatory module. Force off harden
features that don't make sense in kernel space.
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
src addresses are not being incremented, so only first byte is compared
instead of first len bytes.
Signed-off-by: Pratyush Anand <panand@redhat.com>
Acked-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Summary of changes,
configure.ac: Add test for detect x32 ABI.
purgatory/arch/x86_64/Makefile: Not use mcmodel large when
x32 ABI is set.
kexec/arch/x86_64/kexec-elf-rel-x86_64.c: When x32 ABI is set
use ELFCLASS32 instead of ELFCLASS64.
kexec/kexec-syscall.h: Add correct syscall number for x32 ABI.
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
To better catch coding problems add stricter type checking to the
purgatory printf routines.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
To aid in debugging purgatory and its relocation generate a linker map
file when purgatory is built.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
To aid in debugging purgatory update its makefile to generate a
stand alone symbol file that can me loaded by a debugger.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
It seems some toolchains will put zero-initialized variables like purgatory's
sha256_regions into the BSS section. These symbols cannot be processed by
machine_apply_elf_rel() and lead to build errors. To avoid this problem add
the compiler flag no-zero-initialized-in-bss to the purgatory CFLAGS.
Fixes build errors like these:
Symbol: sha256_regions is in a bss section cannot set
Reported here:
http://lists.infradead.org/pipermail/kexec/2014-November/013052.html
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some Linux distributions would like to turn on the GCC exception handling
by default. As this option introduces symbols in the built code that are
defined in a separate shared library, this is not a good idea to have such
an option activated when building the purgatory.
This patch forces the exception handling to be turned off when building the
purgatory on ppc64 BE and LE.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The purgatory code reads the device tree's version and stores if needed the
currently running CPU number. These 2 values are stored in Big Endian
format in the device tree and should be byte swapped when running in Little
Endian mode.
Without this fix, when running in SMP environment, kexec or kdump kernel may
fail booting with the following message :
Failed to identify boot CPU
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some Linux distributions, like Suse, are turning on the GCC's stack
protection mechanism by default (-fstack-protector). When building the
purgatory with this option, this leads to link issues that are revealed at
runtime when the purgatory is loaded because symbols like __stack_chk_fail
are unresolved.
This patch forces this stack protection mechanism to be turned off when
building the purgatory on ppc64 BE and LE.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When the kernel is built with CONFIG_PPC_EARLY_DEBUG_OPAL set, it is
expecting to get r8 and r9 filled respectively with OPAL base address and
OPAL entry address (arc/power/head_64.S).
On the new powernv platform, having these 2 registers set allows the kernel
to perform OPAL calls before it parse the device tree.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When building in PPC64 little endian mode, the compiler is now using the
new ABI v2. Among other changes, this new ABI removes the function
descriptors and changes the way the TOC address is computed when entering a
C function.
The purgatory assembly part where the dot symbols are removed, and ELF
relocation code are impacted in this patch.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
RTAS is expecting parameters in Big Endian order so we have to byte swap
them in LE mode.
In the purgatory RTAS calls are only made for debug output.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch provides support for the new Power PC litte endian (LE) mode. The
LE mode only differs in the way the instructions and data are stored in memory
thus there is no real need to duplicate the ppc64 code.
However some compilation's options, especially for the purgatory, differ
between little and big endian mode's support. A new "SUBARCH" build variable
is introduced which is currently only used for PPC64 to specify the
endianness.
Another set of changes in this patch is fixing minor endianess issues in the
ppc64 code and fix an alignment issue raised on Power7 little endian mode.
Among these fixes, the check on the kernel binary endianess is removed,
since we can imagine kexecing a LE kernel from a BE environment, as far as
the specified root filesystem and initrd file are containing the right
binaries.
This patch depends on the patch "kexec/ppc64: use common architecture
fs2dt.c file" I sent earlier on the kexec mailing list.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The source file config.h is a generated file, so its preprocessor include path must be
relative to the build directory. Add that path to the purgatory CPPFLAGS.
Fixes build errors like these:
purgatory/arch/ppc/misc.S: fatal error: config.h: No such file or directory
Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This file is nowhere referenced, let's get rid of it.
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The clgfi instruction needs at least z9 machine level. To allow kexec-tools
compiled also with z900, this patch replaces clgfi with the older cghi
instruction.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove kexec/arch/i386/compat_x6_64.S
purgatory/arch/i386/linux-entry16.S and purgatory/arch/i386/entry16.S
Those were early attempts at entry32-16.S that should have been
deleted long ago.
Strip the purgatory code of debug symbols. There is no need to carry
debug symbols we will never use around in /sbin/kexec.
On x86_64 use -mcmodel=large so that the code is built without
any 32bit assumptions. -mcmodel=medium and -mcmodel=small
result int code that has 32bit relocations against variables
that can live anywhere in the address space
Modify the assembly in entry64.S and setup-x86_64.S to use %rip
relative addressing of variables so no relocates are emitted.
Modify entry64-32.S so that it does not have any relocations that can
not be processed when purgatory is loaded above 4G. entry64-32.S
jumps to a 32bit entry point and can not itself be used above 4G so
these changes merely prevent it from being a problem in the other case.
eip is modifed to be a 64bit value of which only the low 32bits are
exported outside of entry64-32.S
The long mode exit code is modified to run with a %cs value whose
base address is the address of the symbol entry32. From there
all of the 32bit code in entry64-32.S can read variables by reading
them through %cs. Until the final jump to the the target address
which is made a far jump reloading %cs and the intstruction pointer.
Modify entry32-16.S and entry32-16-debug.S to be position independent
32bit code. At their start make a short call to push the current value
of %eip on the stack and pop it off. Allowing the calculation of the
address of entry16 which the code has always kept in %ebx.
Update the pointer to the gdt in the gdt so that lgdt will work.
Modify the instructions in entry32-16.S and entry32-16-debug.S so
that the 32bit code uses offsets from %ebx which points at entry16.
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The latest commit 5e48916 has removed a line from purgatory/Makefile that was
responsible for building arch specific purgatory code. This causes kexec -p
(loading of panic kernel) to fail. This patch reverts the deleted line.
Verified this fix on x86_64 and ppc64.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Recently we faced an issue on power7 machine where kernel hanged in purgatory.
Some investigation revealed that gcc is generating hardware FPU instructions.
I have been told we can't use it at this point of time and as kernel is
compiled with -msoft-float for ppc/ppc64, so should be purgatory (as it runs
inside kernel context).
Thanks to Jakub Jelinek and Lingzhu Xiang for debugging and coming up with
a fix for this issue.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Tested-by: Lingzhu Xiang <lxiang@redhat.com>
Tested-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
commit 46b2d0b8a719 (kexec/powerpc fix optimization for size (gcc -Os)
build) added out of line GPR save/restore handlers for 32bit -Os
builds. This patch adds the handlers for 64bit builds.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Disable backup regions for BookE in case of a CRASH Dump, as they can
be run from anywhere.
The patch introduces --with-booke option to support the BookE.
With the patch, we get :
## On a 256M machine:
# busybox cat /proc/cmdline
init=/bin/init console=ttyS0,16550 crashkernel=128M@100M
# kexec -p root/vmlinux
usable memory rgns size:1 base:6400000 size:8000000
CRASH MEMORY RANGES
0000000000000000-0000000006400000
000000000e400000-0000000010000000
Command line after adding elfcorehdr: elfcorehdr=112380K
Command line after adding elfcorehdr: elfcorehdr=112380K savemaxmem=256M
Signed-off-by: Suzuki K. Poulose<suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For s390 we first want to check if kdump checksums are valid before we start
the kdump kernel. With this patch on s390 the purgatory entry point is
called with a parameter. If the parameter is "0", only the checksum test
is done and the result (0 = ok, 1 = invalid) is passed as return code back
to the caller (kernel). If the parameter is "1", the complete purgatory code
is executed and kdump is started.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds kdump support for s390 to the kexec tool and enables the
"--load-panic" option. When loading the kdump kernel and ramdisk we add the
address of the crashkernel memory to the normal load address.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
PPC32 ELF ABI expects r2 to be loaded with Thread Pointer, which is 0x7000
bytes past the end of TCB. Though the purgatory is single threaded, it uses
TCB scratch space in vsnprintf(). This patch allocates a 1024byte TCB
and populates the TP with the address accordingly.
Changes from V2: Avoid address overflow in TP allocation.
Changes from V1: Fixed the addr calculation for uImage support.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Cc: Ryan S. Arnold <rsa@us.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
gcc-4.6 does not accept --no-undefined as a compiler option
Reported-by: Civil <civil.over@gmail.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently we hard-coded the first 640K area as backup area,
however, this is not correct on some system which has reserved
memory area in the first 640K:
BIOS-e820: 0000000000010000 - 0000000000097000 (usable)
BIOS-e820: 0000000000097000 - 00000000000a0000 (reserved)
on such system we still mark all the first 640K as usable
in capture kernel, this will cause kernel panic.
The solution, pointed by Vivek, is that we can get the backup
area dynamically by reading /proc/iomem.
The reporter has tested this patch and it fixes the problem.
Signed-off-by: WANG Cong <amwang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
crt.S patch had fixes for gcc -Os (optimaze for size), same as
kernel has. Without this fixes powerpc gcc 4.4 generates forever
loop functions for kexec.
This happends because crtsavres code was spit up to individual files
(http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01294.html) and
kexec purgatory code has following options:
--no-undefined -nostartfiles -nostdlib -nodefaultlibs
So in that case crtasaveregs function are not defined and final object
file has been linked without them. This does not happen with applications
built without -nostdlib, because gcc will add it's standard functions.
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Acked-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 45e8f29639d9f97b74389e5bd28c7a5cccbf3e2a.
purgatory/arch/ppc/crt.S and purgatory/arch/ppc/misc.S are the same
files.
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Revert the revert patch specially made to remove
45e8f29639d9f97b74389e5bd28c7a5cccbf3e2a commit from git tree.
This reverts commit c42b92cd1f3c6c2e812bd1fcc4203672f3b6d461.
Revert "powerpc new toolchains fix (crt.S)"
This reverts commit 45e8f29639d9f97b74389e5bd28c7a5cccbf3e2a.
purgatory/arch/ppc/crt.S and purgatory/arch/ppc/misc.S are the same
files.
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 45e8f29639d9f97b74389e5bd28c7a5cccbf3e2a.
purgatory/arch/ppc/crt.S and purgatory/arch/ppc/misc.S are the same
files.
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Required in case if "-mabi=64" option was specified to build 64 bit mips
application, if not compiler tries to link 64 bit binaries with 32 bit
system libraries.
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Booting with uImage-ppc was broken by previous work, this
patch should restore it to working order
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Linker does not provide some vital functions when building freestanding
applications with a new toolchain, so we have to provide our own CRT.
p.s.
Without the CRT we won't see any build errors (since the purgatory is
linked with --no-undefined), but the purgatory code won't work,
'kexec -e' will just hang the board.
I added option to configure to keep code buildable for old toolchais.
But there should be way to do this automatically.
Author: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some code dtb scanning & filling has been borrowed from ppc64.
The old behavior is still available if compiled with GameCube,
other PowerPC platform use the can purgatory and specify a new
dtb.
Booting a self contained elf image (incl. dtb / without the need
for a bd sturct or the like) can be booted. The dtb support is currently
optional. That means if the elf image does not contain a dtb file then
the user has to supply a complete dtb (including mem size, command line,
bus freq., mac addr, ...)
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
x86_64 specific support, including crash memory range and purgatory setup.
Corresponding kernel support has been merged already.
Together with the kexec jump features in Linux kernel, kexec jump can
be used for following:
- A simple hibernation implementation without ACPI support. You can
kexec a hibernating kernel, save the memory image of original system
and shutdown the system. When resuming, you restore the memory image
of original system via ordinary kexec load then jump back.
- Kernel/system debug through making system snapshot. You can make
system snapshot with kexec/kdump, jump back, do some thing and make
another system snapshot.
- Cooperative multi-kernel/system. With kexec jump, you can switch
between several kernels/systems quickly without boot process except
the first time. This appears like swap a whole kernel/system out/in.
- A general method to call program in physical mode (paging turning
off). This can be used to invoke BIOS code under Linux.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Current x86/x86-64 kexec-tools print the message "I'm in purgatory" to serial
console/VGA while executing the purgatory code. Implement this feature for
POWERPC pseries platform by using the H_PUT_TERM_CHAR hypervisor call by
printng to hvc console.
Includes the changes suggested by Michael Ellerman
Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The kernel updated its ABI to tell the relocatable kernel to run
where it was loaded.
We now need to set a flag in the kernel image. Since we only have
the kernel image avialable as const data to kexec-tools c code, set
the flag in the copy we put in purgatory, and have it set the flag
in the kernel (after purgatory has run its checksum). To simplfy
the purgatory code we can always copy the flag word back to the
kernel as the c code made a copy of the original flag value.
Signed-off-by: Milton Miller <miltonm@bga.com>
Tested-by: M. Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
gcc complains because x86_setup_jump_back_entry() has no arguments,
making the argument list void resolves this.
Also, make the function static as it isn't used in any other files.
And move the function above where it is used, to eliminate the
need for a forward-declaration.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix a bug of kexec load on x86_64. Kexec fails to do load on x86_64, with
error message:
Symbol: cmdline_end not found cannot set
Because kexec/arch/i386/kexec-bzImage.c accesses cmdline_end symbol in
i386 purgatory, but there is no cmdline_end in x86_64 purgatory, and
kexec-bzImage.c is used by x86_64 too.
cmdline_end is added into x86_64 purgatory to solve the bug, because kexec
jump support for x86_64 is planned.
Reported-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
To support memory backup/restore an option named
--load-preserve-context is added to kexec. When it is specified
toggether with --mem-max, most segments for crash dump support are
loaded, and the memory range between mem_min to mem_max which has no
segments loaded are loaded as backup segments. To support jump back
from kexeced, options named --load-jump-back-helper and --entry are
added to load a helper image with specified entry to jump back.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Relocatable kdump kernel support in kexec-tools
This patch adds relocatable kernel support for kdump in the kexec-tools
code. A signature (0xfeed1234) is passed in r6 from panic code to the
purgatory code through kexec_sequence function. The signature is used to
differentiate between relocatable kdump kernel and non-kdump kernels.
The purgatory code compares the signature and sets the __kdump_flag in
head_64.S by using the offset with respect to next kernel load address.
During the boot up, kernel code checks __kdump_flag and if it is set, the
kernel will behave as relocatable kdump kernel.
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
As pointed out by Edgar E. Iglesias, the -fno-zero-initialized-in-bss
option to gcc is not available in the cris 3.2.1 toolchain.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The EFI Runtime Services Table contains pointers to ia64 function
descriptors. On existing, pre-Tiano, firmware, SetVirtualAddressMap()
converts *all* these pointers from physical to virtual. On Tiano-based
firmware, the pointer to the SetVirtualAddressMap() function descriptor
is not converted, so it remains a physical pointer.
The ia64 kexec purgatory patches the SetVirtualAddressMap() function
descriptor so that when the new kernel calls SetVirtualAddressMap(), it
never reaches firmware. Instead, it calls a dummy function that just
returns success.
Purgatory runs in physical mode, so it must convert the pointer from the
RuntimeServicesTable to a physical address. This patch makes that
conversion work both for old firmware (where the pointer is an identity-
mapped virtual address) and new Tiano firmware (where the pointer is a
physical address).
Without this patch, kexec on Tiano firmware causes an MCA because
ia64_env_setup() subtracts PAGE_OFFSET from a physical address and ends
up with an invalid physical address. Referencing that address causes
the MCA.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes following compiler warning:
purgatory/arch/i386/console-x86.c:84: \
warning: implicit declaration of function `outb'
purgatory/arch/i386/console-x86.c:89: \
warning: implicit declaration of function `inb'
Found on x86_64. The problem did not happen with i386.
Fix tested on x86_64-suse-linux and i586-suse-linux.
I also added __always_inline__ to make sure that the function gets always
inlined, regardless of optimisation compiler flags.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The generated code is byte-for-byte identical.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The entry16 and entry16_debug functions need to compute appropriate 16-bit
segments before dropping to real mode. Each is intended to use its own
entry address as the segment base. However, both were using the entry
address of entry16_debug, causing the code-segment reload to branch to the
wrong place in the non-debug case.
This bug was only visible when running kexec with --real-mode and without
--debug.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The undefined symbols naturally weren't relocated by kexec's linker, so
each compiled `call` instruction branched into the middle of itself. The
CPU proceeded to interpret the un-relocated address as instructions,
resulting in an undefined opcode fault. Since at this point no IDT is
loaded, that turned into a triple-fault and reboot.
The bug was only visible when running kexec with --console-vga.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently, CPPFLAGS and LDFLAGS can 'leak' into the purgatory build
from the main kexec/kexec object. Because of this, the purgatory
is build with -lz, but we may not have a zlib present for the
architecture of the purgatory object.
This change uses fresh CPPFLAGS and LDFLAGS for the purgatory object.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
From: Simon Horman <horms@verge.net.au>
Fix a typo and distribute $(mips_PURGATORY_SRCS) instead of
$(mips_PURGATORY_C_SRCS) as the latter is empty.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Sometimes I write nonsensical notes. When I wrote the comment
in purgatory/arch/x86_64/Makefile it was one of those times.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes kexec-tools on x86_64. The build had two problems:
1. The distribution missed the files
purgatory/arch/x86_64/entry64-32.S,
purgatory/arch/x86_64/entry64.S,
purgatory/arch/x86_64/setup-x86_64.S,
purgatory/arch/x86_64/stack.S,
purgatory/arch/x86_64/purgatory-x86_64.c
The problem was that variable expansion in a Makefile is a bit different
from the expectation, i.e. the final value is used even if the variable is
used in the middle.
2. The build didn't include the files mentioned above. This was because of
using '=' instead of '+=' in the 2nd part of the Makefile.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove purgatory/arch/mips/include/limits.h from distribution
as it no longer exists.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
[ Reposted with correct linux-mips address ]
Hi,
this patch switches the mips support in kexec-tools around a little bit.
All the files and directories containing "mipsel" have been renamed
to contain "mips" instead.
This is kind of consistent with the way that ARCH=mips in the kernel
works for both big and little endian.
After a small amount of tweaking, which is also included in this patch, the
code compiles and works fine for big endian mips as well as small endian
mips. All you need to do is compile using an appropriate compiler.
That is to say, kexec-tools's build system doesn't need to
be told about which endienness the code is being compiled for.
I have added kept mipsel as a supported "architecture" via ./configure,
though its just an alias for mips now. This is consistent with how
other architectures such as sh are treated. But I'm happy to remove
mipsel from ./configure if the mips people want that.
I tested this patch using qemu and the 2.6.24.3 tag of the mips-2.6 git
tree compiled for the qemu machine type for both big and little endian.
The qemu machine type has subsequently been removed, and kexec-tools
needs some work in order to function with qemu - as far as I understand
the way the boot parameters are passed needs to be fixed, likely
in purgatory. However, this is not related to the changes
introduced in this patch.
I intend to merge this patch into kexec-tools-testing if
no alarm bells are sounded.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
While trying to test latest kexec tools git code on a x86_64
box i ran into following issue. Kexec refused to load both
kexec and kdump kernels.
# ./build/sbin/kexec -l /boot/vmlinuz-2.6.25-rc5 --initrd=/boot/initrd-2.6.25-rc5
Symbol: entry32_regs not found cannot get
#
# ./build/kexec -p /boot/vmlinux-kdump --initrd=/boot/initrd-kdump
--append="...."
Symbol: entry64_regs not found cannot get
#
It turns out that entry64.S file under purgatory/arch/x86_64 was not
compiled. The original x86_64_PURGATORY_SRCS were being overwritten
in the Makefile.
Signed-Off-By: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove purgatory/arch/mipsel/include/limits.h as it is not needed.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove purgatory/arch/mipsel/include/stdint.h as it just duplicates
things found in system header files.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hello,
We developed a patch to port kexec-tools to mips arch and included support for
command line passing through elf boot notes.
We did it for a customer of ours on a specific platform derived from toshiba
tx4938 (so we think it should work at least for tx4938 evaluation board also).
We would like to contribute it in case somebody else needs it or wants to
improve it.
This patch works for us but the assembler part in particular, should be
considered as a starting point because my assembly knowledge is not too deep.
As this is the first time I submit a patch I tried to guess reading tpp.txt if
this is the right way to submit. Please let me know about any mistakes I may
have made.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
From my observations the way that the EFI_LOAD_DATA is provided
on the inital boot works like this:
There is a large EFI_CONVENTIONAL_MEMORY region.
The portion begining at the first load segment of
the image to be loading and ending with the last segment,
aligned to 64K, is turned into a separate region
of type EFI_LOAD_DATA.
A truncated example of this:
...
mem04: type= 7, attr=0x0000000000000008, range=[0x0000000000100000-0x0000000004000000) ( 63MB)
mem05: type= 2, attr=0x0000000000000008, range=[0x0000000004000000-0x000000000481f000) ( 8MB)
mem06: type= 7, attr=0x0000000000000008, range=[0x000000000481f000-0x000000003e876000) ( 928MB)
...
Where type 7 is EFI_CONVENTIONAL_MEMORY and
type 3 is EFI_LOAD_DATA.
There is a patch to the user-space portion of kexec-tools that merges the
segments supplied to this code if they are adjacent. This seems to always
result in a single segment being passed to this code, that should start
at the same address as the existing EFI_LOAD_DATA segment.
So all that should be left to do is to merge the existing
EFI_LOAD_DATA region with the following EFI_CONVENTIONAL_MEMORY region,
and then split it up to accommodate the segment passed from user-space.
The new EFI_LOAD_DATA region created with this code will always
start at the same address as the old EFI_LOAD_DATA region. If
this proves to be overly simplistic it should be easy to update.
This code also allows merging of multiple regions to accommodate
the new EFI_LOAD_DATA region. I strongly doubt this will ever
be used, but it is in line with the way the existing code works.
If the same image is used after kexec, then the
EFI regions in question will turn out the same as the original regions.
This is important, otherwise kernel / hypervisor regions will not be able
to be inserted into /proc/iomem / /proc/iomem_machine.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes following compilation warning:
purgatory/purgatory.c:21: warning: passing argument 2 of 'sha256_update' makes pointer from integer without a cast
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With the recent build changes a number of unneded files
crept into tarballs, including .o and .d files.
This patch is farily verbose, but hopefully in the long
run this system will be obvious enough to be maintainable.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Pugatory files need to be linked with the target linker,
not the build linker.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add ARM support to kexec including commandline support through ATAGs.
The kernel syscall support has already been merged and kernel ATAG
exporting is queued for 2.6.25 (its optional for kexec).
Based on work by various people, notably Uli Luckas <u.luckas@road.de>
for adding ATAG support.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use a $(clean) variable to store all items that need to be removed on
'make clean' (eg, .o files).
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
Conflicts:
Makefile.in
|
|
Since we use the implicit ruls for .c and .S, just colelct all sources
in the one variable.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Purgatory seems to partially duplicate system headers.
It seems a log cleaner not to do so.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This change makes kexec-tools work more like a standard configure-make-
make-install-type project:
* Remove $(OBJDIR) stuff. To do an out-of-tree build, just configure
from a different directory.
* Use the implicit Makefile rules more, and just edit the compiler
flags for specific targets.
* Simplify compiler/linker flags - no need for EXTRA_*
* Add TARGET_CC, and improve checks for BUILD_CC too.
* Set arch-specific flags in arch-specific makefiles, not conditional
on $(ARCH).
* Generate dependency files in the main compile, rather than as a
separate step.
* Don't #include sha256.c, but re-build it into the purgatory.
Still a work-in-progress.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Based on
http://cvs.fedora.redhat.com/viewcvs/rpms/kexec-tools/devel/kexec-tools-1.101-ppc-boots-ppc64.patch?rev=1.2&view=auto
64 bit: OK
32 bit: purgatory build fails
Work-in-progress-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Purgatory doesn't really care about the SMP cpus. But if we leave them
behind, they end up getting lost when the kernel overwrites purgatory or
the previous kernel. The current slave handling in purgatory doesn't
have any handshaking to make sure the cpus have moved on before leaving.
Instead of moving the slave cpus up to purgatory and then back down to
the kernel, just copy bytes 4-255 from the kernel and use it as the
purgatory start / slave hold block.
Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The address where the ELF core header is stored is passed to the secondary
kernel as a kernel command line option. The memory area for this header is
also marked as a separate EFI memory descriptor on ia64.
The separate EFI memory descriptor is at the moment of the type
EFI_UNUSABLE_MEMORY. With such a type the secondary kernel skips over the
entire memory granule (config option, 16M or 64M) when detecting memory.
If we are lucky we will just lose some memory, but if we happen to have data
in the same granule (such as an initramfs image), then this data will never
get mapped and the kernel bombs out when trying to access it.
So this is an attempt to fix this by changing the EFI memory descriptor
type into EFI_LOADER_DATA. This type is the same type used for the kernel
data and for initramfs. In the secondary kernel we then handle the ELF core
header data the same way as we handle the initramfs image.
This strategy requires changes in the secondary kernel as well, I'll
post the kernel patches in a little while.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Patch found on
http://eggplant.ddo.jp/www/download/debian26/source/kexec-tools/kexec-tools_1.101-2sh.diff.gz
According to Paul Mundt <lethal@linux-sh.org> it was originally by
kogiidena <kogiidena@eggplant.ddo.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Magnus Damm <magnus.damm@gmail.com>
|
|
Hi,
I've run into problems testing kexec/kdump on a Montecito revision C
processor. In purgatory, __dummy_efi_function is copied onto the end of
the command line boot parameter (command_line + command_line_len) and this
address is used to replace the EFI call to set_virtual_address_map(). The
copied range is then icache flushed.
The destination address is aligned to 16-bytes (in kexec-elf-ia64.c), but
the fc.i instruction flushes a 32-byte range "associated" with that
address. When my command line length is 16-byte aligned but not 32-byte
aligned, this results in the first 16-bytes of __dummy_efi_function getting
flushed (and the 16 bytes prior to that), but the second half of the
function (the part with the br.ret) does not get flushed. kdump then hangs
in purgatory. By adding a few spaces to my command line, it becomes both
16 and 32-byte aligned, and kdump works.
This patch makes icache_flush_range() align the start address to 32-bytes
and account for the difference. The patch is against Horms
kexec-tools-testing tree. As a side note, you could also fix this by just
adding 32 to the length passed to flush_icache_range() but that hides the
dependent behavior.
Thanks,
-T
It seems I was always testing with command line more than 16 bytes
length.....
Thanks.
Acked-by: Zou Nan hai <nanhai.zou@intel.com>
Manually applied - not sure why that was neccessary.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This adds vmm support to kexec-tool for ia64. This is annalogous
to the same feature that is present in the latest version of elilo.
It is a method of booting a vmm (hypervisor) such as Xen.
Essentially it works as follows.
* If the --vmm argument is not provided, then the kernel is booted as normal,
no changes
* Else, the image specified by --vmm is placed loaded into the elf
segments, where the Linux kernel image would otherwise have gone.
And the Linux kernel image, allong with its length is loaded into a
seprate segment, and passed as new entry at the end of the boot parameters.
This is somewhat similar to how initramfs/initramd images are passed
to a booting kernel, and can work in conjunction with that feature.
On boot (or in this case on kexec) the vmm (hypervisor) will be
loaded instead of a Linux kernel, and the hypervisor will then load up
the Linux kernel as it sees fit.
This is needed in order for kexec from Xen to Xen, using the
port of kexec to Xen that I am working on, to work.
I am not entirely fond of this design, and i think that developing
an ia64 variant of multiboot would be much nicer. However it is
an existing method that is currently in widespread use through
its incarntation in elilo. And if multiboot is added in future,
it can be done as a separate boot method, and thus orthogonal to this
patch.
In order to use this code a number of other changes are needed,
in particular:
1. Xen and the corresponding Linux Kernel needs to be patched with
the port of kexec to ia64-xen that I have been working on.
I will post the latest version of these patches to xen-devel
shortly.
2. The currently hardcoded PAGE_OFFSET value in purgatory needs
to be changed from the Linux value to the Xen value. I will
post a very hackish, definately not to be released, patch
after this patch which includes a comment that explains this problem
more clearly.
Also, xen->linux and linux->xen is still very much work in progress due
to the problem described at the following link
http://permalink.gmane.org/gmane.linux.ports.ia64/14995
However, from an infastructure point of view I think it would be good to
apply this code, so that kexec-tool is one step closer to being able to
support vmms (hypervisors). The patch does not alter any existing
behaviour, it just adds a new feature. Bugs asside, the only real danger
seems to be confusion for end-users, perhaps we could comment out the help
text to hide the feature from the lay user, or attach a big fat warning to it.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
[BUILD] CPPFLAGS, CFLAGS and LDFLAGS fixes
* Set internal CPPFLAGS as EXTRA_CPPFLAGS, CFLAGS as EXTRA_CFLAGS,
and LDFLAGS as EXTRA_LDFLAGS
- Don't overwrite CPPFLAGS, LDLFAGS or CFLAGS from the environment
- They are irrelevant for BUILD_CC
- When cross-compiling for a ppc64 host on a non-ppc64 host,
EXTRA_CFLAGS, which is included in BUILD_CPPFLAGS contains
-mcall-aixdesc, which does not work on i386 at least
* Use LDFLAGS when linking kexec
- Append rather than overwrite in purgatory/Makefile
The purpose of these changes is three-fold.
* CPPFLAGS, CFLAGS and LDFLAGS from the environment really ought
to be honoured. For one thing;
* Without these changes, the confgiure taget in
the toplevel makefile can't work
* Without these changes, cross compiling does not work -
well, I can't work out how to get it to work anyway.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Add a more verbose comment to explain why set_virtual_address_map is
replaced why a dummy function
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This unifies the comments in purgatory-ia64.c to always use C style
comments. Previously some comments where C style, while others were
C++ style.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This makes the tail of patch_efi_memmap() slightly less nested,
and thus a little easier to read.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Just use boot_param->efi_memdesc_size directly instead, it seems
at least as clean, and possibly easier to follow.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
len is assigned once and used once, just use boot_param->efi_memmap_size
directly instead.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
* Rename md1 and md2 to md_src and md_dest respectively to make things
a little easier to follow.
* Remove p1 and p2, use src and dest instead
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
There is a farily complex if, for construct in patch_efi_memmap(),
that seems to be simplifyable to a somewhat simpler while statement.
Note that this does change the logic statement. In particular
the original code has if (seg->end < mend) towards the end,
and the new code effectively replaces this with if (seg->end <= mend).
However, in the original code this is copled with a separate
if (seg->end > mend) check at the begining, so I believe that
this is actually a minor (possibly never seen) logic error in
the original code. The node code just always checks (seg->end > mend).
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This patch removes a duplicated assignment of *md2.
It also replaces a switch statement with an if statement
which is much more compact in this instance.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This patch reduces the nesting in patch_efi_memmap() by
jumping to the next interation of the inner for loop
if the following condition is true.
if (seg->start < mstart || seg->start >= mend)
This is instead of a reasonably large ammount of code inside the if
conditional if the converse is true.
This makes things somewhat easier to read as the nesting is already
quite deep, and many lines do not fit easily within 80 columns.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Make purgatory code 80 columns wide
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Remove kexec/arch/ia64/kexec-ia64.h.orig and purgatory/arch/ia64/Makefile.orig
which were (presumably accidently) introduced in changest
9241000f28eb6b86a06c0be2d6cf31498373bc1c, "kdump ia64".
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
SN platform support PIO in a different way to generic IA64 platform. It
does not support most of the legacy I/O ports.
Give an --noio option to kexec-tools to disable I/O in purgatory code.
This patch also removed an unused io.h in kexec-tools.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Edited to consistently use tabs instead of spaces for intentation,
remove one instance of trailing whitespace, and fix indentation
of noio line in options[].
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Currently DEBUG macro is being used at some places by purgatory code. We
need this DEBUG macro to be defined by user at compile time for including
or excluding the debug code. -DDEBUG is more common practice to use for
this purpose. Hence, changing DEBUG() to DEBUG_CHAR() and make space
for DEBUG to be defined by user.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
without this patch, crash tool will not able to analyze efi memmap of
first kernel from vmcore file.
This patch is against kexec-tools-1.101 with kdump10 patch.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Removed bogus fragments caused by whitespace addition
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The purgatory code in kexec-tools does not currently setup CS when booting a
64-bit ELF file such as a vmlinux file. This together with the fact that the
Linux kernel doesn't reload CS properly if booted from the 64-bit entry point
means that booting a vmlinux may fail under certain conditions.
The only known combination that triggers this problem is when kexec-tools and
kexec are used to load a x86_64 vmlinux under a dom0 Linux running under the
Xen hypervisor.
This patch is needed for sure to reload kernels with version <= 2.6.17. There
are fixes for this problem in the URL below, but if a fix will be included in
2.6.18 or not is unknown at this time.
http://permalink.gmane.org/gmane.linux.kernel/438998
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Removed some trailing whitespace
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Get rid of multiple definitions of backup region.
o Give more relevant name to backup source region.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
|
|
On Thu, Jul 27, 2006 at 12:32:56PM -0600, Eric W. Biederman wrote:
>
> I have found a couple of moments and have been able to
> catch up with most of the backlog of patches for kexec-tools.
> There are several details I need to follow up on, and there is
> some testing I want to do to make certain everything is working.
>
> The primary kexec-tools archive is:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/kexec-tools.git
>
> An archive to hold versions before 1.101 is at:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/kexec-tools-historic.git
>
> So far I have all version in there since 1.0 except 1.9, 1.92, and 1.93
> if someone happens to have a copy point me at it and I will update the
> history.
>
> Patches that hang out in quilt for a while can be annoying to import
> into git because their authorship information is not stored in an
> unambiguous way. git is general is much stricter about the format
> it's meta-data information is stored in.
>
> Maneesh in kdump10 there were two patches in particular that I have
> not sorted out their who wrote them. If you could help me sort that
> out I would appreciate it.
>
> ppc64-initrd-option.patch
> ppc64-kdump-device_tree-sort.patch
>
> Before I make a release here is my list of things I intend to look at:
> - Why we have defined the location of the crash backup region twice.
Hi Eric,
Are you referring to BACKUP_REGION_START and BACKUP_START declarations?
I am not sure why did I do that, may be somehow I thought that purgatory
code is not sharing the header files with main kexec code base.
Please have a look at the patch attached for i386. If this looks
fine, I shall generate the patches for x86_64 and ppc64 too.
Thanks & Regards
Vivek
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
|
|
On Fri, 2006-06-09 at 19:50, Welterlen Benoit wrote:
> Zou Nan hai wrote:
> > The ia64 kdump patch is in 2 parts.
> >
> > the kexec-kdump-ia64-2.6.16.patch should apply on top of the previous
> > kexec patch by Khalid in Tony's test tree.
> >
> > the kexec-tools-kdump-ia64.patch should apply to kexec-tools-1.101
> > with kexec-tools-1.101-kdump.patch
> >
> >
> > To test it.
> > Build first SMP kernel with KEXEC and KDUMP enabled.
> >
> > Boot it with kernel parameter "crashkernel=XXX@YYY"
> > means reserver XXX from YYY for crashdumping.
> > Build an UP kernel with KEXEC KDUMP VMCORE enabled.
> > load this kernel as a crashdumping kernel
> > kexec -p vmlinux.gz --initrd=initrd --append="...."
> >
> > trigger a crash,
> > maybe "echo c > /proc/sysrq-trigger"
> > after the crash kernel boots,
> > cp /proc/vmcore core
> >
> > gdb first_kernel_vmlinux core
> >
> > please test and review.
> >
> > Signed-off-by: Khalid Aziz <khalid_aziz@hp.com>
> > Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
> >
> >
> > https://lists.osdl.org/mailman/listinfo/fastboot
> >
>
> Hello Nan hai,
>
> I tried your patches. It seems that the kexec-tools-kdump-ia64.patch
> file can not be applied after the latest release of kexec-tools
> http://lse.sourceforge.net/kdump/patches/1.101-kdump9/kexec-tools-1.101-kdump9.patch
>
> I modified it for that. (attached file).
>
> I have a question about kdump :
>
> When the second kernel is loaded, kexec checks if the segments of the
> new kernel are in the reserved memory
>
> valid_memory_range in kexec/kexec.c :
> if ((send > mem_max) || (sstart < mem_min)) return 0;
>
> but mem_min and mem_max are defined by the XXX@YYY argument of the
> first kernel.
> For me, with 512@512 :
> more /proc/iomem
> ...
> 049cc000-77ffffff : System RAM
> 20000000-3fffffff : Crash kernel
> ...
> So, I can not load the second kernel : Invalid memory segment
> 0x4000000 - 0x469ffff
>
> When I set 64@64 argument for the first kernel, the checking is ok,
> but I have another issue :
> kexec_load failed: Cannot assign requested address
> entry = 0x80020 flags = 320001
> nr_segments = 6
> segment[0].buf = 0x6000000000021b90
> segment[0].bufsz = 20
> segment[0].mem = (nil)
> segment[0].memsz = 10000
> segment[1].buf = 0x60000000000222d0
> segment[1].bufsz = 10638
> segment[1].mem = 0x80000
> segment[1].memsz = 20000
> segment[2].buf = 0x2000000003b50010
> segment[2].bufsz = 23473c
> segment[2].mem = 0x100000
> segment[2].memsz = 240000
> segment[3].buf = 0x20000000002f0010
> segment[3].bufsz = 692dd8
> segment[3].mem = 0x4000000
> segment[3].memsz = 6a0000
> segment[4].buf = 0x2000000000990010
> segment[4].bufsz = 42c8
> segment[4].mem = 0x46a0000
> segment[4].memsz = 10000
> segment[5].buf = 0x20000000009a0010
> segment[5].bufsz = 17c3ec
> segment[5].mem = 0x46b0000
> segment[5].memsz = 2d0000
>
>
> Segments of the second kernel are the same than the first one
> (0x0000000004000000, 0x00000000046a0000 ...)
> We can not change the PHYSICAL_START as in other architectures (x86,
> x86_64, powerpc).
>
> So, I don't understand how it should work. Can you please have some
> explanation on this ?
>
> Thank you very much !
>
> Best regards,
>
> Benoit Welterlen
>
>
> ______________________________________________________________________
I modify the patch based on this one, fixed some bugs in it.
please test.
Thanks
Zou Nan hai
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch adds support for kexec-tools on ia64. This patch applies on
top of -kdump7 patch from <http://lse.sourceforge.net/kdump/>.
Signed-off-by: Khalid Aziz <khalid.aziz@hp.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch implements the purgatory support to take backup
of the first 32KB of the first kernel
- Modified the v2wrap code to make the secondary cpus spin
directly in the v2wrap after pulling them out of kexec_wait
- Use the elf_rel function support to set the various
symbols used in purgatory
- load device-tree as a separate segment
- other miscellaneous compiler warnings cleanup
- add purgatory code support for backup
- build purgatory as relocatable for ppc64
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o This patch adds the support for saving first 640k to the backup
region for x86_64.
Signed-off-by: Murali <muralim@in.ibm.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch builds v2wrap from within purgatory
Signed-off-by: Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o This patch adds support for reserving space for backup region. Also adds code
in purgatory to copy the first 640K to backup region.
o Moved kexec_flags inside kexec_info structure.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
--===============39718348520004598==
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi Milton,
first of all thanks for looking at the patches.
> 1) When patching the command line, you read the string from the
> optarg. While you clear the area in the kernel looking at
> COMMAND_LINE_SIZE, you do not limit the length that you copy into
> the kernel by this amount. This would seem like a buffer-overflow
> situation that could easily be trapped.
Yes, you're right. The kernel image could be damaged. Fixed.
> 2) I noticed your ramdisk code is quite similar in function to
> slurp_file in kexec/kexec.c. I realize this is probably a new
> function.
Fixed as well :)
> 3) Your elf-rel loading seem to not be implemented, but your probe
> returns 0 just like the image loader.
I think you're talking about the function machine_verify_elf_rel().
Unlike the probe functions this one should return 0 on error,
shouldn't it?
> 4) You seem to have several addresses hard-coded into the kexec-s390.h
> file. This would seem to limit the image you are loading, including
> any panic crash kernel options using the current scheme. I don't
> know your abi to know what other issues you might have with a more
> generic kexec to image interface. (It appears you setup your image
> to load as if it were from 0 but skipping IMAGE_READ_OFFSET bytes.
The hard coded addresses are part of the kernel abi. Nothing needs to
be changed here. Skipping the first 64k of the kernel image is ok too,
since you usually would only find a loader routine there which would
load the rest of the kernel image into ram and then start it.
If you are really interested you might have a look at
arch/s390/kernel/head.S in the kernel sources :)
Also we do not plan to use the kdump feature. It doesn't make too
much sense for the s390 architecture since we have already other
mechanisms which allow to reliably dump complete memory and register
contents at any given state of the system.
The patch below should be better (still against 1.101). Guess I will
come up with an improved kernel patch too.
Thanks,
Heiko
diffstat:
configure | 5 -
kexec/arch/s390/Makefile | 6 +
kexec/arch/s390/include/arch/options.h | 11 ++
kexec/arch/s390/kexec-elf-rel-s390.c | 23 +++++
kexec/arch/s390/kexec-image.c | 137 +++++++++++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.c | 104 +++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.h | 25 ++++++
kexec/kexec-syscall.h | 7 +
purgatory/arch/s390/Makefile | 7 +
purgatory/arch/s390/include/limits.h | 54 +++++++++++++
purgatory/arch/s390/include/stdint.h | 24 +++++
11 files changed, 402 insertions(+), 1 deletion(-)
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
