| Age | Commit message (Collapse) | Author |
|---|
|
2nd kernel hangs early because of a regression caused by below commit:
commit 68262155d8c661586b809bc5301a7dff1c378137
Author: Andrew Jones <drjones@redhat.com>
Date: Fri Nov 20 12:31:53 2015 -0500
kexec/fs2dt: cleanup pathname
putnode() will add the trailing '/', avoid having two. Also
pathstart is unused, get rid of it.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
The actual purpose of the commit is to avoid double slash in pathname.
But unfortunately in function putnode() we have below magics to get the node
name:
basename = strrchr(pathname,'/') + 1;
...
strcpy((void *)dt, *basename ? basename : "");
...
strcat(pathname, "/");
We treat none zero basename as a node name, then concat a slash to open the
directory for later property handling.
pathname originally was "/proc/device-tree/" so for the first run of putnode
it will cause double slashes. With the commit above mentioned there are no
double slashes but we will copy "device-tree" to dt. Thus kexec kernel is not
happy..
Instead let's fix it by only concating slash when the basenanme is not empty
and restore the initial value of pathname as "/proc/device-tree/"
Note: I only reproduce the issue with loading older kernel like 3.10 in RHEL. I do
not see the problem in new kernels in Fedora.
Signed-off-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
logged_chars would be set to 0 by `dmesg -c`, but full dmesg is useful
for debugging. So instead of using logged_chars directly, we calculate
it by ourselves.
Now logged_chars is set to the minimum of log_end and log_buf_len, as
the same logic as crash utility is using.
Signed-off-by: Dangyi Liu <dliu@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
It needs to know this because the SMP release mechanism for Freescale
book3e is different from when booting with normal hardware. In theory
we could simulate the normal spin table mechanism, but not (easily) at
the addresses U-Boot put in the device tree -- so there'd need to be
even more communication between the kernel and kexec to set that up.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 8a1aa35a1077b42bc2a2afb05d24b637e1edf2a1.
|
|
Crash kernel region size is available via sysfs on Linux running on
bare metal. However, this does not work when Linux runs as Xen dom0.
In this case Xen crash kernel region size should be established using
__HYPERVISOR_kexec_op hypercall (Linux kernel kexec functionality does
not make a lot of sense in Xen dom0). Sadly hypercalls are not easily
accessible using shell scripts or something like that. Potentially we
can check "xl dmesg" output for crashkernel option but this is not nice.
So, let's add this functionality, for Linux running on bare metal and
as Xen dom0, to kexec-tools. This way kdump scripts may establish crash
kernel region size in one way regardless of platform. All burden of
platform detection lies on kexec-tools.
Figure (and unit) displayed by this new kexec-tools functionality is
the same as one taken from /sys/kernel/kexec_crash_size.
This functionality is available on x86 platform only. If idea is acceptable
then I can prepare patches for other platforms (if it is possible and make
sense) and repost them as fully flagged patch series.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
It appears that (older?) revisions of xenctl.h define
all of the E820_* values used in kexec-x86-common.c except
E820_PMAM and E820_PMEM. This results in a build failure when
building against libxenctl.
Avoid this problem by providing local definitions of those values.
It seems reasonable to do so in the kexec-x86-common.c as
currently that is the only source file that uses the values in question.
Fixes: 56a12abc1df1 ("kexec: fix mmap return code handling")
Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Cc: Petr Tesarik <ptesarik@suse.com>
Cc: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When mmap fails, MAP_FAILED (that is, (void *) -1) is returned. Currently
we assume that NULL is returned. Fix this and add the MAP_FAILED check.
Fixes: 95741713e790 ("kexec/s390x: use mmap instead of read for slurp_file")
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Previously when sorting the device tree directory entries, if both
device tree entries contained the '@' character then comparison was
made based on the length of the strings.
This did not work in all cases and could result in odd orderings.
This patch modifies the comparison function for the case when both
strings contain the '@' character.
First a lexical comparison is made between the prefix portions of the
strings *before* the '@' character.
Next, if the prefixes are equal, the lengths of the suffixes *after*
the '@' character are compared. This preserves the intent of the
original code.
Next, if the suffix lengths are equal, a lexical comparison of the
suffixes is made.
This is still not strictly correct, as ideally the portion after the
'@' should be compared numerically. However, determining what base to
use for all case is difficult.
Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Latest linux kernel will create /sys/firmware/fdt file. It will be convenient
to use it in case one does not specify --atags and --dtb options.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Check /chosen/stdout-path first, as linux,stdout-path is deprecated.
I don't know how the ppc64:my_debug thing works, but on arm the warning
"Unable to find /proc/device-tree//chosen/linux,stdout-path, printing
from purgatory is diabled" is output when loading a kexec kernel. This
patch at least suppresses that when /chosen/stdout-path exists, and
maybe it even enables printing from purgatory?
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
putnode() will add the trailing '/', avoid having two. Also
pathstart is unused, get rid of it.
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
booting a non-devicetree kernel from a devicetree kernel failed,
since the memory layout wasn't passed.
Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
starting 'kexec -l /dev/mmcblk0p1' fails since the size of
a block device can not be determined with stat
Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The slurp_fd() function allocates memory and uses the read() system call.
This results in double memory consumption for image and initrd:
1) Memory allocated in user space by the kexec tool
2) Memory allocated in kernel by the kexec() system call
The following illustrates the use case that we have on s390x:
1) Boot a 4 GB Linux system
2) Copy kernel and 1,5 GB ramdisk from external source into tmpfs (ram)
3) Use kexec to boot kernel with ramdisk
Therefore for kexec runtime we need:
1,5 GB (tmpfs) + 1,5 GB (kexec malloc) + 1,5 GB (kernel memory) = 4,5 GB
This patch introduces slurp_file_mmap() which for "normal" files uses
mmap() instead of malloc()/read(). This reduces the runtime memory
consumption of the kexec tool as follows:
1,5 GB (tmpfs) + 1,5 GB (kernel memory) = 3 GB
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When createing fdt from /proc/device-tree, if there's local --command-line
option provided but there's no root= specified, kexec-tools will copy the root=
param from 1st kernel cmdline by default. In case one want kexec boot without
root= it will be impossible.
Thus add the new option so that one can provide --dt-no-old-root for above
mentioned case.
Reported-by: Jan Stodola <jstodola@redhat.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When createing fdt from /proc/device-tree, if there's local --command-line
option provided but there's no root= specified, kexec-tools will copy the root=
param from 1st kernel cmdline by default. In case one want kexec boot without
root= it will be impossible.
Thus add the new option so that one can provide --dt-no-old-root for above
mentioned case.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Split the copy old root param code to a new function dt_copy_old_root_param
Also add a global variable dt_no_old_root, do not copy root param when
dt_no_old_root == 1. It will be used in later patches.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 7ab842d8a004f6cd75a9d7b3528e4a70819ce4ef.
using mmap by default in slurp_file cause segment fault while later
reallocing dtb_buf during my arm kexec test.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Produce a warning-free build on ppc64 (at least, when built as 64-bit
userspace -- if a 64-bit binary for ppc64 is a requirement, why is -m64
set only on purgatory?). Mostly unused (or write-only) variable
warnings, but also one nasty one where reserve() was used without a
prototype, causing long long arguments to be passed as int.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When building a 32 bit version of kexec-tools for powerpc64
set the default powerpc64 SUBARCH as BE.
Fixes build errors like these:
powerpc-linux-gnu/bin/ld: unrecognised emulation mode: elf64lppc
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec-tools build fails on my laptop with RHEL7.1 installed:
gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include -I./util_lib/include -Iinclude/ -I./kexec/arch/x86_64/include -c -MD -o kexec/arch/i386/kexec-x86-common.o kexec/arch/i386/kexec-x86-common.c
In file included from kexec/arch/i386/kexec-x86-common.c:36:0:
kexec/arch/i386/../../kexec.h:19:2: error: #error BYTE_ORDER not defined
#error BYTE_ORDER not defined
^
kexec/arch/i386/../../kexec.h:23:2: error: #error LITTLE_ENDIAN not defined
#error LITTLE_ENDIAN not defined
^
kexec/arch/i386/../../kexec.h:27:2: error: #error BIG_ENDIAN not defined
#error BIG_ENDIAN not defined
^
In file included from kexec/arch/i386/kexec-x86-common.c:37:0:
kexec/arch/i386/../../kexec-syscall.h: In function ‘kexec_load’:
kexec/arch/i386/../../kexec-syscall.h:74:2: warning: implicit declaration of function ‘syscall’ [-Wimplicit-function-declaration]
return (long) syscall(__NR_kexec_load, entry, nr_segments, segments, flags);
^
make: *** [kexec/arch/i386/kexec-x86-common.o] Error 1
The build error was introduced by below commit:
commit c9c21cc107dcc9b6053e39ead1069e03717513f9
Author: Baoquan He <bhe@redhat.com>
Date: Thu Aug 6 19:10:55 2015 +0800
kexec: use _DEFAULT_SOURCE instead to remove compiling warning
Now compiling will print warning like below. Change code as it suggested.
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
^
See manpage: http://man7.org/linux/man-pages/man7/feature_test_macros.7.html
_BSD_SOURCE has been deprecated since glibc 2.20, To allow code that requires
_BSD_SOURCE in glibc 2.19 and earlier and _DEFAULT_SOURCE in glibc 2.20 and
later to compile without warnings, define both _BSD_SOURCE and _DEFAULT_SOURCE.
Thus fix it by adding back _BSD_SOURCE along with _DEFAULT_SOURCE.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There may be more than one crash kernel regions on x86. Currently,
kexec-tools picks the largest one. If high reservation is smaller
than low, it will try to load panic kernel low. However, the kexec
syscall checks that target address is within crashk_res boundaries,
so attempts to load crash kernel low result in -EADDRNOTAVAIL, and
kexec prints out this error message:
kexec_load failed: Cannot assign requested address
Looking at the logic in arch/x86/kernel/setup.c, there are only two
possible layouts:
1. crashk_res is below 4G, and there is only one region,
2. crashk_res is above 4G, and crashk_low_res is below 4G
In either case, kexec-tools must pick the highest region.
Changelog:
* v3: rename function to get_crash_kernel_load_range
* v2: remove unnecessary local variables
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
While readng crash note, count_cpu variable will be never decreased in case
any failure to read the sysfs file.
The issue was found during I test CONFIG_KEXEC_FILE only kernel option.
crash_notes are exported to sysfs only for CONFIG_KEXEC. In latest kernel
we can configure kernel with CONFIG_KEXEC_FILE only in Kconfig. In this
case, if you run a kernel with kexec_file only but do not specify "-s"
in kexec-tools arguments, then kexec-tools will hang there.
Though "-s" is mandatory for kexec_file_load, kexec should still fail out
instead of hanging.
Fixing the problem by always decreasing count_cpu in the for loop.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The slurp_fd() function allocates memory and uses the read() system call.
This results in double memory consumption for image and initrd:
1) Memory allocated in user space by the kexec tool
2) Memory allocated in kernel by the kexec() system call
Therefore use mmap() for non-character devices to reduce the runtime
memory consumption of the kexec tool.
The following use case illustrates the usefulness of this patch a bit more:
1) Boot a 4 GB Linux system
2) Read kernel and 1,5 GB ramdisk from external source into local tmpfs (ram)
3) kexec the kernel and ramdisk
Without this patch for the kexec runtime we need:
1,5 GB (tmpfs) + 1,5 GB (kexec malloc) + 1,5 GB (kernel memory) = 4,5 GB
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.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>
|
|
kexec --version reports like below:
kexec-tools 2.0.7 released 05 February 2015
The date string is generated when one run bootstrap script, thus
it is more like a build date instead of release date.
Even for distribution like Fedora it will make more sense if it can
report something like "kexec-tools 2.0.7-1 released 05 February 2015"
In case building from git tree, the date cause more confusion.
So let's remove it from version string unless there is better idea
to resolve the issue.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Kernel add E820_PRAM or E820_PMEM type for NVDIMM memory device.
Now support them in kexec too.
Reported-by: Toshi Kani <toshi.kani@hp.com>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Now compiling will print warning like below. Change code as it suggested.
# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
^
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add .git to version so it doesn't look like a release.
This is just so when people build code from git it can
be identified as such from the version string.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.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>
|
|
Currently, the two options must be the last ones to be honored;
otherwise, they can get silently ignored and both the manpage and help
text point it out. This is error-prone and trivial to fix. There
isn't much point in pointing something out in documentation when the
peculiarity can be removed with four lines of extra code.
Update option handling so that the two arguments are honored
regardless of their positions.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
During kernel develoment, kexec can be used to get out of sticky
situations without going through possibly lenghty reboot; however,
there are situations where the filesystem and/or storage stack are
known to be misbehaving and performing sync before kexecing is
dangerous or just never finishes.
This patch implement -y (--no-sync) option which makes kexec skip
syncing in the similar way as -x (--no-ifdown).
Signed-off-by: Tejun Heo <tj@kernel.org>
Suggested-by: Chris Mason <clm@fb.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When try to compile with zlib fails due to configure.ac
bad expansion caused by x32 ABI test that needs AC_PROG_CC
for use AC_EGREP_CPP.
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
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>
|
|
gcc 4.9.1 tells me this variable is set but unused
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>
|
|
Commit 4362bfac changes params for kexec_iomem_for_each_line from
'unsigned long' to 'unsigned long long'.
This patch fixes forgotten changes for sh and x86 archs.
Bug causes incorrect parsing of memory ranges.
Signed-off-by: Roman Pen <r.peniaev@gmail.com>
Cc: kexec@lists.infradead.org
Signed-off-by: Simon Horman <horms@verge.net.au>
|
