| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
"kexec -p" fails to load kernels with version of the form x.y instead of
x.y.z with an error message similar to "Unsupported utsname.release:
3.10-1-amd64". Code in kernel_version() also checks the wrong variable
name for error return value from strtoul() for "minor" and "patch", and
hence possibly missing a real error.
These changes fix both of these problems.
Signed-off-by: Khalid Aziz <khalid@gonehiking.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Prefix local include paths with $(srcdir)/.
Fixes build errors like these when building for ARM out of the source tree:
cc1: fatal error: kexec/arch/arm/crashdump-arm.h: No such file or directory
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
saved_max_mem is used to calculate the amount of memory that the previous
kernel used. It seems in sh, we just calculate this variable, but we
never use it. So remove it.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
saved_max_mem is used to calculate the amount of memory that the previous
kernel used. And passed to the dump-capture kernel by kernel commandline
parameter "savemaxmem=". But in the dump-capture kernel, we never use
this parameter now, so remove saved_max_mem and don't add "savemaxmem="
to new kernel commandline.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
saved_max_mem is used to calculate the amount of memory that the previous
kernel used. And passed to the dump-capture kernel by kernel commandline
parameter "savemaxmem=". But in the dump-capture kernel, we never use
this parameter now, so remove saved_max_mem and don't add "savemaxmem="
to new kernel commandline.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
saved_max_mem is used to calculate the amount of memory that the previous
kernel used. And passed to the dump-capture kernel by kernel commandline
parameter "savemaxmem=". But in the dump-capture kernel, we never use
this parameter now, so remove saved_max_mem and don't add "savemaxmem="
to new kernel commandline.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
several options are missed in man page, add it now. They are
--reuseinitrd, --load-preserve-context, --load-jump-back-helper
and --entry=<addr>.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
"--entry" option is used to specify jump back entry address, but
lack description in help message and man page. Now add it.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In commit 28d4ab53, the arch-specific --debug are moved to
generic place, but the relevant description was not updated
accordingly in man page. Here change it.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The return will never be reached, so remove it.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There is no elf.h in this directory, so remove the useless
include.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When borrowing codes from ia64 architecture, this comment was
forgotten to be change. So fix it.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When memory for crashkernel isn't reserved, it's confusing that kexec
spits error message for unloading kdump kernel as if we were loading it:
# kexec -p -u
Memory for crashkernel is not reserved
Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
Then try loading kdump kernel
# echo $?
1
It's more appropriate to test if memory is reserved only when
loading kdump kernel. With this patch:
# kexec -p -u
# echo $?
0
It's also the same behavior with the case of trying to unload kernel
from unloaded state.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Error messages are mixed stderr with stdout when we use die() along with
printf(). So use die() to keep error out consistent.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We used 1024 as the percpu crash note size. But for new kernel that
exports the real crash note size, we should parse it instead of
using 1024.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The function add_backup_segments is only called by my_load and
they are in the same file. So unnecessary to export it. Make it
static.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit e35aa29fb40b37bf86d980b2e19af5e01c2d2549.
This patch is based on the commit 49320340f705694e387d794f7f19d407ad9baefa
"kexec: lengthen the kernel command line image"
Since the latter commit has been reverted due to its useless, this
patch should be reverted too.
Besides, This patch also changed a kernel restriction of max segments
from 16 to 70. Though kexec-tools could have more segments, more than 16,
the kexec_load syscall will still fail for the kernel side has a restriction
of 16.
Cc: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Vivek found specical handling crashkernel low in not good.
We should extend kexec-tools to handle multiple Crash kernel instead.
Extend crash_reserved_mem to array instead and use
kexec_iomem_for_each_line directly. After that we can drop
crashkernel low.
-v2: fix left over calling of parse_iomem_single() found by Vivek.
Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Teach uImage_probe_xxx() to return the information about
a corrupted image. This is required to prevent the loading
of a corrupted ramdisk, where we don't have strict checking
for the other formats, unlike the kernel. So, we should abort
the operation than causing a problem with the new kernel.
Without this patch, a corrupted uImage ramdisk is treated as
a plain ramdisk where there is no format check involved.
# kexec -l uImage --initrd romfs-initrd.corrupt
The data CRC does not match. Computed: 867e73f7 expected 8f097cc0
# echo $?
0
# kexec -e
Starting new kernel
Bye!
Reserving 55MB of memory at 70MB for crashkernel (System RAM: 256MB)
Using Xilinx Virtex440 machine description
Linux version 3.6.0-rc3 (root@suzukikp) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (GCC) ) #66 Tue Apr 16 06:36:56 UTC 2013
Found initrd at 0xcf5f8000:0xcfff8040
...
NET: Registered protocol family 17
RAMDISK: Couldn't find valid RAM disk image starting at 0.
List of all partitions:
No filesystem could mount root, tried: ext2 cramfs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
With this patch :
# kexec -l uImage --initrd romfs-initrd.corrupt
uImage: The data CRC does not match. Computed: 867e73f7 expected 8f097cc0
uImage: Corrupted ramdisk file romfs-initrd
With a corrupted kernel image(the behaviour remains the same) :
# kexec -l uImage.corrupt --initrd romfs-initrd
uImage: The data CRC does not match. Computed: 285787b7 expected e37f65ad
Cannot determine the file type of uImage.corrupt
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We needn't get the initial values for every regs in regs32
from symbol entry32_regs for we will manually initialize them
one by one next:
/*
* Initialize the 32bit start information.
*/
regs32.eax = 0; /* unused */
regs32.ebx = 0; /* 0 == boot not AP processor start */
regs32.ecx = 0; /* unused */
regs32.edx = 0; /* unused */
regs32.esi = setup_base; /* kernel parameters */
regs32.edi = 0; /* unused */
regs32.esp = elf_rel_get_addr(&info->rhdr, "stack_end"); /* stack, unused */
regs32.ebp = 0; /* unused */
regs32.eip = kernel32_load_addr; /* kernel entry point */
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
command line instead of empty command line
This patch prevents the problems to happen below:
In setup_linux_bootloader_parameters_high
120 cmdline_ptr = ((char *)real_mode) + cmdline_offset;
121 memcpy(cmdline_ptr, cmdline, cmdline_len);
122 cmdline_ptr[cmdline_len - 1] = '\0';
if cmdline_len == 0, Line 122 will corrupt kernel16 buf just before the commandline.
And in do_bzImage_load, for example,
369 cmdline_end = setup_base + kern16_size_needed + command_line_len - 1;
370 elf_rel_set_symbol(&info->rhdr, "cmdline_end", &cmdline_end,
371 sizeof(unsigned long));
Line 369 will go wrong, too.
Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Enforce size check for kernel command line to make sure it
doesn't overflow COMMAND_LINE_SIZE.
Reported-by: Nathan D. Miller <nathanm2@us.ibm.com>
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
All other architectures use the command line option --dtb to pass
a dtb file name. For consistency add that option to ppc64.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compile kexec-tools in i386, we got the following warnings:
kexec/kexec-elf-rel.c: In function ‘elf_rel_set_symbol’:
kexec/kexec-elf-rel.c:517: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘size_t’
kexec/kexec-elf-rel.c: In function ‘elf_rel_get_symbol’:
kexec/kexec-elf-rel.c:541: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘size_t’
This is because the two functions output a size_t value as %ld
when it should be %zd, resulting in this warning.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
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>
|
|
Functions:
- cmdline_add_memmap()
- cmdline_add_memmap_acpi()
- cmdline_add_memmap_reserved()
is kind of similar, So add a new function cmdline_add_memmap_internal() to
hold the common codes, reducing the duplication.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
fatal() nearly does the same thing as die() does, so this is kind of
duplicate. Remove fatal() and use die() instead.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use die() to simplify code.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 49320340f705694e387d794f7f19d407ad9baefa. The change
of COMMAND_LINE_SIZE cannot solve Cliff's problem since the kernel side
has the restriction, so it is useless. Let's recover the original value
defined by kernel side.
Cc: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
when specified a wrong --entry option, it outputs the error message:
"Bad option value in --load-jump-back-helper=%s\n"
which is obviously wrong, it should be:
"Bad option value in --entry=%s\n"
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In elf_x86_64_load, allocated memory may not be free'd if the code
exits abnormally, by calling die() or return. So the patch fixes
the possible memory leak.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In ppc_load_bare_bits, allocated memory may not be free'd if the code
exits abnormally, by calling die() or return. So the patch fixes
the possible memory leak.
This patch is also a preparation for patch10.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In elf_ppc_load, allocated memory may not be free'd if the code
exits abnormally, by calling die() or return. So the patch fixes
the possible memory leak.
This patch is also a preparation for patch08.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In multiboot_x86_load, allocated memory may not be free'd if the code
exits abnormally, by calling return. So the patch fixes the possible
memory leak.
Besides, remove some extra blank lines.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In elf_x86_load, allocated memory may not be free'd if the code
exits abnormally, by calling die() or return. So the patch fixes
the possible memory leak.
This patch is also a preparation for patch04.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since get_command_line returns dynamically allocated memory, it is
easy for the caller to forget freeing the memory. Here fixes a
memory leak caused by this function.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If the if test is ok, then it will call die() to exit the process,
so freeing line will not be reached, causing memory leak. Fix this.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When make kdump object file, the expression of linking kdump ignores
LDFLAGS. If someone want to build kdump with static links, it won't
product object file with static attributes. So, fix it.
Signed-off-by: Haifeng Li <omycle@gmail.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>
|
|
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>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could more clear.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be more clear.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be more clear.
Besides, remove the duplicate _ALIGN_* definition in file
kexec/arch/ppc/crashdump-powerpc.h.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be more clear.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be more clear.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We have _ALIGN_UP now, so remove ALIGN_UP and use _ALIGN_UP
instead of it.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be more clear.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be simplified.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be more clear.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be more clear.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We have defined the global align macros for use, so remove the
duplicated macros here.
And in file kexec/arch/ppc/include/page.h, we directly expand the
align operation for marco PAGE_ALIGN since we have removed marco
_ALIGN in this file.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since we have imported macro _ALIGN() for global use, replace the call
of function align() with _ALIGN() and remove align().
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch imports Macros for align operation:
- _ALIGN_UP(addr, size): align addr up on a size boundary
- _ALIGN_DOWN(addr, size): align addr down on a size boundary
- _ALIGN(addr, size): align addr up on a size boundary
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If size is zero, it is unnecessary to do the malloc operation.
So checking size first is better than doing malloc first.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This fixes a build failure introduced by
"kexec x86: drop truncation warning for crash kernel".
Reported-by: CAI Qian <caiqian@redhat.com>
Cc: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Handle the RAM Disks in uImage format
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add IH_TYPE_RAMDISK as a recognized image type.
uImage_load shouldn't decompress the RAMDISK type images, since
uboot doesn't do it.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For payloads without any compression, the image->len
is set to the length of the entire uImage which includes
the uImage header. This should be filled in from
ih_size field of the uImage header.
This can cause a buffer overflow, leading the sha256_process
to overrun the initrd buffer. Also, prevents a vulnerability
where the image has been appended with additional data. The
crc check is performed only when compiled with zlib.
TODO: Implement CRC check if ZLIB is not compiled in.
Reported-by: Nathan Miller <nathanm2@us.ibm.com>
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
uImage supports different types of payloads, including kernel,
ramdisks etc. uImage_probe() as of now checks whether the supplied
payload is of type KERNEL ( i.e, IH_TYPE_KERNEL or IH_TYPE_KERNEL_NOLOAD ).
Change this behaviour to return the image type, if it is one of the supported
payloads. This change is in prepartion to support ramdisks in uImage format.
Introduce a uImage_probe_kernel() which can be used by the archs to check if
the supplied payload is one of the KERNEL types.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
[ horms@verge.net.au: Applied manually due to conflict ]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
I got the following warnings when I compiled kexec-tools:
kexec/kexec-elf-rel.c: In function 'elf_rel_load':
kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 6 has type 'unsigned int'
kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 7 has type 'long long unsigned int'
kexec/kexec-elf-rel.c:367: warning: format '%lx' expects type 'long unsigned int', but argument 8 has type 'long long unsigned int'
kexec/arch/i386/crashdump-x86.c: In function 'get_kernel_paddr':
kexec/arch/i386/crashdump-x86.c:99: warning: format '%016Lx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t'
kexec/arch/i386/crashdump-x86.c: In function 'get_kernel_vaddr_and_size':
kexec/arch/i386/crashdump-x86.c:171: warning: format '%lx' expects type 'long unsigned int', but argument 3 has type 'long long unsigned int'
kexec/arch/i386/crashdump-x86.c: In function 'get_crash_notes':
kexec/arch/i386/crashdump-x86.c:781: warning: format '%Lx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t'
kexec/arch/i386/crashdump-x86.c: In function 'load_crashdump_segments':
kexec/arch/i386/crashdump-x86.c:905: warning: 'nr_ranges' may be used uninitialized in this function
The patch fix above warnings.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix it on ppc64 also. This patch now reads the memory limit information
from device-tree file and limits the crash memory ranges accordingly.
Tested this patch on ppc64 with upstream kernel version 3.8.0-rc4
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
So far powerpc kernel never exported memory limit information which is
reflected by mem= kernel cmdline option. Hence, kexec-tools always used
to build ELF header for entire system RAM generating a dump bigger than
the actual memory used by the first kernel.
This patch now reads the memory limit information from device-tree file and
limits the crash memory ranges accordingly.
Suzuki tested this patch on ppc32(ppc440) with a kernel patch by Suzuki.
The following are the upstream kernel commits that exports memory limit
information through /proc/device-tree file:
4bc77a5ed - powerpc: Export memory limit via device tree
a84fcd468 - powerpc: Change memory_limit from phys_addr_t to unsigned
long long
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Tested-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The crash kernel is not able to find its root device if that device is not
on PCI 0.
This is because it is booted with the command line option memmap=exactmap
which currently clears the e820 table and does not restore reserved spaces.
This works for a device on PCI 0 because ACPI falls back to a legacy mode.
But the error message " [Firmware Bug]: PCI: MMCONFIG at
[mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources"
is written to the log even in this functioning case.
It fails for some devices on UV2, and only for UV2, because SGI seems to
be the only manufacturer currently using the extended PCI(>0).
The fix is simple, as long as the command line is long enough to include
all the reserved spaces.
The command line may have to be lengthened. See
[PATCH] kexec: lengthen the kernel command line image
Signed-off-by: Cliff Wickman <cpw@sgi.com>
[ horms@verge.net.au: Manually applied due to conflicts ]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The crash kernel's boot command line is not long enough to contain the
necessary memmap= options for a large memory.
The fix is simple, as long as the boot loader's command line is also long enough.
I'm not sure about boot loader or kernel restrictions to this length.
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On kexec set-up of a crash kernel on a very large memory machine we
sometimes see the worrisome warning:
Too many memory ranges, truncating...
meaning that the total count of e820 ram, reserved and ACPI spaces is over 128.
Per the comment in do_bzImage_load():
/* If using bzImage for capture kernel, then we will not be
* executing real mode code. setup segment can be loaded
* anywhere as we will be just reading command line.
*/
So if I understand, the e820 table built here and added to the 'real_mode'
area is not going to be used.
So the warning message can be omitted.
Signed-off-by: Cliff Wickman <cpw@sgi.com>
[ horms@verge.net.au manually applied due to conflict ]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For the allocation, using CRASH_MAX_MEMMAP_NR instead of KEXEC_MAX_SEGMENTS + 1
seems more understandable.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
[horms@verge.net.au: Applied by hand due to conflict]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
uImage probe fills the entry point (ep) based on the load_addr
from the uImage headers. If we change the load_addr, we should
accordingly update the entry point.
For ELF, calculate the offset of e_entry from the virtual start
address and add it to the physical start address to find the
physical address of kernel entry.
i.e,
pa (e_entry) = pa(phdr[0].p_vaddr) + (e_entry - phdr[0].p_vaddr)
= kernel_addr + (e_entry - phdr[0].p_vaddr)
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Matthew McClintock <msm@freescale.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kernel could have that in /proc/iomem, will use it for kdump kernel
for dma32
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
need to check xloadflags to see the bzImage is for 64bit relocatable.
-v2: add kexec-bzImage64.c according to Eric.
-v3: don't need to purgatory under 2g after Eric's change to purgatory code.
-v4: use locate_hole find position first then add_buffer... suggested by Eric
add buffer for kernel image at last to make kexec-load faster.
use xloadflags in setup_header to tell if is bzImage64.
remove not cross GB boundary searching.
add --entry-32bit and --real-mode for skipping bzImage64.
-v5: add buffer with runtime size instead, so kernel could use BRK
early and safely.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We could put ramdisk/cmdline above for bzImage on 64bit for protocol 2.12.
-v2: change ext_... handling to way that eric like.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We need to keep space for bss, heap/stack before command line.
otherwise command_line will be cleared by kernel 16bit init code.
also need to set 32bit start in real_mode header, kernel 16bit code
need to jump there.
Also don't touch regs16 if --real-mode is not specified.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec bzImage path setup data is shared with real-mode path, and
setup_header is copied together with setup_code.
Later 32bit just use whole area as boot_params for real_mode_data.
but those area for boot_params around setup_header is
not cleaned that will leave some field in boot_param as
non-zero value.
So clean whole buffer at first, and only copy setup_header for non
real-mode entry path.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
will use ext_ramdisk_image/size, and xloadflags to put
ramdisk and bzImage high for 64bit.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
set LOADER_TYPE_KEXEC
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This check makes sure that we indeed get the memory information.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
At first, we have already filled the kexec_info.memory_ranges by
calling my_load() -> get_memory_ranges(). So if we want to
get the memory information, we could just use the existing
one instead of calling get_memory_ranges again.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Update struct x86_linux_header with new fields, based on
arch/x86/include/asm/bootparam.h as included in linux-3.7.
Upcoming changes will use the payload_offset/payload_length fields.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If we load the relocatable bzImage, the boot protocol must >= 2.05,
So the if condition check is unnecessary.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Restrict the scope of compiler flags set in per-arch Makefiles
to the architecture the Makefile belongs to.
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>
|
|
When resizing a dtb to add the command-line, only resize the DTB once,
rather than once to add the /chosen node, and once to add the bootargs
property.
Also, simply add 1K of overhead (beyond strlen(cmdline)) to the buffer,
to avoid requiring precise knowledge of the size impact of the requested
FTB changes. In particular, some padding is performed when setting
property values, which was not accounted for in the current code, which
caused failures to set the bootargs values in some cases.
Cc: Daniel Mack <zonque@gmail.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Anders Hedlund <anders.j.hedlund@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If --dtb is called together with --command-line, we need to modify the
binary dtb buffer. Luckily, we have libfdt functions available, so this
is straight forward.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Tested-by: Sven Neumann <s.neumann@raumfeld.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Port xen-unstable changeset 24344:72f4e4cb7440 to kexec-tools:
Pushing stuff onto the stack on x86-64 when we do not specify
-mno-red-zone is unsafe. Since the complicated asm is due to register
pressure on i386, we simply implement an all-new simpler alternative
for x86-64.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
execstack shows ppc kexec has an executable stack,
this leaves it vulnerable to buffer overflows.
Fix it by adding ASFLAGS --noexecstack
Tested on PowerMac G4 Macmini:
Without the patch:
dave@darkstar:~/kexec-tools$ execstack build/sbin/kexec
X build/sbin/kexec
With the patch:
dave@darkstar:~/kexec-tools$ execstack build/sbin/kexec
- build/sbin/kexec
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For some reason my version of the Makefile generated by configure
included the line STRIP=strp. Rerunning configure from a fresh slate
did not regenerate that line so I don't know how it got there. So add
the code to Makefile.in and configure.ac to autodetect the strip binary.
This is needed so that we can remove from purgatory all of the
relocations to sections that are not needed at runtime, by stripping
out those sections.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
[horms@verge.net.au: Omitted white-space only change to
purgatory/arch/x86_64/Makefile]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When building configured as '--host=mips64-octeon-linux-gnu' using
GCC-4.7.0 there are two compile errors, fix them.
Signed-off-by: David Daney <david.daney@cavium.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This prevents the creation of chosen/linux,initrd-{start,stop} entries
with zero length.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
basename is initialized as
basename = strrchr(pathname,'/') + 1;
and does hence not contain the leading slash character.
Signed-off-by: Daniel Mack <zonque@gmail.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>
|
|
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>
|
|
A 32bit arch can prepare ELF64 headers. For example for PAE case to
preresent file offsets 64bit but data size at the offset still remains
32bit. If we just base our decision based on EI_CLASS, then we will try
to read 64bit data from file and can run into various issues.
We ran into following issue when we tried to run vmcore-dmesg on a 32bit
PAE system vmcore which had 64bit elf headers.
No program header covering vaddr 0xc0a6a688c0b89100found kexec bug?
Basically we try to read value of log_buf variable from address
log_buf_vaddr. We read in 64bit value and then pass that value again
to vaddr_to_offset() in an attempt to get to actual log_buf start
and get error message.
So determine the machine pointer size based on ELF class and arch and read
the bytes from file accordingly.
v2: Fixed the code as per suggestion from Eric.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If the kernel cannot be loaded at the default load_addr, provided
by the image, we should try finding a free area using locate_hole().
This is usually applicable for the CRASH case, where the memory should
be located in the reserved region.
Without this patch, sometime the kernel fails to load for uImage formatted
relocatable kernel images.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Matthew McClintock <msm@freescale.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve
the acpi root table physical address.
Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab
If there's no such file or read fail the function will just do nothing.
Tested efi boot Fedora 17 on thinkpad T420.
Some background info for this issue:
http://lists.infradead.org/pipermail/kexec/2010-March/003889.html
[v1 -> v2]:
Address comments from Khalid and Simon
use fgets instead of read(2) to iterate the file
do not add 'noefi' because kexec does not construct EFI signature
in bootloader signature in boot_params, so kexec'd kernel will
disable EFI automatically even without noefi.
Signed-off-by: Dave Young <dyoung@redhat.com>
Reviewed-by: Khalid Aziz <khalid@gonehiking.org>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Definitions of BINARIES_ARCH in Makefile.in seems to have been broken since commit 0775c60eb.
Signed-off-by: Tony Jones <tonyj@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some definitions in include/x86/x86-linux.h conflicts
with definitions placed in Xen headers. Make them
conditional. This patch is required by future
Xen kdump fixes.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
get_crash_memory_ranges() is unreliable under Xen. Proper machine
memory map could be obtained under Xen by calling __HYPERVISOR_memory_op
hypercall with XENMEM_machine_memory_map argument. get_crash_memory_ranges_xen()
does that. It is implemented using ioctl() or libxenctrl interface.
This solution is compatible with 3.x and 4.x Xen versions.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Move crash memory ranges logging from get_crash_memory_ranges()
to load_crashdump_segments(). This solution will be used by
fixed Xen kdump support, too.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Get backup area start address and size directly from mem_range.
Under Xen /proc/iomem contains invalid values.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Extract code segregating lowmem region and move it to new
segregate_lowmem_region(). This function will be used by
fixed Xen kdump support, too.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
is_crashkernel_mem_reserved()
Move crash kernel area placement and size detection
from get_crash_memory_ranges() to is_crashkernel_mem_reserved().
Former one will not be used by fixed Xen kdump support.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Rename e820_to_kexec_type() to xen_e820_to_kexec_type() and export it.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
To allow newer ARM platforms to use kexec, pass device tree
information to the kernel during boot.
By default the dtb is found from /proc/device-tree. A user can specify
a dtb file or use legacy ATAGs
Signed-off-by: Matthew Leach <matthew.leach@arm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Make use of struct memory_ranges and provide a global usablemem_rgns.
This is in preparation for adding device tree support.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This is in preparation for using the code on ARM as well as PPC.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The motivation for this is to remove duplicated code by sharing the fs2dt
between different architectures.
The code added by this patch is very close to the code currently used by
ppc64, and thus migrating that architecture should not be difficult. The
32bit powerpc code is a little different and thus more care is needed when
migrating that architecture to this code.
Unfortunately I do not have any powerpc equipment available to test this
code.
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>
|
|
Now kernel has made kernel logging structured and exsisting vmcore-dmesg
does not work with this new format. Hence kernel version 3.5 is broken. In
3.6 now a kernel patch has been put which exports relevant fields. This
patch parses those fields and makes vmcore-dmesg work with new logging
format.
Currently it does not display log levels or dictionary. I personally think
that log levels are not very useful and it also requires additional kernel
patches so that log levels are not bitfields and relevant information is
exported to user space properly.
Concept of dictionary is new and relevant information is exported. One can
possibly enahnce vmcore-dmesg to also print dictionary contents based on
a user command line option.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
scan_vmcoreinfo() currently assumes that every vmcoreinfo note line ends
with \n and overwrites new line with \0. But last entry in note, CRASHTIME=
does not end with \n and this leads to corrupting memory as we write beyond
end of buffer.
Normally things were fine but when I added some fields to vmcoreinfo, this
bug started showing and vmcore-dmesg started crashing.
I am planning to send a patch to fix this in kernel but it might be good
idea to handle this case in user space too so that vmcore-dmesg works
fine with cores of older kernels.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
While trying to port kexec cleanly to klibc,
came across this syscall usage for reboot(2).
Calling reboot directly simplifies the code.
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
As of now, the kexec reserves the spin-table for all the CPUs
on an SMP machine. The spin-table is pointed to by the
cpu-release-addr property in the device-tree. Reserving the
spin-table in the crash kernel will cause a BUG(), if the table
lies outside the memory reserved for the crashkernel.
Disable reserving the spin-table regions and use maxcpus=1 to
use only the crashing CPU to boot the crash kernel.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
vmcoreinfo file could exists under /sys/kernel (valid on baremetal only)
and/or under /sys/hypervisor (valid when Xen dom0 is running).
Read only one of them. It means that only one PT_NOTE will be
always created. Remove extra code for second PT_NOTE creation.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
One of them caused crash when user specifies a file that does not
exist.
Signed-off-by: Aleksey Makarov <aleksey.makarov@gmail.com>
Removed trailing whitespace.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use gcc's __attribute__ to check format string.
Signed-off-by: Aleksey Makarov <aleksey.makarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Do not trigger an error when loading a uImage with the
IH_TYPE_KERNEL_NOLOAD type. These images do not need to be copied to
their load address before being executed.
All archs (excepted PPC) do not use the uImage load and entry point
parameters, so their current behavior needs not be changed further than
just accepting the image type.
Tested and validated on ARM.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Allow bzImages smaller than 32KiB to be kexec'ed.
The current code will fail to load a bzImage smaller than 32768 bytes (sizeof
struct x86_linux_header), but the 'memdisk' program that comes with syslinux is
only about 26 KiB. This patch changes the minimum size to 1024 bytes (2
sectors), which appears to be the limit that syslinux enforces.
Removed the "tail" field of struct x86_linux_header because it doesn't seem to
actually be used (is there a reason for it?).
Also, note that bzImage_probe() was incorrectly using `sizeof (header)', even
though header is a pointer.
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
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>
|
|
From: Cong Wang <xiyou.wangcong@gmail.com>
V2: Fix a compile error
Like commit 28d4ab53280853d2aeefdfb7c369331e89ab9ac2
("Add generic debug option"), this one moves code
under #if DEBUG to --debug on ppc arch.
Sorry that I still can't find a ppc32 machine to test this.
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Another patch that I have been carrying in debian kexec-tools package.
It corrects the section number for shutdown in the man page. This
patch also adds little more descriptive note for the -e option to
clarify that this does not do an orderly shutdown.
Please apply.
Signed-off-by: Khalid Aziz <khalid.aziz@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Instead of calulating the CRC on the whole file just calculate the CRC
on the actual uImage length as given by the uImage header. This fixes
loading padded uImages, for example from a mtd partition.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
|
|
In the past, we did neglected some usable memory range
changing infos. With those deubg code added, we can now
catch them.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec-tools package for debian includes a patch that adds a more
descriptive error message when someone tries to laod a crash kernel
and didn't remember to boot up with crashkernel= parameter. This
patch would be of general interest. This patch was originally written
by Alastair McKinstry.
Please apply.
Signed-off-by: Khalid Aziz <khalid.aziz@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Like patch 1/5, this one moves code under #if DEBUG to --debug
on sh arch.
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Like patch 1/5, this one moves code under #if DEBUG to --debug
on mips arch.
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Like patch 1/5, this one moves code under #if DEBUG to --debug
on arm arch.
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently the debugging code is under #ifdef DEBUG, which
means when we want to debug, we have to re-compile the source
code with -DDEBUG. This is not convenient, we want to have
a generic --debug option so that we can enable debugging code
without re-compiling.
This patch moves the arch-specific --debug to generic place
and moves code under #ifdef DEBUG to --debug on x86.
BTW, the size of kexec binary increases very little after this patch.
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This messages seems unnecessarily verbose.
Reported-by: Maxim Kammerer <mk@dee.su>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
setup_memory_ranges() is being called twice in ppc64. First in my_load()
through get_memory_ranges(), then in elf_ppc64_load(). Looks like we can
remove the latter.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use automatic variables for prerequisites when copying man pages and
include a makefile relative to $(srcdir).
Signed-off-by: Tyler Hall <tylerwhall@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The following functions/variables can become static.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.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>
|
|
The magic varible of function name should be uppercase.
Signed-off-by: Han Pingtian <hanpt@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For s390 we have two modes for kdump:
For the first mode, as on all other architectures, the kexec tool creates
the ELF header and the 2nd kernel processes it for /proc/vmcore setup.
This mode has the disadvantage that for memory and CPU hotplug the kdump
kernel has to be reloaded by the kexec tool. For s390 this is a real problem
because we have a cpuplugd daemon that sets CPUs online and offline
according to the current workload. So CPU online/offline events occur very
often.
For the second mode on s390, the ELF header is created by the kdump kernel.
This is done automatically when the kernel is booted in kdump mode
and no "elfcorehdr" kernel parameter is specified. On s390 the kdump kernel
can get all necessary information to build the ELF header. We can get
the memory map, all CPU registers, and vmcoreinfo
With this patch a compile switch WITH_ELF_HEADER is introduced. When the
macro is defined, kexec will create the ELF header and add the "elfcorehdr"
kernel parameter. If it is not specified (default), no header is created.
For s390 we want to have the 2nd mode as default because it has only
advantages for us.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There is a bug in add_loaded_segments_info, which causes that some LOAD
segments may be skipped on ia64. For two consecutive segments which cannot
be
combined, the 'i' counter is incremented twice, effectively skipping over
the
second segment.
For example, these are the program header of my vmlinux:
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000010000 0xa000000100000000 0x0000000004000000
0x0000000000ee0e90 0x0000000000ee0e90 RWE 10000
LOAD 0x0000000000f00000 0xfffffffffffc0000 0x0000000004f00000
0x0000000000006d80 0x0000000000006d80 RW 10000
LOAD 0x0000000000f10000 0xa000000100f40000 0x0000000004f40000
0x00000000005e3028 0x0000000000dc9198 RW 10000
NOTE 0x000000000098dc60 0xa00000010097dc60 0x000000000497dc60
0x0000000000000024 0x0000000000000024 R 4
IA_64_UNWIND 0x00000000009edd58 0xa0000001009ddd58 0x00000000049ddd58
0x000000000005d468 0x000000000005d468 R 8
And these are the resulting load segments:
0x6004000000 - 0x6004ef0000 (LOAD 1)
0x6004f40000 - 0x6005d10000 (LOAD 3)
0x6023fc0000 - 0x6023fc1000 (elfcorehdr)
Note: The crash kernel is loaded at 0x6004000000 on this machine.
Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
[horms@verge.net.au: Trivial up-port]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
a) rpmbuild doesn't like '-' in version, replace it with '.'.
b) update the files installed in kexec-tools.spec
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
a) We don't need 'crash_notes' array at all, save some bytes on stack.
b) We forgot to fclose 'fp' before return.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add all the TOC16 relocations. These were hit when building kexec
with a recent toolchain.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some cleanup of the relocation code:
- Whitespace changes
- Use braces to add clarity to nested for/if loop.
- Order ADDR16 relocations
- No need for to return from a void function.
Signed-off-by: Anton Blanchard <anton@samba.org>
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>
|
|
hole_align == 0 check is not neccesary, because it will be set to
pagesize if it's zero. Just remove it here.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This file does not include information on offlined memory chunks. With this
patch the memory hotplug information is read from "/sys/devices/system/memory"
and is added to the "/proc/iomem" info.
Also the MAX_MEMORY_RANGES count is increased to 1024 in order to support
systems with many memory holes.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
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>
|
|
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This corrects logic errors so that is_32bit() can actually detect that it
is running on a 32 bit system - something the original version I wrote
failed at woefully.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Previously virt_to_phys() assumed that physical memory always started
at address 0. This is not always the case.
Tested on an sh7757lcr (32bit system) whose only System RAM region is
40000000-4effffff and an ecovec24 (29bit system).
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When the kernel image size is larger than 8 MiB on s390, we currently
can't load the ramdisk, because it is loaded to the fix address 8 MiB
(RAMDISK_ORIGIN_ADDR) per default.
With this patch the ramdisk is loaded behind the image with an 1 MiB
alignment. To be compatible with older kernels we still load
the ramdisk to 8 MiB, if the kernel is smaller than 8 MiB.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hello Simon,
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
All architectures define the "--append" option together with the
"--command-line" option to specify kernel parameters. This option
is also used by kdump init scripts. In order to be compatible this
patch introduces the "--append" option also for s390. In addition
to that the help text is adjusted so that it is now the same as on
all other architectures.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This avoids out of range comparisons (for values >= 128)
and an unnecessary cast.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
commit 1ea7cfd435aba0e095886db367e9616271f56c28 broke the ppc build as it removes
the declaration for two variables in use by the elf_ppc_load(). This patch reverts
the particular hunk.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Reported-by: Josh Boyer <jwboyer@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
get_memory_ranges_sysfs() and get_memory_ranges_proc_iomem()
are unreliable under Xen. Proper machine memory map could be
obtained under Xen by calling __HYPERVISOR_memory_op hypercall
with XENMEM_machine_memory_map argument. get_memory_ranges_xen()
does that. It is implemented using ioctl() or libxenctrl interface.
This solution is compatible with 3.x and 4.x Xen versions.
Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Rename fixup_memory_ranges_sysfs() to fixup_memory_ranges().
It is generic function and it could be used to fixup memory
ranges from other sources than sysfs (e.g. Xen).
Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Export compare_ranges() function from firmware_memmap.c module.
It is generic function and it could be used by other modules.
Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
xc_interface_open() receive three arguments instead of void and returns
pointer to xc_interface type instead of int since Xen Ver. 4.1. Take into
account that and allow kexec-tools compilation with all versions of Xen.
Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
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>
|
|
These 2 "uncommon" include pathes are the first stumbling blocks
to build kexec-tools against klibc.
Of course more is needed, but this is a first step.
On the klibc step there is still stuff needed, but
it is already possible with hacks as Oppenembedded shows.
Signed-off-by: maximilian attems <max@stro.at>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The pv_ops kernel in mainline Linux provides xenfs which has to be
mounted at /proc/xen. It creates /proc/xen/capabilities unconditionally
which makes it impossible to distinguish PVonHVM guests from PV guests.
Use code from xen-detect.c to check wether kexec runs on a PV guest.
Without this change PVonHVM guests will be detected incorrectly as plain
PV guests.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
properties
On a large ppc64 box I got the following error from kexec -l:
unrecoverable error: could not read "/proc/device-tree/ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory": Bad address
dt_reserve was assuming a property was never larger than
INIT_TREE_WORDS (65536), but on this box ibm,dynamic-memory is
119995 words.
Allocate INIT_TREE_WORDS or the number of words requested, whatever
is larger.
Signed-off-by: Anton Blanchard <anton@samba.org>
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>
|
|
The format of memory/reg is based on the #address-cells,#size-cells. Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg values.
Hence the kexec cannot handle cases where #address-cells, #size-cells are
different, (for e.g, PPC440X ).
This patch introduces a read_memory_region_limits(), which parses the
memory/reg contents based on the values of #address-cells and #size-cells.
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
A Xen HVM guest with PV drivers loaded has also a /proc/xen directory.
But such a guest is an ordinary PC and the special handling for dom0
breaks kdump in this environment.
Test for /proc/xen/capabilities instead and cache the result.
Also make two variables static, they are only used in this file.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: WANG Cong <amwang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch changes the behavior of the kexec loader when the
"add_efi_memmap" option is present on the currently running kernel's
command line, to read the kernel memory map from /proc/iomem instead
of /sys/firmware/memmap.
On EFI systems, sometimes the e820 table is missing or incomplete.
Systems like these use the "add_efi_memmap" option to add EFI's memory
table entries to the kernel's memory table to build a complete picture
of the system's memory; however, using the option does not add these
entries to the table used to populate /sys/firmware/memmap, which is
meant to be a pristine original copy.
The kexec loader uses the pristine memory map by default, which causes
problems when the loader doesn't have a complete picture of the system
and incorrectly loads the kernel or ramdisk in places that aren't
actually usable. This change makes the kexec loader check the running
kernel's command line for the "add_efi_memmap" option and if it finds
it, will use the modified map instead of the original map.
signed-off-by: Benjamin Romer <benjamin.romer@unisys.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes buffer overflow and improper realloc() in realloc_memory_ranges().
Signed-off-by: Suzuki K. Poulose <suzuki@in.ibm.com>
(manually applied)
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Vivek pointed out that we have duplicated ->backup_src_start
in struct crash_elf_info and struct kexec_info.
This patch removes the ->backup_src_start and ->backup_src_end
from struct crash_elf_info.
I tested it on both i686 and ppc64, and used a test case from
Dave Anderson to confirm the backup region is correct on i686.
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
I got the following warning when I compiled kexec-tools on ppc64,
In file included from kexec/arch/ppc64/kexec-ppc64.c:32:
kexec/arch/ppc64/../../kexec-syscall.h:118:1: warning: "KEXEC_ARCH_NATIVE" redefined
kexec/arch/ppc64/../../kexec-syscall.h:115:1: warning: this is the location of the previous definition
This is due to that ppc64 defines bot __powerpc64__ and __powerpc__,
this patch fixes that warning.
Signed-off-by: WANG Cong <amwang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Simon Horman <horms@...> writes:
>
> On Tue, Mar 29, 2011 at 09:04:53AM +0000, WANG Cong wrote:
> > On Mon, 28 Mar 2011 14:50:11 -0700, Chris Leech wrote:
> >
> > > kexec needs to keep the subarch setting the same as the running kernel
> > > in the boot parameters, or the kernel will die in early setup. I ran
> > > into this with X86_SUBARCH_MRST, but it should apply to CE4100 and any
> > > future subarch that uses non-default early setup code.
> > >
> > > This patch requires debugfs mounted at /sys/kernel/debug, as that's the
> > > only way I know of to get at the running kernels boot_params. Without
> > > debugfs mounted it falls back to the current behavior of assuming
> > > subarch 0.
> > >
> > ...
> > >
> > > +#define BOOT_PARAMS_DBGFS "/sys/kernel/debug/boot_params/data"
> >
> > A minor issue here is that you are using a hard-coded debugfs path,
> > debugfs can be also mounted to /debug too, so it is better that if we can
> > search the path dynamically here.
>
> Do you think it would be better for the code to loop through
> a few common alternatives for the path?
>
Not fully tested, but instead of looping through possible mount points maybe
look through mtab in search of debugfs by fs type.
Something like this?
kexec, x86: search for debugfs mountpoint in /etc/mtab
From: Chris Leech <christopher.leech@linux.intel.com>
Signed-off-by: Chris Leech <christopher.leech@linux.intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Vivek pointed out that I missed the i386 part in this commit,
commit 1100580b05e3fdfe648d9be8617d962b11f4b88b
Author: Amerigo Wang <amwang@redhat.com>
Date: Thu Mar 3 00:10:43 2011 +0800
get the backup area dynamically
Yes. The customer who reported that bug definitely only
tested it on x86_64. Now make it complete.
Signed-off-by: Amerigo Wang <amwang@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Acked-by: "Eric W. Biederman" <ebiederm@xmission.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>
|
|
kexec/virt_to_phys.c is handled by $(ARCH)_PHYS_TO_VIRT
in order to allow it to be overridden by architectures
that provide their own implementation - currently SH and MIPS.
This resolves a build failure caused by duplicate implementations
of virt_to_phys() on those architectures.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec needs to keep the subarch setting the same as the running kernel
in the boot parameters, or the kernel will die in early setup. I ran
into this with X86_SUBARCH_MRST, but it should apply to CE4100 and any
future subarch that uses non-default early setup code.
This patch requires debugfs mounted at /sys/kernel/debug, as that's
the only way I know of to get at the running kernels boot_params.
Without debugfs mounted it falls back to the current behavior of
assuming subarch 0.
Signed-off-by: Chris Leech <christopher.leech@linux.intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/kexec-tools-devel
|
|
This test appears bogus because the e_phnum element of Elf32_Phdr and
is an unsigned 16bit entity.
This addresses the following warnings:
vmcore-dmesg/vmcore-dmesg.c: In function 'read_elf32':
vmcore-dmesg/vmcore-dmesg.c:116: warning: comparison is always false due to limited range of data type
vmcore-dmesg/vmcore-dmesg.c: In function ‘read_elf64’:
vmcore-dmesg/vmcore-dmesg.c:192: warning: comparison is always false due to limited range of data type
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
A customer machine has run over the limit that we increased in October.
> When boot.kdump runs:
>
> Loading kdump
> 297 segments require a 16696-byte buffer
> KCORE_ELF_HEADERS_SIZE 16384 too small
> ELF core (kcore) parse failed
> Cannot load /boot/vmlinuz-2.6.32.12-0.7.1-uv
> failed
Just barely overflowed. But I suggest doubling the buffer.
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Don't wholeheartedly copy the 32-Kbytes bzImage header area to the stack,
just use a constant pointer instead.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hello,
We've got a bug report of random memory corruption when using kexec.
The test case to reproduce the problem sets up bonding between two
tg3 NICs and transmits some data just before calling kexec to boot
the new kernel. Around one in every one hundred boots would crash
early with different signatures.
We confirmed that the patch below resolves the problem. Please, could
you review and consider it for upstream inclusion?
Thanks,
Leonardo
Before executing the new kernel, kexec disables all network interfaces
to prevent problems like random memory corruption caused by in flight
DMAs.
The current algorithm uses the SIOCGIFCONF to enumerate all interfaces
before shutting them down. However, this ioctl returns only the interfaces
that have an IP address set. This means that in some setups, kexec may
skip interfaces that are up and running. A common example is in bonding,
where the enslaved interfaces are up but may not have an IP address
configured.
This patch replaces SIOCGIFCONF with if_nameindex() to enumerate all
network interfaces available, regardless of having an IP address set
or not.
Signed-off-by: Leonardo Chiquitto <lchiquitto@novell.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
