| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
static data from dump instead of not initialized values from vmlinux.
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If the x86_64 arch returns 0 (KEXEC_ARCH_DEFAULT) then following
condition in load_crashdump_segments function will fill 386 as the
machine for the vmcore elf header..
...
if ((info->kexec_flags & KEXEC_ARCH_MASK) == KEXEC_ARCH_X86_64)
{
elf_info.machine = EM_X86_64;
} else {
elf_info.machine = EM_386;
elf_info.lowmem_limit = X86_MAXMEM;
elf_info.get_note_info = get_crash_notes;
}
...
ending with kexec-ed kernel failing check for the machine,
and disabling vmcore interface.
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
crt.S patch had fixes for gcc -Os (optimaze for size), same as
kernel has. Without this fixes powerpc gcc 4.4 generates forever
loop functions for kexec.
This happends because crtsavres code was spit up to individual files
(http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01294.html) and
kexec purgatory code has following options:
--no-undefined -nostartfiles -nostdlib -nodefaultlibs
So in that case crtasaveregs function are not defined and final object
file has been linked without them. This does not happen with applications
built without -nostdlib, because gcc will add it's standard functions.
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Acked-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
It was possible to not add enough space when we allocate
more space for more memory reserve regions, this was because
we were incorrectly accounting for the size of a reserve
region. This corrects the assumed size for a resize region
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Paper bag time. I forgot to double check my changes worked
on x86_64. So I wound up with x86_64 putting i386 crashdump headers
on when it generated a crashdump header. Ouch!
Fix it by using the new KEXEC_ARCH_NATIVE value so we can see what
we are doing.
Change the one remaining arch test of info->kexec_flags to look
at elf_info.machine instead.
memset elf_info to 0 to ensure all of the fields are initialized
to something predictable.
*Sigh* What a landmine getting the arch out of kexec_flags became.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
Trivial but sometimes it is sometimes multi-arch code wants to know.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
|
|
Load the setup sectors above the kernel in the panic case,
to avoid wasting memory.
Linux kernels frequently have a severe alignment requirment
that can be as much as 16M. The start of the reserved
crash kernel region is 16M aligned. The setup sectors
are tiny 20k? and when we are not running the real mode code
they can live anywhere. Move the setup sectors from
lower address than the kernel to higher address than the kernel
avoids introducing a bad alignment. Allowing the linux kernel
to load lower. Loading the linux kernel lower in memory ensures
memory is used more efficiently.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
vmcore-dmesg is a trivial utility to extract the dmesg from a vmcore.
This was written in reaction to problems I was having building
makedumpfile, and using makedumpfile for extracting dmesg. makedumpfile
does a whole lot of things, uses a whole lot of libraries and which
make it hard to compile and a little bit clunky to remember the command
line switches.
So I have written the trivial vmcore-dmesg program that reads a vmcore
either /proc/vmcore or a saved version vmcore and writes the dmesg to stdout.
There is nothing to vmcore-dmesg and all of the arch dependencies are wrapped
up in generating the core file. Which means a vmcore-dmesg should work with
core files of all architectures without needing a rebuild.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
[ horms@verge.net.au removed trailing white-space ]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Now we use the i386 crashdump-x86 instead we can kill
crashdump-x86_64.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
With proper biarch support in crashdump-x86, crashdump-x86_64
is now redudant and we can use crashdump-x86 everywhere. Using
crashdump-x86 everywhere results in a little unnecessary i386
logic on x86_64 but is otherwise harmless. Removing the
unnecessary duplication between i386 and x86_64 should make
the code much easier to maintain going forward.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In preparation for having a single crashdump implementation
on i386 and x86_64 start sharing arch_options_t between
i386 and x86_64, and don't make arch_options static on
x86_64.
i386 and x86_64 have been using identitcal defitions of
arch_options for a while this change now reflects that
practical reality in the code.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
