| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Make certain we are using the same page_offset, paddr, and vaddr
and kernel size that the x86_64 crashdump code is using.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Don't print uncondintionally print an error message about
KCORE_ELF_HEADERS_SIZE being wrong when the elf headers
are truncated when build_mem_phdrs fails because there
are other reasons we could be truncated (like an
actual damaged elf file).
Instead only print an error message when either probe_debug
is true or we are skipping the total file size checks for
some reason. When we do print an error message limit the
message to the fact that we are truncated and how many
bytes we have and how many bytes we need. The context
of the failure should be able to provide the rest of
the information.
For now add a comment in crashdump-x86_64.c to direct people
to KCORE_ELF_HEADERS_SIZE so that if someone finds the
code things can be adjusted.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
- Pass the acpi memap to the kernel.
- Port the fix from x86_64 to not truncate the elf
note segment to 16K, to keep large machines happy.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Put the debug code under #ifdef DEBUG instead of #if 0.
o Do this to match the x86_64 code.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Build a version of get_crash_memory_ranges that works the same
on both x86_64 and x86. Reorder the calls in load_crashdump_segments
so we have the architectures low memory limit when we call
get_crash_memory_ranges.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Unify the 32bit and the 64bit crashdump headers. Rename
arch specific defintions to arch specific names to be clear.
Update users of the renamed constants.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In preparation for merging crashdump-x86 and crashdump-x86_64
move elf_info onto the stack and start filling it out dynamically
as appropriate.
Included in this change is only setting lowmem_limit and get_note_info
when we are generating a core file for a 32bit kernel.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
These fields as defined in kexec_info are not biarch safe and
beyond that crash_elf_info is the structure for passing this kind
of information not kexec_info. So move them in prepartion for
properly cleaning up biarch x86 functionality.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
[ horms@verge.net.au: converted stray elf_info-> to elf_info. ]
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The function only had one user, the error checking was wrong,
and the functions it performed are best done elsewhere
so remove the tempation of a problemenatic hook.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
Don't calculate page_offfset in arch_init. Performing the work there
badly messes up biarch support, so move the work into crashdump_x86_64.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
I'm not pleased with the hacks that we use kernel_version
for but kernel_version itself is reasonable code and might
be needed elsewhere, so move kernel_version into the kexec
core.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
Move cmdline from just after .bss segment to the just after
the latest segment to avoid segments overlap while loading
crashdump kernel. (new mips vmlinux has additional segments
after .bss).
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
