| Age | Commit message (Collapse) | Author |
|---|
|
For 32-bit ARM systems with CONFIG_ARM_LPAE=y, when kexec utility
loads the crash kernel. 32-bit elf header is not enough if the
physical address exceeds 4G.
This patch checkes whether the largest physical address of the system
exceeds 4G. If so, kexec creates 64-bit elf header.Otherwise it
creates 32-bit elf header.
Signed-off-by: Wei Jitao <weijitao@huawei.com>
Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since "start" and "end" in kexec_iomem_for_each_line
are unsigned long long, this patch makes "callback"s
accept unsigned-long-long-type parameters.
Signed-off-by: Wei Jitao <weijitao@huawei.com>
Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
get_crash_notes_per_cpu() should return -1 if return value of stat(2) is
zero (on success).
Signed-off-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There is a case that the number of /sys/devices/system/cpu/cpuN is not
contiguous, for example after cpu hot removing. This patch fixes so that
all /sys/devices/system/cpu/cpuN is handled when they are discontiguous.
Signed-off-by: Takao Indoh <indou.takao@jp.fujitsu.com>
Reviewed-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If kernel does not export efi runtime maps it means 1:1 mapping does not
work or user explictly boot with efi=old_map. In this case efi setup code
will failback to noefi boot, but for kdump case we still need pass extra
acpi_rsdp cmdline.
Thus adding a check in kdump path.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When KALLSYMS is disabled or /proc is not mounted, this patch allows
--page-offset cmdline option for user to setup correct page_offset.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
ARM kernel can be compiled with CONFIG_VMSPLIT_1G, CONFIG_VMSPLIT_2G or
CONFIG_VMSPLIT_3G. This patch dynamically detects PAGE_OFFSET according
to _stext symbol from /proc/kallsyms.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There's one more '-' in arch_usage, thus
s/pass--memmap-cmdline/pass-memmap-cmdline
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
For kernel boot with efi=old_map or some quirked machines like SGI UV
they use old ioremap instead of 1:1 mapping. But kexec efi support
depends on the 1:1 mapping thus we need to switch to use the old way
There's a kernel patch for exporting the efi flags so we can check the memory
mapping method. But user may want to explictly disable efi boot for unknown
reasons.
So here add a new arch option '--noefi' for this case.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
vmcore-dmesg has been failing for me for quite some time as struct log
was renamed to struct printk_log.
62e32ac printk: rename struct log to struct printk_log
This patch has been sitting in mailing list for quite some time. It
is time to repost the patch.
I took original patch of Lubomir and modified a bit to take care of
concern of hardcoded string length.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In kdump path, now we store all the 2nd kernel memory ranges in
memmap_p. We could use just cmdline_add_memmap() to add all types of
memory ranges to 2nd kernel cmdline.
So clean up here, merge cmdline_add_memmap_acpi() into
cmdline_add_memmap().
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
OPAL based system exports reserved memory ranges through /proc/device-tree
for the regions that are reserved by OPAL firmware. Traverse
/proc/device-tree/reserved-ranges and add them to exclude_ranges[] and
reserve them.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On PowerNV platform, OPAL region is overlapped with crashkernel, need to
create ELF Program header for the overlapped memory. The changes are
similar to the way RTAS region was handled.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch memset modified_cmdline after it alloced.
Without this patch, the header of command line always contains random
value like following example:
kernel: 0x765fd008 kernel_size: 0x23b610
memory range: [0x60000000 - 0x6fffffff] (256M)
memory range: [0x78000000 - 0x9fffffff] (640M)
...
kernel command line: "°¥氥䐶# elfcorehdr=0x77f00000 mem=130048K"
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Geng Hui <hui.geng@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
I accidentally add one duplicate line. Now remove it.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixs a problem introduced by commit e5d6a55 which make ARM
kexec fails.
Due to that commit, kernel is loaded at a dynamically offset: it computes
extra_size using size of dtb, and load zImage at base + extra_size. When
dtb size small (for example, 0x3000 bytes), kernel will be loaded at
address like 0x60003000. For ARM zImage such address is incorrect.
In kernel code arch/arm/boot/compressed/head.S, zImage builds a
temporary page table at (pc & 0xf8000000) + TEXT_OFFSET - 0x4000. The
related instructions sequence is:
mov r4, pc
and r4, r4, #0xf8000000
add r4, r4, #TEXT_OFFSET @ (TEXT_OFFSET == 0x8000 on most platforms)
call cache_on
...
call __armv7_mmu_cache_on
...
call __setup_mmu
sub r3, r4, #16384 @ Page directory size
r3 becomes page table pointer.
When kernel is loaded at 0x60003000, page table is still built at
0x60004000, which destroys kernel.
This patch make extra_size a fix value (0x8000) to avoid the failure.
For the problem commit e5d6a55 tries solve, this patch uses
locate_holes() to find a place can hold initrd and dtb.
Change from v1:
- Coding style enhancements.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Tested-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In commit 91f5b9c ("kdump: pass e820 reserved region to 2nd kernel via
e820 table or setup_data"), I made a wrong condition check.
We should only add cmdline for a memory range if --pass-memmap-cmdline
and the range type isn't RANGE_RESERVED.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The code in arch/arm/kexec-zImage-arm.c currently enforces a hard limit
on the maximum size a dtb blob can occupy. This limit is set to 32k,
which is quite low for device tree blobs nowadays.
Get rid of this assumption, and calculate the added size dynamically.
For this, we need to slurp in the dtb file earlier in order to
determine its size, because the memory hole allocation for 'base'
takes this size into account.
For ATAGs, we keep the current value of 32k, which should in fact be
enough.
With this change in place, the 'DTB too large!' error message can go
away. Successfully tested on a AM335x board.
Signed-off-by: Daniel Mack <zonque@gmail.com>
[s.neumann@raumfeld.com: Fix ATAGs case]
Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
e820 reserved region could be useful in 2nd kernel.
For example, PCI mmconf (extended mode) requires reserved region
otherwise it falls back to legacy mode. The following log is from Cliff
Wickman <cpw@sgi.com>:
PCI: MMCONFIG for domain 1003 [bus 3f-3f] at [mem 0xff0ff00000-0xff0fffffff] (base 0xff0c000000)
[Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources
PCI: not using MMCONFIG
PCI devices on segment 1 (>0) can't fall back to legacy mode, thus
kernel probing fails and device can't be found.
We don't pass reserved region because these regions could be too much
and eat up our very limited kernel command line resource in
memmap=exactmap case.
However now we use e820 map and setup_data to pass memory map to 2nd
kernel and the number of reserved regions should not be a problem any
more.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The purgatory code reads the device tree's version and stores if needed the
currently running CPU number. These 2 values are stored in Big Endian
format in the device tree and should be byte swapped when running in Little
Endian mode.
Without this fix, when running in SMP environment, kexec or kdump kernel may
fail booting with the following message :
Failed to identify boot CPU
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Generated files should always be built from source and never be present in
VCS repositories and only autotools generated files should be in tarballs.
This ensures that they get built as often as possible and bugs with that
process are discovered early.
Signed-off-by: Paul Wise <pabs3@bonedaddy.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
command line size is restricted by kernel, sometimes memmap=exactmap has
too many memory ranges to pass to cmdline. And also memmap=exactmap and
kASLR doesn't work together.
A better approach, to pass the memory ranges for crash kernel to boot
into, is filling the memory ranges into E820.
boot_params only got 128 slots for E820 map to fit in, when the number of
memory map exceeds 128, use setup_data to pass the rest as extended E820
memory map.
kexec boot could also benefit from setup_data in case E820 memory map
exceeds 128.
Now this new approach becomes default instead of memmap=exactmap.
saved_max_pfn users can specify --pass-memmap-cmdline to use the
exactmap approach.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Reviewed-by: Linn Crosetto <linn@hp.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
--pass-memmap-cmdline is used for pass memmap=exactmap cmdline for 2nd
kernel. Later we will use this option to disable passing E820 memmap
method but use the old exactmap method.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Later kexec and kdump memory range will be mapped to E820entry. But
currently kexec memory range .end field is exclusive while crash memory
range is inclusive.
Given the fact that the exported proc iomem and sysfs memmap are both
inclusive, change kexec memory range .end to be inclusive. Later the
unified memory range of both kexec and kdump can use the same E820
filling code.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add two new members to kexec_info structure:
struct memory_range *crash_range
int nr_crash_ranges;
crash_range contains the memory ranges used to boot 2nd kernel.
nr_crash_ranges contains the count of the crash memory ranges.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
CRASH_MAX_MEMMAP_NR is used as the upper boundary of memmap_p.
Originally memmap_p was used to store RANGE_RAM only. But now we changed
it to store all the types of memory ranges for 2nd kernel, which
includes RANGE_RAM, RANGE_ACPI, RANGE_ACPI_NVS (and RANGE_RESERVED in
the future).
Currently CRASH_MAX_MEMMAP_NR is defined (KEXEC_MAX_SEGMENTS + 2), which
is not enough for memmap_p. It must be increased to a much higher value.
I think 1024 is good enough for storing all memory ranges for 2nd
kernel. So this patch increases CRASH_MAX_MEMMAP_NR to 1024.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In load_crashdump_segments(), memmap_p[] is used to contain RANGE_RAM
memory range for booting 2nd kernel. Now adding types of RANGE_ACPI and
RANGE_ACPI_NVS to memmap_p, so later we can pass all the types of memory
range to 2nd kernel. These all types of memory ranges are all stored in
memmap_p for later reference.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
add_memmap() will also add memory range with type RANGE_ACPI and
RANGE_ACPI_NVS (RANGE_RESERVED in the future) besides RANGE_RAM to
memmap_p.
Among these types of memory range, only RANGE_RAM needs to
be aligned with certain alignment. RANGE_ACPI, RANGE_ACPI_NVS and
RANGE_RESERVED doesn't have to be aligned.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This change will be used later:
add_memmap(.., int *nr_memmap, .., int type);
delete_memmap(.., int *nr_memmap, ..);
memmap_p[] is statically allocated for a certain amount. It will be used
later when mapping these memory maps to e820 map.
It's convenient to keep track of the count of memmap_p (nr_memmap) in
add_memmap and delete_memmap, because the counting has already been
taken care of in these two functions.
The original add_memmap() can only add memory range of RANGE_RAM type.
For adding other types of memory range, add another argument for
indicating the type.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The initrd values exposed in the device tree of the kexeced kernel must be
encoded in Big Endian format.
Without this patch, kexeced LE kernel are expected to panic when dealing
with the initrd image.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
add_setup_data() is used to add an instance to the single linked list
of setup_data structure.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Move filling crash_memory_range table entries into a separate routine,
which saves quite a few lines of code.
In this routine, if range spawns over lowmem-highmem border, split range
into two. This is needed to get proper virtual address for lowmem part.
Similar thing is already done for x86. Credits to Yadviga Grigorieva
<yadviga@dev.rtsoft.ru> for tracking down this issue for ppc.
Also this patch makes excluding crash kernel regoin a bit shorter, and
removes unused variable to get rid of compiler warning.
Signed-off-by: Nikita Yushchenko <nyushchenko@dev.rtsoft.ru>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Some Linux distributions, like Suse, are turning on the GCC's stack
protection mechanism by default (-fstack-protector). When building the
purgatory with this option, this leads to link issues that are revealed at
runtime when the purgatory is loaded because symbols like __stack_chk_fail
are unresolved.
This patch forces this stack protection mechanism to be turned off when
building the purgatory on ppc64 BE and LE.
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch append the position of initrd to dtb when loading arm kernel
and initrd without using atag.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch introduces setup_dtb_prop(), which is used for dtb operations. The
code is extracted from zImage_arm_load, and this patch makes memory grown
computation more accurate.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch introduce fdt_node_len and fdt_prop_len to help for computing
memory requirement when operating dtb.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When kASLR is enabled (CONFIG_RANDOMIZED_BASE=y), kernel text mapping
base is randomized. The max base offset of such randomization is
configured at compile time through CONFIG_RANDOMIZE_MAX_BASE_OFFSET (by
default 1G).
Currently kexec-tools is using hard code macro X86_64__START_KERNEL_map
(0xffffffff80000000) and X86_64_KERNEL_TEXT_SIZE (512M) to determine
kernel text mapping from kcore's PT_LOAD. With kASLR, the mapping is
changed as the following:
ffffffff80000000 - (ffffffff80000000+CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
As Vivek suggested, we can get _stext kernel symbol address from
/proc/kallsyms, and search for kcore's PT_LOAD which contains _stext,
and we can say that this area represents the kernel mapping area.
Let's first use this way to find out kernel text mapping. If failed for
whatever reason, fall back to use the old way.
Suggested-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On non-EFI systems, efi_info section of boot_params is zero filled resulting
in an erroneous message from kexec regarding "efi memory descriptor" version.
Caused by commit: e1ffc9e9a0769e1f54185003102e9bec428b84e8 "Passing efi related
data via setup_data"
0000700 0000 0000 0000 0000 0000 0000 0000 0000
0000720 0000 0000 0000 0000 0000 0000 0000 0000
0000740
efi memory descriptor version 0 is not supported!
Signed-off-by: Tony Jones <tonyj@suse.de>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In case using crashkernel=xM,high crashkernel memory will be allocated from top to down
Thus the usable memory for kdump kernel could be bigger than 4G. The efi memmap value
is two 32 bit values efi_memmap and efi_memmap_hi, previously I only passed the efi_memmap
so for the high memory address there will be below kernel panic:
[ 0.000000] efi: EFI v2.31 by American Megatrends
[ 0.000000] efi: ACPI 2.0=0xdb752000 SMBIOS=0xdbab4b98 ACPI=0xdb752000 MPS=0xf4bd0
[ 0.000000] efi: mem00: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] efi: mem01: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] efi: mem02: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] efi: mem03: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] efi: mem04: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935)
[ 0.000000] SMBIOS 2.7 present.
[snip]
[ 0.082451] BUG: unable to handle kernel paging request at ffffa3d0f0000000
[ 0.089467] IP: [<ffffffff810513d1>] native_set_pte+0x1/0x10
[ 0.095157] PGD 0
[ 0.097197] Oops: 0002 [#1] SMP
[ 0.100466] Modules linked in:
[ 0.103554] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc7 #157
[ 0.110001] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013
[ 0.118697] task: ffffffff818e1460 ti: ffffffff818ce000 task.ti: ffffffff818ce000
[ 0.126181] RIP: 0010:[<ffffffff810513d1>] [<ffffffff810513d1>] native_set_pte+0x1/0x10
[ 0.134296] RSP: 0000:ffffffff818cfc80 EFLAGS: 00010287
[ 0.139609] RAX: 0000000000000000 RBX: ffffa3d0f0000000 RCX: 00003ffffffff000
[ 0.146744] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffffa3d0f0000000
[ 0.153879] RBP: ffffffff818cfcb8 R08: ffffea0010745d20 R09: 0000000000000000
[ 0.161013] R10: ffff88041f731fc0 R11: 000000000000001e R12: 0000000000200000
[ 0.168148] R13: 0000000000000000 R14: 0000000000400000 R15: ffff880000000008
[ 0.175288] FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
[ 0.183377] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.189125] CR2: ffffa3d0f0000000 CR3: 000000041e8da000 CR4: 00000000000406b0
[ 0.196264] Stack:
[ 0.198283] ffffffff818cfcb8 ffffffff810561d7 ffff880000000008 0000000000400000
[ 0.205746] ffff880000001000 00000000000001ff ffff88041e8de000 ffffffff818cfd00
[ 0.213210] ffffffff8105644e 0000000000200000 0000000040000000 00000000ffffffff
[ 0.220676] Call Trace:
[ 0.223130] [<ffffffff810561d7>] ? unmap_pte_range+0x77/0x110
[ 0.228966] [<ffffffff8105644e>] unmap_pmd_range+0xde/0x210
[ 0.234630] [<ffffffff81056c6b>] __cpa_process_fault+0x48b/0x5e0
[ 0.240730] [<ffffffff81057276>] __change_page_attr_set_clr+0x4b6/0xb10
[ 0.247437] [<ffffffff810557c7>] ? __ioremap_caller+0x277/0x360
[ 0.253454] [<ffffffff810589f1>] kernel_map_pages_in_pgd+0x71/0xa0
[ 0.259736] [<ffffffff81a53361>] __map_region+0x45/0x63
[ 0.265051] [<ffffffff81a535cc>] efi_map_region_fixed+0xd/0xf
[ 0.270886] [<ffffffff81a52f19>] efi_enter_virtual_mode+0x5a/0x3d9
[ 0.277162] [<ffffffff81a77516>] ? acpi_enable_subsystem+0x37/0x90
[ 0.283440] [<ffffffff81a36eb9>] start_kernel+0x386/0x41c
[ 0.288931] [<ffffffff81a3693c>] ? repair_env_string+0x5c/0x5c
[ 0.294852] [<ffffffff81a36120>] ? early_idt_handlers+0x120/0x120
[ 0.301035] [<ffffffff81a365ee>] x86_64_start_reservations+0x2a/0x2c
[ 0.307479] [<ffffffff81a3672e>] x86_64_start_kernel+0x13e/0x14d
[ 0.313572] Code: 66 2e 0f 1f 84 00 00 00 00 00 48 8b 46 18 55 48 89 e5 48 89 47 04 5d c3 66 90 55 48 89 e5 0f 01 f8 5d c3 0f 1f 8
[ 0.333545] RIP [<ffffffff810513d1>] native_set_pte+0x1/0x10
[ 0.339312] RSP <ffffffff818cfc80>
[ 0.342807] CR2: ffffa3d0f0000000
[ 0.346141] ---[ end trace 86088f739725b8c6 ]---
[ 0.350760] Kernel panic - not syncing: Fatal exception
Fix this by passing both efi_memmap and efi_memmap_hi to 2nd kernel.
Reported-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Before this patch, when no --image-size passed, initrd_base is caculated using
base + len * 4, which is unaligned, and unable to pass check in
add_segment_phys_virt():
if (base & (pagesize -1)) {
die("Base address: 0x%lx is not page aligned\n", base);
}
This patch also uses getpagesize() instead of hard encoded 4096.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
dbgprint_mem_range is used for printing the given memory range under
debugging mode.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Description
in dump_dmesg_structured() the out_buf size is 4096, and if the
length is less than 4080( 4096-16 ) it won't really write out.
Normally, after writing one or four chars to the out_buf, it will
check the length of out_buf. But in extreme cases, 19 chars was
written to the out_buf before checking the length. This may cause
the stack corruption. If the length was 4079 (won't realy write out),
and then write 19 chars to it. the out_buf will overflow.
Solution
Change 16 to 64 thus can make sure that always have 64bytes before
moving to next records. why using 64 is that a long long int can take
20 bytes. so the length of timestamp can be 44 ('[','.',']',' ') in
extreme case.
Signed-off-by: Arthur Zou <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix an off-by-one in locate_hole() that can cause it to return a range
that was previously allocated.
In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping
memory segments at 0xbeff000"
Adding some debugging I found locate_hole was returning incorrect
values. The below is from the debug I added:
XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff
XXXMDF: look for hole memsz=100000, found beff000
Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be
0xbf00000, not 0xbef000. Continuing to the second invocation:
XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff
XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff
XXXMDF: look for hole memsz=1000, found bffe000
Now we die with overlapping ranges, since the 0x100000 bytes at
0xbeff000 overlaps 0x1000 bytes at 0xbffe000.
Signed-off-by: Matthew Fleming <mdf356@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently kexec will use the kernel image type when probe function return
value >=0. It looks odd, but previously it works. Since commit bf06cf2095
it does not work anymore.
During my testing for arm zImage, in 2nd kernel the atags pointer and the
machine_id are not valid, I did a lot of debugging in kernel, finally I found
this is caused by a kexec tools bug instead.
Because uImage will be probed before zImage, also the uImage probe return 1
instead of -1 since bf06cf2095, thus kexec will mistakenly think it is uImage.
Fix this issue by regarding it's valid only when probe return 0.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
All other _probe functions return 0 for probing the kernel
image successfully, so there's no reason to return 1 here.
Fix it to return 0 instead.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
At least on our systems, xenctrl.h defines (unguarded) struct e820entry
Move the (guarded) definition in include/x86/x86-linux.h to below.
Signed-off-by: Tony Jones <tonyj@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
