| Age | Commit message (Collapse) | Author |
|---|
|
Since kernel 4.17-rc2 s390 supports the kexec_file_load system call. Add
the new system call to kexec-tools and provide the -s (--kexec-file-syscall)
option for s390 to support this new feature.
Signed-off-by: Philipp Rudo <prudo@linux.ibm.com>
Acked-by: Dave Young <dyoung@redhat.com>
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>
|
|
Fixes warnings like these when building kexec for powerpc (32 bit):
kexec-elf-rel-ppc64.c: warning: cast from pointer to integer of different size
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):
crashdump-ppc64.h: warning: large integer implicitly truncated to unsigned type
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):
kexec.c: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘uint64_t
Signed-off-by: Geoff Levand <geoff@infradead.org>
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>
|
|
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: Simon Horman <horms@verge.net.au>
|
|
Do not fall through to "--mem-min" when "-p" option is parsed. The
break statement was apparently removed by mistake...
Fixes: cb434cbe6f40 ("kexec: Do not special-case the -s option")
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Normally vmlinux for arm64 is of ET_EXEC type, while if built with
CONFIG_RANDAMIZE_BASE (that is KASLR), it will be of ET_DYN type.
Meanwhile, physical address field of segments in vmlinux has actually
the same value as virtual address field.
Accordingly, in this case, it totally makes no sense to check for
validity of segments against physical memory ranges and, if necessary,
relocate them in elf_exec_load() on arm64.
This patch allows to unconditionally skip the check on arm64.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
supported
Not all architectures implement KEXEC_FILE_LOAD. However, on some
archiectures KEXEC_FILE_LOAD is required when secure boot is enabled in
locked-down mode. Previously users had to select the KEXEC_FILE_LOAD
syscall with undocumented -s option. However, if they did pass the
option kexec would fail on architectures that do not support it.
So add an -a option that tries KEXEC_FILE_LOAD and when it is not
supported tries KEXEC_LOAD.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The undocumented -s option selects KEXEC_FILE_LOAD syscall but there is
no option to select KEXEC_LOAD syscall. Add it so -s can be reverted.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
It is parsed separately to save a few CPU cycles when setting up other
options but it just complicates the code. So fold it back and set up all
flags for both KEXEC_LOAD and KEXEC_FILE_LOAD
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When kexec_file_load support was added some sanity checks were not updated.
Some options are set only in the kexec_load flags so cannot be supported
wiht kexec_file_load. On the other hand, reserved memory is needed for
kdump with both kexec_load and kexec_file_load.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When the kernel does not know a syscall number it returns -ENOSYS but
when kexec does not know a syscall number it returns -1. Return -ENOSYS
from kexec as well.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
PPC64 kernel now supports kexec_file_load system call. Leverage it by
enabling that support here. Note that loading crash kernel with this
system call is not yet supported in the kernel and trying to load one
will fail with '-ENOTSUPP' error.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Include the stack and malloc space in our calculation of the zImage
size, both of which must be avoided when locating the dtb.
Signed-off-by: Russell King <rmk@armlinux.org.uk>
|
|
Add further debugging of the kernel size
Signed-off-by: Russell King <rmk@armlinux.org.uk>
|
|
Signed-off-by: Russell King <rmk@armlinux.org.uk>
|
|
Add support to parse the new 'ibm,dynamic-memory-v2' property in the
'ibm,dynamic-reconfiguration-memory' node. This replaces the old
'ibm,dynamic-memory' property and is enabled in the kernel with a
patch series that starts with commit 0c38ed6f6f0b ("powerpc/pseries:
Enable support of ibm,dynamic-memory-v2"). All LMBs that share the same
flags and are adjacent are grouped together in the newer version of the
property making it compact to represent larger memory configurations.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a helper function for adding ranges to avoid duplicating code.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With modern drm/kms graphic driver kexec-tools does not setup screen_info
correctly so one will only see screen output after those drm drivers
reinitializing after rebooting. Copying the old screen info from original
boot_params will help during my test, although it could not work for some
potential cases, but it is not worse than before. This has been used in
the kernel kexec_file_load.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch is a follow-on to commit 894bea93 "kexec-tools: Perform
run-time linking of libxenctrl.so". This patch addresses feedback
from Daniel Kiper.
This patch implements Daniel's suggestion to make the
xc_dlhandle variable static, insert missing 'extern'
qualifier for the new __xc() wrappers, and correct some
style issues.
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch is a follow-on to commit 43d3932e "kexec-tools: Perform
run-time linking of libxenctrl.so". This patch addresses feedback
from Daniel Kiper.
In the original patch, the call to dlclose() was omitted, in contrast
to the description in the commit message. This patch inserts the call.
Note that this dynamic linking feature is dependent upon the proper
operation of the RTLD_NODELETE flag to dlopen(), which does work as
advertised on Linux (otherwise the call to dlclose() should be omitted).
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When kexec is utilized in a Xen environment, it has an explicit
run-time dependency on libxenctrl.so. This dependency occurs
during the configure stage and when building kexec-tools.
When kexec is utilized in a non-Xen environment (either bare
metal or KVM), the configure and build of kexec-tools omits
any reference to libxenctrl.so.
Thus today it is not currently possible to configure and build
a *single* kexec that will work in *both* Xen and non-Xen
environments, unless the libxenctrl.so is *always* present.
For example, a kexec configured for Xen in a Xen environment:
# ldd build/sbin/kexec
linux-vdso.so.1 => (0x00007ffdeba5c000)
libxenctrl.so.4.4 => /usr/lib64/libxenctrl.so.4.4 (0x00000038d8000000)
libz.so.1 => /lib64/libz.so.1 (0x00000038d6c00000)
libc.so.6 => /lib64/libc.so.6 (0x00000038d6000000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000038d6400000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038d6800000)
/lib64/ld-linux-x86-64.so.2 (0x000055e9f8c6c000)
# build/sbin/kexec -v
kexec-tools 2.0.16
However, the *same* kexec executable fails in a non-Xen environment:
# copy xen kexec to .
# ldd ./kexec
linux-vdso.so.1 => (0x00007fffa9da7000)
libxenctrl.so.4.4 => not found
liblzma.so.0 => /usr/lib64/liblzma.so.0 (0x0000003014e00000)
libz.so.1 => /lib64/libz.so.1 (0x000000300ea00000)
libc.so.6 => /lib64/libc.so.6 (0x000000300de00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000300e200000)
/lib64/ld-linux-x86-64.so.2 (0x0000558cc786c000)
# ./kexec -v
./kexec: error while loading shared libraries:
libxenctrl.so.4.4: cannot open shared object file: No such file or directory
At Oracle we "workaround" this by having two kexec-tools packages,
one for Xen and another for non-Xen environments. At Oracle, the
desire is to offer a single kexec-tools package that works in either
environment. To achieve this, kexec-tools would either have to ship
with libxenctrl.so (which we have deemed as unacceptable), or we can
make kexec perform run-time linking against libxenctrl.so.
This patch is one possible way to alleviate the explicit run-time
dependency on libxenctrl.so. This implementation utilizes a set of
macros to wrap calls into libxenctrl.so so that the library can
instead be dlopen() and obtain the function via dlsym() and then
make the call. The advantage of this implementation is that it
requires few changes to the existing kexec-tools code. The dis-
advantage is that it uses macros to remap libxenctrl functions
and do work under the hood.
Another possible implementation worth considering is the approach
taken by libvmi. Reference the following file:
https://github.com/libvmi/libvmi/blob/master/libvmi/driver/xen/libxc_wrapper.h
The libxc_wrapper_t structure definition that starts at line ~33
has members that are function pointers into libxenctrl.so. This
structure is populated once and then later referenced/dereferenced
by the callers of libxenctrl.so members. The advantage of this
implementation is it is more explicit in managing the use of
libxenctrl.so and its versions, but the disadvantage is it would
require touching more of the kexec-tools code.
The following is a list libxenctrl members utilized by kexec:
Functions:
xc_interface_open
xc_kexec_get_range
xc_interface_close
xc_kexec_get_range
xc_interface_open
xc_get_max_cpus
xc_kexec_get_range
xc_version
xc_kexec_exec
xc_kexec_status
xc_kexec_unload
xc_hypercall_buffer_array_create
xc__hypercall_buffer_array_alloc
xc_hypercall_buffer_array_destroy
xc_kexec_load
xc_get_machine_memory_map
Data:
xc__hypercall_buffer_HYPERCALL_BUFFER_NULL
These were identified by configuring and building kexec-tools
with Xen support, but omitting the -lxenctrl from the LDFLAGS
in the Makefile for an x86_64 build.
The above libxenctrl members were referenced via these source
files.
kexec/crashdump-xen.c
kexec/kexec-xen.c
kexec/arch/i386/kexec-x86-common.c
kexec/arch/i386/crashdump-x86.c
This patch provides a wrapper around the calls to the above
functions in libxenctrl.so. Every libxenctrl call must pass a
xc_interface which it obtains from xc_interface_open().
So the existing code is already structured in a manner that
facilitates graceful dlopen()'ing of the libxenctrl.so and
the subsequent dlsym() of the required member.
The patch creates a wrapper function around xc_interface_open()
and xc_interface_close() to perform the dlopen() and dlclose().
For the remaining xc_ functions, this patch defines a macro
of the same name which performs the dlsym() and then invokes
the function. See the __xc_call() macro for details.
There was one data item in libxenctrl.so that presented a
unique problem, HYPERCALL_BUFFER_NULL. It was only utilized
once, as
set_xen_guest_handle(xen_segs[s].buf.h, HYPERCALL_BUFFER_NULL);
I tried a variety of techniques but could not find a general
macro-type solution without modifying xenctrl.h. So the
solution was to declare a local HYPERCALL_BUFFER_NULL, and
this appears to work. I admit I am not familiar with libxenctrl
to state if this is a satisfactory workaround, so feedback
here welcome. I can state that this allows kexec to load/unload/kexec
on Xen and non-Xen environments that I've tested without issue.
With this patch applied, kexec-tools can be built with Xen
support and yet there is no explicit run-time dependency on
libxenctrl.so. Thus it can also be deployed in non-Xen
environments where libxenctrl.so is not installed.
# ldd build/sbin/kexec
linux-vdso.so.1 => (0x00007fff7dbcd000)
liblzma.so.0 => /usr/lib64/liblzma.so.0 (0x00000038d9000000)
libz.so.1 => /lib64/libz.so.1 (0x00000038d6c00000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000038d6400000)
libc.so.6 => /lib64/libc.so.6 (0x00000038d6000000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038d6800000)
/lib64/ld-linux-x86-64.so.2 (0x0000562dc0c14000)
# build/sbin/kexec -v
kexec-tools 2.0.16
This feature/ability is enabled with the following:
./configure --with-xen=dl
The previous --with-xen=no and --with-xen=yes still work as before.
Not specifying a --with-xen still defaults to --with-xen=yes.
As I've introduced a new build and run-time mode, I've done an
extensive matrix of both build-time and run-time checks of kexec
with this patch applied. The set of build-time scenarios are:
1: configure --with-xen=no and Xen support NOT present
2: configure --with-xen=no and Xen support IS present
3: configure --with-xen=yes and Xen support NOT present
4: configure --with-xen=yes and Xen support IS present
5: configure --with-xen=dl and Xen support NOT present
6: configure --with-xen=dl and Xen support IS present
Xen support present requires that configure can find both
xenctrl.h and libxenctrl.so.
Then for each of the six scenarios above, the corresponding kexec
binary was tested on a Xen system (Oracle's OVS dom0) and a
non-Xen system (Oracle Linux).
There are two build-time checks: did kexec build, and did
it contain libxenctrl.so? The presence of libxenctrl.so
in kexec was checked via ldd. The results were:
Scenario | Build | libxenctrl.so | Result
1 | pass | no | pass - see Note 1
2 | pass | no | pass - see Note 1
3 | pass | no | pass - see Note 2
4 | pass | yes | pass - see Note 3
5 | pass | no | pass - see Note 2
6 | pass | no | pass - see Note 4
Note 1: This passes since due to --with-xen=no, there will
be no Xen support in kexec and therefore no libxenctrl.so a
in the kexec.
Note 2: This passes since while --with-xen=yes, the configure
displays a message indicating that Xen support is disabled,
and allows kexec to build (this is the same behavior as prior
to this patch). And since Xen support is disabled, there is
no libxenctrl.so in the kexec.
Note 3: This passes since with --with-xen=yes and configure
locating the xenctrl.h and libxenctrl.so, support for Xen was
built into kexec. Ldd shows an explicit dependency on the library.
Note 4: This passes since with --with-xen=dl and configure
locating the xenctrl.h and libxencrl.so, support for Xen
was built into kexec. However, this uses the new technique
introduced by this patch and, as a result, ldd shows that the
libxenctrl.so is not a explicit run-time dependency for kexec
(rather libdl.so is now an explicit dependency). This is
precisely the goal of this patch!
The net effect is that there are now three "flavors" of a kexec
binary (prior to this patch there were two): a) kexec with no
support for Xen [scenarios 1, 2, 3, 5], b) kexec with support
for Xen and libxenctrl.so as an explicit dependency [scenario 4],
and c) kexec with support for Xen and libxenctrl.so is NOT an
explicit dependency [scenario 6].
The run-time checks are to take each of the six scenarios above
and run the corresponding kexec binary on both a Xen system and
a non-Xen system. The test for each kexec scenario was:
% service kdump stop
% vi /etc/init.d/kdump
change KEXEC= to /sbin/kexec-[123456]
% service kdump start
# If not FAILED, then below
% service kdump status
Kdump is operational
% rm -fr /var/crash/*
% echo c > /proc/sysrq-trigger
# after reboot verify vmcore generated
% ls -al /var/crash/<tab>
The results were:
Scenario | Xen environment | non-Xen environment
1 | fail - see Note 5 | pass
2 | fail - see Note 5 | pass
3 | fail - see Note 6 | pass
4 | pass | fail - see Note 7
5 | fail - see Note 6 | pass
6 | pass | pass
Note 5: Due to --with-xen=no, kexec lacks support for Xen and will
fail in the Xen environment. This behavior is the same as prior
to this patch.
Note 6: Due to the missing xenctrl.h and libxenctrl.so, kexec was
built without support for Xen, and thus will fail in the Xen
environment. This behavior is the same as prior to this patch.
Note 7: This kexec has the explicit dependency on libxenctrl.so
which prevents it from running in a non-Xen environment. This is
expected as this is the original issue for which this patch is
intended to address.
Note that for scenarios 1, 2, 3 and 5 kexec lacks support for Xen,
thus these versions are expected to "fail" in a Xen environment.
On the flip side, since a non-Xen environment does not need
libxenctrl.so, all but scenario 4 are expected to "pass" in a
non-Xen environment. The results match these expectations!
And, of course, importantly with this patch applied, it did not
have an adverse impact on kexec build or run-time.
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.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>
|
|
In kdump kernel, we got:
Saving vmcore-dmesg.txt
Failed to malloc 67108864 bytes for the logbuf: Cannot allocate memory
Apparently 64M is too luxury for a kdump kernel which only has 128M
in total.
We can avoid allocating such a large memory chunk, instead just allocate
a smaller chunk inside the loop each time.
Verify the result by comparing the vmcore-dmesg output with and without
this patch.
Cc: Simon Horman <horms@verge.net.au>
Reviewed-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Read the new extension data which tells the boot agent about the
requirements for booting the kernel image, such as how much RAM
will be consumed by the kernel through decompression and booting.
This is necessary to control the placement of the DTB and
compressed RAM disk to avoid these objects being corrupted.
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk@armlinux.org.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There is no difference in the way the initrd is handled between an
ATAG-based kernel and a DTB-based kernel. Therefore, this should be
handled identically in both cases.
Rearrange the code to achieve this.
Signed-off-by: Russell King <rmk@armlinux.org.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The OCTEON family of MIPS64 CPUs uses a PAGE_OFFSET of
0x8000000000000000ULL, which is differs from other CPUs.
Scan /proc/cpuinfo to see if the current system is "Octeon", if so,
patch the page_offset so that usable kdump core files are produced.
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some kernel versions running on MIPS split the System RAM memory
regions reported in /proc/iomem. This may cause loading of the kexec
kernel to fail if it crosses one of the splits.
Fix by merging adjacent memory ranges that have the same type.
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The kernel message buffers, as well as a lot of other useful data
reside in the bss section. Without this vmcore-dmesg cannot work, and
debugging with a core dump is much more difficult.
Try to add the /proc/iomem "Kernel bss" section to vmcore. If it is
not found, just do what we used to do and use "Kernel data" instead.
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The 64-bit MIPS architecture doesn't have the same 2G limit the 32-bit
version has. Set MAXMEM and lowmem_limit to 0 for 64-bit MIPS so that
memory above 2G is usable in the kdump core files.
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Accelerator devices like GPU and FPGA cards contain onboard memory. This
onboard memory is represented as a memory only NUMA node, integrating it
with core memory subsystem. Since, the link through which these devices
are integrated to core memory goes down after a system crash and they are
meant for user workloads, avoid adding coherent device memory regions to
crash memory ranges. Without this change, makedumpfile tool tries to save
unaccessible coherent device memory regions, crashing the system.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Tested-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since kernel commit a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
to 2048"), powerpc bumped command line size to 2048 but the size
used here is still the default value of 512. Bump it to 2048 to
fix command line overflow errors observed when command line length
is above 512 bytes. Also, get rid of the multiple definitions of
COMMAND_LINE_SIZE macro in ppc architecture.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hang was observed, in purgatory, on a machine configured with
single LPAR. This was because one of the segments was loaded
outside the actual Real Memory Area (RMA) due to wrongly
deduced RMA top value.
Currently, top of real memory area, which is crucial for loading
kexec/kdump kernel, is obtained by iterating through mem nodes
and setting its value based on the base and size values of the
last mem node in the iteration. That can't always be correct as
the order of iteration may not be same and RMA base & size are
always based on the first memory property. Fix this by setting
RMA top value based on the base and size values of the memory
node that has the smallest base value (first memory property)
among all the memory nodes.
Also, correct the misnomers rmo_base and rmo_top to rma_base
and rma_top respectively.
While how RMA top is deduced was broken for sometime, the issue
may not have been seen so far, for couple of possible reasons:
1. Only one mem node was available.
2. First memory property has been the last node in
iteration when multiple mem nodes were present.
Fixes: 02f4088ffded ("kexec fix ppc64 device-tree mem node")
Reported-by: Ankit Kumar <ankit@linux.vnet.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Geoff Levand <geoff@infradead.org>
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.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>
|
|
Keep pace with changes to linux arch/x86/kernel/e820.c to
function e820_type_to_string(). With this change, the following
messages from kexec are eliminated (and allows kexec to load):
Unknown type (Reserved) while parsing /sys/firmware/memmap/8/type.
Please report this as bug. Using RANGE_RESERVED now.
Unknown type (Unknown E820 type) while parsing /sys/firmware/memmap/4/type.
Please report this as bug. Using RANGE_RESERVED now.
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds support to use binary image ie arch/arm64/boot/Image with
kdump.
Signed-off-by: Pratyush Anand <panand@redhat.com>
[takahiro.akashi@linaro.org: a bit reworked]
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: David Woodhouse <dwmw@amazon.co.uk>
Tested-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We pass the following properties to crash dump kernel:
linux,elfcorehdr: elf core header segment,
same as "elfcorehdr=" kernel parameter on other archs
linux,usable-memory-range: usable memory reserved for crash dump kernel
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: David Woodhouse <dwmw@amazon.co.uk>
Tested-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We make sure that all the other segments, initrd and device-tree blob,
also be loaded into the reserved memory of crash dump kernel.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: David Woodhouse <dwmw@amazon.co.uk>
Tested-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
