| Age | Commit message (Collapse) | Author |
|---|
|
Implement get_crash_kernel_load_range() in support of
print crash kernel region size option.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
By replacing all the explicit align opertion with marco _ALIGN*,
the code logic could be simplified.
Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch combines consecutive PL_LOAD segments into one.
The end address of the last PL_LOAD segment, calculated by
adding p_memsz to p_paddr & rounded up to ELF_PAGE_SIZE,
will be the end address of this loaded_segments[] entry.
This patch fixes the kdump kernel MCA problem caused by under-
allocation of memory and a "kdump broken on ALtix 350" problem
reported by Bernhard Walle.
Simon, this patch replaces my previous patch I submitted on the
underallocation issue.
Signed-off-by: Jay Lan <jlan@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently a memory segment in memory map with attribute of EFI_MEMORY_UC
is denoted as "System RAM" in /proc/iomem, while memory of attribute
(EFI_MEMORY_WB|EFI_MEMORY_UC) is also labeled the same.
The kexec utility then includes uncached memory as part of vmcore.
The kdump kernel may MCA when it tries to save the vmcore to a disk.
A normal "cached" access can cause MCAs.
Since kexec assembled memory ranges with memory tagged as "System RAM",
the uncached memory will be excluded if it is labeled differently.
Simon, since only IA64 will create "Uncached RAM" label, i do not
make changes to other arch.
Our HP machine in the lab is dead. I am sorry that i can not test
against other IA64 systems (than SGI's). Feedback is very much
appreciated.
The corresponding kernel patch is needed to test this kexec patch:
http://marc.info/?l=linux-ia64&m=122122791230130&w=2
This patch without the kernel patch will have no effect and do no
harm.
The kernel patch has been commited as
"[IA64] kexec fails on systems with blocks of uncached memory".
Signed-off-by: Jay Lan <jlan@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
A list of segments is passed into the kernel at kexec_load time
and these are subsequently passed to purgatory which uses
them to mangle the EFI memory table.
Each of these segments represents a PT_LOAD segment in the
elf image to be booted after purgatory. They are already
aligned 64k by this code,
The problem with the code as it stands is that it creates
a separate segment for each PT_LOAD segment. Which in the
end results in separate EFI memory regions for each
PT_LOAD segment. And when linux or xen goes to insert
its kernel/hypervisor regions into /proc/iomem
or /proc/iomem_mashine, they don't fit because those regions
actually span several of the new EFI regions created.
So it makes sense to merge these segments if they are adjacent
after alignment - which they always seem to be. This results
in one EFI region that can contain the relevent kernel/hypervisor
iomem region. Problem solved.
This merging could be done in purgatory. But its easier
and cleaner to do it here (IMHO).
The test for this code is to kexec a machine running kexec it
into linux and then inspect /proc/iomem to see of the kernel
code, text and bss regions are present. Without this fix,
they won't be. With it they should be.
This patch is part of the solution to the same problem for
the hypervisor, though it requires an additional change
to split the code from the heap as the later resides in
convential memory rather than the load segment created
by purgatory's mangling.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Removes the machine parameter to proc_iomem() which is no
longer of any use.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
I tested in a rhel5.1 root with:
2.6.24 kernel
kexec-tools-testing-20080227
crash-4.0-5.1
Crash failed to initialize:
crash: read error: kernel virtual address: a0000001007f0868 type:
"kernel_config_data"
WARNING: cannot read kernel_config_data
crash: read error: kernel virtual address: a000000100f370b0 type: "xtime"
It turned out that the kexec sets info->kern_vaddr_start incorrectly
on ia64 platform.
Jonathan Lim posted a fix to the fastboot list in March 2007:
https://lists.linux-foundation.org/pipermail/fastboot/2007-March/013645.html
This patch derived from Jonathan's patch, but fixes the problem at
kexec/arch/ia64/crashdump-ia64.c.
Signed-off-by: Jay Lan <jlan@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On ia64 XEN it is sometimes neccessary to use an alternate location for the
information that is usually provided by /proc/iomem. By having the path
returned by a function, which can be overriden on a per-architecture basis,
it is possible for ia64 XEN to make use of existing generic code. Hopefully
other achitectures can use this infastructure as the need arises.
If the machine parameter is zero, then iomem file relating to the currently
running kernel should be returned. If the machine parameter is non-zero
then iomem file, relating to the underlying hypervisor, should be returned.
In the simple case, these will be the same file.
Signed-off-by: Simon Horman <horms@verge.net.au>
kexec/arch/i386/crashdump-x86.c | 4 ++--
kexec/arch/i386/kexec-x86.c | 2 +-
kexec/arch/i386/x86-linux-setup.c | 2 +-
kexec/arch/ia64/crashdump-ia64.c | 9 +++++----
kexec/arch/ia64/kexec-elf-ia64.c | 2 +-
kexec/arch/ia64/kexec-ia64.c | 5 +++--
kexec/arch/ppc/kexec-ppc.c | 2 +-
kexec/arch/s390/kexec-s390.c | 5 +++--
kexec/arch/x86_64/crashdump-x86_64.c | 10 +++++-----
kexec/arch/x86_64/kexec-x86_64.c | 2 +-
kexec/crashdump-xen.c | 6 ++++--
kexec/kexec-iomem.c | 31 +++++++++++++++++++++++--------
kexec/kexec.h | 6 +++---
13 files changed, 53 insertions(+), 33 deletions(-)
9079040b40f643cfc9eb3d425dffa0ca8fd573e1
|
|
Remove duplicate MAX_LINE
MAX_LINE is already defined in kexec/kexec.h
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The address where the ELF core header is stored is passed to the secondary
kernel as a kernel command line option. The memory area for this header is
also marked as a separate EFI memory descriptor on ia64.
The separate EFI memory descriptor is at the moment of the type
EFI_UNUSABLE_MEMORY. With such a type the secondary kernel skips over the
entire memory granule (config option, 16M or 64M) when detecting memory.
If we are lucky we will just lose some memory, but if we happen to have data
in the same granule (such as an initramfs image), then this data will never
get mapped and the kernel bombs out when trying to access it.
So this is an attempt to fix this by changing the EFI memory descriptor
type into EFI_LOADER_DATA. This type is the same type used for the kernel
data and for initramfs. In the secondary kernel we then handle the ELF core
header data the same way as we handle the initramfs image.
This strategy requires changes in the secondary kernel as well, I'll
post the kernel patches in a little while.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
I used fixed 64M as physical offset in vmcore ELF segment header.
This gives trouble to crash utility to analyze vmcore on platform that
load kernel to a different address.
This patch will fix it.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
This is the second time this patch has been applied, it seems to have been
inadvertantly reverted as part of the crash_create_elf64_headers() patch,
f038d30bff8510a1df1e72af08db1766581d1f2c.
Cc: Jay Lan <jlan@sgi.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Make kexec/arch/ia64/crashdump-ia64.c:Make cmdline_add_elfcorehdr() <= 80col
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(-)
|
|
There are two memory_ranges arrays declared in the IA64 kexec code.
One in kexec-ia64.c and the other one in crashdump-ia64.c.
They currently were allocated as a hard-coded size of array. Since
SN systems may scale to hunders of nodes and each node may contain
up to 12 DIMMs, the hard-coded size of 1024 is not enough for very
large systems.
The size of either array can not be greater than the number of
entries in /proc/iomem, which is saved as "max_memory_ranges"
and is used to dynamically allocate the two arrays.
Signed-off-by: Jay Lan <jlan@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a note about cmdline_add_elfcorehdr() allocating memory.
This isn't too much of a problem as cmdline_add_elfcorehdr()
is only called once, but I feel better noting it all the same.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Remove commented-out variables from load_crashdump_segments()
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
elf_ia64_load() passes a const char ** to load_crashdump_segments(),
so it needs to expect that rather than a char **
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Hi Magnus,
The previous patch, "Make use of crash_create_elf64_headers() (ia64)",
needs crashdump.h to be included else various types are missing.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
kexec-tools: Use generic /proc/iomem code (ia64) V2
This patch modifies the ia64-specific code to use the new generic code.
Version 2 of this patch uses the newly renamed parse_iomem_single() function.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec-tools: Make use of crash_create_elf64_headers() (ia64) V2
Use the new function provided by crashdump-elf.c instead of duplicating the
same functionality in prepare_crash_memory_elf64_headers().
This patch also makes the code create a separate kernel program header - just
like x86_64 does. This may or may not be correct, but making the architectures
behave as similar as possible is probably a good thing.
On top of that the patch contains a bugfix for the fact that space for crash
note program headers are never allocated...
Version 2 of this patch removes alignment and the callback from elf_info.
This together with a cosmetic crashdum -> crashdump fix. I'm not 100% sure
if the removal of the alignment is correct though.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Removed trailing whitespace
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec-tools: Use get_crash_notes_per_cpu() (ia64)
Use get_crash_notes_per_cpu() on ia64 to avoid code duplication.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Remove trailing 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>
|
|
Check whether memory for crashkernel is reserved by calling arch dependent
functions. The patch also creates dummy functions in ppc, ia64 and s390
architectures, so that the build process will not break. The function
"is_crashkernel_mem_reserved" needs to be implemented on ppc, ia64 and
s390 architectures.
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
I used fixed 64M as physical offset in vmcore ELF segment header.
This gives trouble to crash utility to analyze vmcore on platform that
load kernel to a different address.
This patch will fix it.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On Fri, 2006-06-09 at 19:50, Welterlen Benoit wrote:
> Zou Nan hai wrote:
> > The ia64 kdump patch is in 2 parts.
> >
> > the kexec-kdump-ia64-2.6.16.patch should apply on top of the previous
> > kexec patch by Khalid in Tony's test tree.
> >
> > the kexec-tools-kdump-ia64.patch should apply to kexec-tools-1.101
> > with kexec-tools-1.101-kdump.patch
> >
> >
> > To test it.
> > Build first SMP kernel with KEXEC and KDUMP enabled.
> >
> > Boot it with kernel parameter "crashkernel=XXX@YYY"
> > means reserver XXX from YYY for crashdumping.
> > Build an UP kernel with KEXEC KDUMP VMCORE enabled.
> > load this kernel as a crashdumping kernel
> > kexec -p vmlinux.gz --initrd=initrd --append="...."
> >
> > trigger a crash,
> > maybe "echo c > /proc/sysrq-trigger"
> > after the crash kernel boots,
> > cp /proc/vmcore core
> >
> > gdb first_kernel_vmlinux core
> >
> > please test and review.
> >
> > Signed-off-by: Khalid Aziz <khalid_aziz@hp.com>
> > Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
> >
> >
> > https://lists.osdl.org/mailman/listinfo/fastboot
> >
>
> Hello Nan hai,
>
> I tried your patches. It seems that the kexec-tools-kdump-ia64.patch
> file can not be applied after the latest release of kexec-tools
> http://lse.sourceforge.net/kdump/patches/1.101-kdump9/kexec-tools-1.101-kdump9.patch
>
> I modified it for that. (attached file).
>
> I have a question about kdump :
>
> When the second kernel is loaded, kexec checks if the segments of the
> new kernel are in the reserved memory
>
> valid_memory_range in kexec/kexec.c :
> if ((send > mem_max) || (sstart < mem_min)) return 0;
>
> but mem_min and mem_max are defined by the XXX@YYY argument of the
> first kernel.
> For me, with 512@512 :
> more /proc/iomem
> ...
> 049cc000-77ffffff : System RAM
> 20000000-3fffffff : Crash kernel
> ...
> So, I can not load the second kernel : Invalid memory segment
> 0x4000000 - 0x469ffff
>
> When I set 64@64 argument for the first kernel, the checking is ok,
> but I have another issue :
> kexec_load failed: Cannot assign requested address
> entry = 0x80020 flags = 320001
> nr_segments = 6
> segment[0].buf = 0x6000000000021b90
> segment[0].bufsz = 20
> segment[0].mem = (nil)
> segment[0].memsz = 10000
> segment[1].buf = 0x60000000000222d0
> segment[1].bufsz = 10638
> segment[1].mem = 0x80000
> segment[1].memsz = 20000
> segment[2].buf = 0x2000000003b50010
> segment[2].bufsz = 23473c
> segment[2].mem = 0x100000
> segment[2].memsz = 240000
> segment[3].buf = 0x20000000002f0010
> segment[3].bufsz = 692dd8
> segment[3].mem = 0x4000000
> segment[3].memsz = 6a0000
> segment[4].buf = 0x2000000000990010
> segment[4].bufsz = 42c8
> segment[4].mem = 0x46a0000
> segment[4].memsz = 10000
> segment[5].buf = 0x20000000009a0010
> segment[5].bufsz = 17c3ec
> segment[5].mem = 0x46b0000
> segment[5].memsz = 2d0000
>
>
> Segments of the second kernel are the same than the first one
> (0x0000000004000000, 0x00000000046a0000 ...)
> We can not change the PHYSICAL_START as in other architectures (x86,
> x86_64, powerpc).
>
> So, I don't understand how it should work. Can you please have some
> explanation on this ?
>
> Thank you very much !
>
> Best regards,
>
> Benoit Welterlen
>
>
> ______________________________________________________________________
I modify the patch based on this one, fixed some bugs in it.
please test.
Thanks
Zou Nan hai
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
