Age | Commit message (Collapse) | Author |
|
We got a problem on one SGI 64TB machine, the current kexec-tools
failed to work due to the insufficient ranges(MAX_MEMORY_RANGES)
allowed which is defined as 1024(less than the ranges on the machine).
The kcore header is insufficient due to the same reason as well.
To solve this, this patch simply doubles "MAX_MEMORY_RANGES" and
"KCORE_ELF_HEADERS_SIZE".
Signed-off-by: Xunlei Pang <xlpang@redhat.com>
Tested-by: Frank Ramsay <frank.ramsay@hpe.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
crashdump-elf.c passes unsigned long long addresses into phys_to_virt()
so make phys_to_virt() accept such addresses without truncating them.
This is important for ARM LPAE systems.
Reviewed-by: Pratyush Anand <panand@redhat.com>
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 8a1aa35a1077b42bc2a2afb05d24b637e1edf2a1.
|
|
Crash kernel region size is available via sysfs on Linux running on
bare metal. However, this does not work when Linux runs as Xen dom0.
In this case Xen crash kernel region size should be established using
__HYPERVISOR_kexec_op hypercall (Linux kernel kexec functionality does
not make a lot of sense in Xen dom0). Sadly hypercalls are not easily
accessible using shell scripts or something like that. Potentially we
can check "xl dmesg" output for crashkernel option but this is not nice.
So, let's add this functionality, for Linux running on bare metal and
as Xen dom0, to kexec-tools. This way kdump scripts may establish crash
kernel region size in one way regardless of platform. All burden of
platform detection lies on kexec-tools.
Figure (and unit) displayed by this new kexec-tools functionality is
the same as one taken from /sys/kernel/kexec_crash_size.
This functionality is available on x86 platform only. If idea is acceptable
then I can prepare patches for other platforms (if it is possible and make
sense) and repost them as fully flagged patch series.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Xen 4.4 has an improvided kexec hypercall ABI that allows images to be
loaded and executed without any kernel involvement. Use the API
provided by libxc to load images when running in a Xen guest.
Support for loading images via the kexec_load syscall in non-upstream
("classic") Xen kernels is no longer supported.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
|
|
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>
|
|
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>
|
|
A customer has seen the kexec command exhaust its buffer for the ELF headers
from /proc/kcore. It found 147 program headers, which requires a buffer of
over 8k.
(This overflow was on an SGI UV with an extremely large memory, hence
many ram ranges.)
The default buffer size of 4k is configured in KCORE_ELF_HEADERS_SIZE.
The easy solution would probably be to increase the buffer to 16k.
That is room for 291 entries, on x86_64.
You might want to make the command dynamically enlarge the buffer when
it is found to be too small, but I don't think this command's use of a
little more memory is of concern. So there is probably no reason to
change the program logic in this area.
Diffed against kexec-tools-2.0.2
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This function is used by ELF crashdump code which prepares crash memory headers
for the dump capture kernel. Most architecture can use default version which
just adds PAGE_OFFSET to the virtual address but some architectures might need
some special handling.
Signed-off-by: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
- using simple mips* ) in configure.ac to make it compilable on mips2
and mips64
- remove kexec/arch/mips/mips-setup-simple.S which prepares cmdline for
new kernel, it is better to move this work to kernel code. BTW this code was
compilable only on o32 because of t4 is not defined on 64-64 or n32 MIPS ABIs.
- simple put cmdline as string, kernel code should catch cmdline like this
int board_kexec_prepare(struct kimage *image)
{
int i;
char *bootloader = "kexec";
board_boot_desc_ptr->argc = 0;
for(i=0;i<image->nr_segments;i++)
{
printk("segment %d
if (!strncmp(bootloader, (char*)image->segment[i].buf,
strlen(bootloader)))
{
/*
* convert command line string to array
* of parameters (as bootloader does).
*/
int argc = 0, offt;
char *str = (char *)image->segment[i].buf;
char *ptr = strchr(str, ' ');
while (ptr && (ARGV_MAX_ARGS > argc)) {
*ptr = '\0';
if (ptr[1] != ' ') {
offt = (int)(ptr - str + 1);
boot_desc_ptr->argv[argc] =
image->segment[i].mem + offt;
argc++;
}
ptr = strchr(ptr + 1, ' ');
}
boot_desc_ptr->argc = argc;
break;
}
}
Keep it as string make code simple and more readable.
- add crashdump support
- do not redefine syscalls numbers if they defined in system
remove fixups for /proc/iomem. If your board provides wrong /proc/iomem please
fix kernel, or at least you local version of kexec. No need to support it in
main line. At least add option --fake-iomem
- some minor fixes
Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch is for kexec-tools-testing-20080324.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The patch is for kexec-tools-testing-20070330.
(http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/)
The kexec command gets the address and size of the vmcoreinfo data from
/sys/kernel/vmcoreinfo, and passes them to the second kernel through
ELF header of /proc/vmcore. When the second kernel is booting, the
kernel gets them from the ELF header and creates vmcoreinfo's PT_NOTE
segment into /proc/vmcore.
Signed-off-by: Dan Aloni <da-x@monatomic.org>
Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
architecture.
This is necessary when running Xen with a 64 bit hypervisor and 32 bit
domain 0 since the CPU crash notes will be 64 bit.
Detecting the hypervisor archiecture requires libxenctrl and therefore this
support is optional and disabled by default.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
Acked-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Keep alignment comment in elf code and use ELF_CORE_HEADER_ALIGN
This patch puts back and extends the alignment comment in crashdump-elf.c
and adds a small check to make sure the arch-specific code aligns properly.
Instead of hardcoding 1024 we introduce ELF_CORE_HEADER_ALIGN.
The idea behind the alignment requirement is explained here:
http://lists.osdl.org/mailman/htdig/fastboot/2006-November/005147.html
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Acked-by: Vivek Goyal <vgoyal@in.ibm.com>
Removed trainling whitespace after "kilobytes,"
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
crash_create_XXX_headers assumes that all arhitectures need an alignment of
1024bytes. But on ia64 at least this is not true. This patch adds an
alignment parameter to crash_create_XXX_headers, and calls passes
a value of 1024 for all architectures except ia64, where EFI_PAGE_SIZE (4096)
is passed.
If there are problems with alignment on other architectures hopefully
this facility will work for them too.
Cc: Bernhard Walle <bwalle@suse.de>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Zou, Nanhai <nanhai.zou@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
kexec/arch/i386/crashdump-x86.c | 4 ++--
kexec/arch/ia64/crashdump-ia64.c | 5 +++--
kexec/arch/ppc64/crashdump-ppc64.c | 4 ++--
kexec/arch/x86_64/crashdump-x86_64.c | 2 +-
kexec/crashdump-elf.c | 11 ++---------
kexec/crashdump.h | 6 ++++--
6 files changed, 14 insertions(+), 18 deletions(-)
|
|
kexec-tools: Introduce crashdump-xen.c and Xen support V2
This patch adds the new file crashdump-xen.c that implements Xen support. The
Xen support is not complete yet in the sense that a special program header
for the hypervisor isn't created. Crash notes for physical cpus are created
so basic support is at least provided by this patch.
Version 2 of this patch includes a cleaner implementation for crashdump-elf.c
together with a bugfix for xen_get_nr_phys_cpus().
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Removed trailing whitespace
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec-tools: Introduce crashdump-elf.c and crash_create_elf32/64_headers() V2
This patch adds the new file crashdump-elf.c that implements a single generic
function which is used to create elf headers. The file gets included twice by
crash.c to create two functions from the same source. These two functions are
named crash_create_elf32_headers() and crash_create_elf64_headers().
The new code differs from prepare_crash_memory_elf32/64_headers() in the sense
that both allocation and setup now are done in the same function.
This patch only adds the new code, following patches make sure the different
architecture-specific files make use of the new code.
This version contains a new comment as suggested by Vivek, together with
that the alignment now is fixed at 1024 regardless of architecture. The cpu
elf note callback code has been slightly reworked to become cleaner. Also,
FUNCTION has been renamed to FUNC.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Removed trainling whitespace
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec-tools: Add length parameter to get_crash_notes_per_cpu()
Let get_crash_notes_per_cpu() pass both physical base address and length.
Under Xen we export this information from the hypervisor, and it would be
a nice improvement for the kernel to actually export the size too. So let's
change the framework to use both base address and length.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Removed trainling whitespace
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o With relocatable kernel in picture, the kernel text map offset
(__START_KERNEL_map) is no longer constant. It depends on where kernel
is loaded.
o Now /proc/kcore is read to determine the virtual address the kernel
is mapped at and /porc/iomem is read for determining the physical
address where kernel is loaded at. This information is enough to
create to fill virtual address and phy addr info for elf header
mapping kernel text and data.
o Virtual address for kernel text are needed by gdb as well as crash to
retrieve the meaningful data from core file.
o This patch requires "elf note memsz" fix in the kernel. Currently
that fix is in -mm tree. It will still work with older kernels. It will
display the warning messages (/proc/kcore could not be parsed) and hardcode
the kernel virtual address and size.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On Wed, Dec 14, 2005 at 02:50:52PM -0600, Milton Miller wrote:
[..]
> >>(2) why do you stat the files instead of just trying to open them and
> >>check for ENOENT?
> >>
> >>milton
> >>
> >
> >I wanted to differentiate between two cases. One being sysfs not
> >mounted
> >and other being file not being present (Due to kernel bug or cpu not
> >present), hence used stat(). In case of sysfs not being mounted, we
> >simply exit after giving an error message. In other case we continue
> >to loop through other cpus and ignore cpu, which is not present.
> >
>
> Ok, but try to open the file first. IF you want to do this diagnostic
> after the open fails, that is ok. But don't do this check n times (n =
> number of cpus) when the file exists.
>
I have moved the sysfs mounted check in failure condition.
>
> >
> >On Tue, Dec 13, 2005 at 09:36:26AM -0800, Haren Myneni wrote:
> >>Vivek, I believe, we should push this func into arch independent code.
> >>Otherwise, we have to copy it for every platform.
> >>
> >
> >We have reworked the patch and moved this code to architecture
> >independent
> >portion.
> >
>
>
> Only the x86 code has the fallback the old name, not the genric code.
>
Only i386 port of kdump was available when crash_notes was exported
through /sys/kernel/crash_notes. Rest of the architectures see new arch-
independent percpu crash_notes sysfs interface only. Hence thought no
point copying backward compatibility code in generic code.
>
> Also, there are error paths that do not set the address, others that
> zero it.
>
The error paths which do not set address to zero are non return path. They
call die() which inturn calls exit(1) after printing appropriate error
messasge.
> What happens if the base kernel is too old for kexec-panic, where
> neiter file will exist?
>
In that case kexec will fail much earlier. There will be no reserved
memory area for loading second kernel (crashkernel=X&Y) hence attempt to
load the second kernel will fail and control will not reach this place at
all.
Modifed patch appended.
Thanks
Vivek
o This patch moves per cpu interface to retrieve crash_notes address to
architecture independent section. (As suggested by Haren)
o For i386, kernels older than 2.6.15-rc1-mm2 used to export crash_notes
through /sys/kernel/crash_notes. This patch also provides backward
compatibility with older kernel versions.
o Definition of MAX_NOTE_BYTES moved to architecture independent header
file as everybody is using same definition.
o Definition of MAX_LINE moved to architecture independent header file.
Seems to be a better option than defining it in many C files.
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|