| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
