| Age | Commit message (Collapse) | Author |
|---|
|
virtio-mem in Linux adds/removes individual memory blocks (e.g., 128 MB
each). Linux merges adjacent memory blocks added by virtio-mem devices, but
we can still end up with a very sparse memory layout when unplugging
memory in corner cases.
Let's increase the maximum number of crash memory ranges from ~2k to 32k.
32k should be sufficient for a very long time.
e_phnum field in the header is 16 bits wide, so we can fit a maximum of
~64k entries in there, shared with other entries (i.e., CPU). Therefore,
using up to 32k memory ranges is fine. (if we ever need more than ~64k,
we can switch to the sh_info field)
Move the temporary xen ranges off the stack, dynamically allocating
memory for them.
Note: We don't have to increase MAX_MEMORY_RANGES, because virtio-mem
added memory is driver managed and always detected and added by a
driver in the kexec'ed kernel; for ordinary kexec, we must not expose
these ranges in the firmware-provided memmap.
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Linux kernel commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR
region on 5-level paging") changed the base of the direct mapping
from 0xffff880000000000 to 0xffff888000000000. This was merged
into v4.20-rc2.
Update to new address accordingly.
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>
|
|
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>
|
|
On Thu, Jul 27, 2006 at 12:32:56PM -0600, Eric W. Biederman wrote:
>
> I have found a couple of moments and have been able to
> catch up with most of the backlog of patches for kexec-tools.
> There are several details I need to follow up on, and there is
> some testing I want to do to make certain everything is working.
>
> The primary kexec-tools archive is:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/kexec-tools.git
>
> An archive to hold versions before 1.101 is at:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/kexec-tools-historic.git
>
> So far I have all version in there since 1.0 except 1.9, 1.92, and 1.93
> if someone happens to have a copy point me at it and I will update the
> history.
>
> Patches that hang out in quilt for a while can be annoying to import
> into git because their authorship information is not stored in an
> unambiguous way. git is general is much stricter about the format
> it's meta-data information is stored in.
>
> Maneesh in kdump10 there were two patches in particular that I have
> not sorted out their who wrote them. If you could help me sort that
> out I would appreciate it.
>
> ppc64-initrd-option.patch
> ppc64-kdump-device_tree-sort.patch
>
> Before I make a release here is my list of things I intend to look at:
> - Why we have defined the location of the crash backup region twice.
Hi Eric,
Are you referring to BACKUP_REGION_START and BACKUP_START declarations?
I am not sure why did I do that, may be somehow I thought that purgatory
code is not sharing the header files with main kexec code base.
Please have a look at the patch attached for i386. If this looks
fine, I shall generate the patches for x86_64 and ppc64 too.
Thanks & Regards
Vivek
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
|
|
o For i386, Physical memory upto 896MB is linearly mapped. Hence virtual
addresses for linearly mapped region are known.
o This patch sets the appropriate virtual addresses in core headers for
linearly mapped region.
o Enables gdb to debug linearly mapped region without any special user space
utility. Otherwise, capture tools first need to analyze the core image (Read
page tables and/or vm areas) and determine virtual addresses for memory
chunks and then regenerate the elf headers suitable for debugging with gdb.
o Some cases like 4G/4G split deviate from 896MB linearly mapped region and
might have different value for PAGE_OFFSET. Probably its a good idea to
export the linear region from kernel and use that instead of hard coding it.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o Creates a segment for storing elf headers.
o Creates Elf headers for dump capture.
o Functionality to modify command line internally. (Appending elfcorehdr= and
user defined memory map, memap=exactmap).
o Adds command line option to choose between ELF32 and ELF64 headers for core.
o As of today, gdb does not open ELF64 core file for i386 systems. So for
users who don't have PAE systems, can generate ELF32 headers by specifying
--elf32-core-headers on kexec command line. --elf64-core-headers forces
generation of ELF64 headers. ELF64 headers are generated by default.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o This patch adds support for reserving space for backup region. Also adds code
in purgatory to copy the first 640K to backup region.
o Moved kexec_flags inside kexec_info structure.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
