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