| Age | Commit message (Collapse) | Author |
|---|
|
MUSL doesn't support %L except for floating-point arguments; therefore,
%ll must be used instead with integer arguments.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
The ehdr parameter of machine_apply_elf_rel() is used.
This resolves a build regression.
Fixes: 4a2ae3a39c64 ("Pass struct mem_sym into machine_apply_elf_rel()")
Signed-off-by: Simon Horman <horms@verge.net.au>
Reviewed-by: Pratyush Anand <panand@redhat.com>
|
|
On PowerPC64 ABIv2 we need to look at the symbol to determine
if it has a local entry point. Pass struct mem_sym into
machine_apply_elf_rel() so we can.
Signed-off-by: Anton Blanchard <anton@samba.org>
Tested-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The main kexec option code handles the -? option. Remove all the
duplicate -? handlers in the arch code which are never used.
Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro
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>
|
|
The argument parsing is currently a bit broken as main()'s getopt_long()
knows nothing about either the architecture-specific options or, even
more specifically, the architecture-and-loader-specific options.
This patch introduces new #defines for all architectures,
KEXEC_ALL_OPTIONS and KEXEC_ALL_OPT_STR. These contain all possible
options for a given build, and the getopt_long() passes in main() and
arch_process_options() will now recognise arch- and loader-specific
options; these will not be re-ordered in argv[], there is no confusion
over which argv[] entry is the kernel filename, and using '--opt=foo' and
'--opt foo' both work.
All architectures have command line options (and #define OPT_BLAHs)
consolidated into their include/arch/option.h files. x86_64 builds
parts of i386/ as well, so now both share a single option.h file (with
a symlink).
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
mips, ppc)
These architectures don't have any architecture-specific options
(note: distinct from loader options, which are more specific), yet
their arch_process_options() functions contain getopts_long() calls
followed by no argument processing. The code doesn't do anything,
so this patch removes it.
Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Apparently this never happens, but the current code seems excessively loose.
1) die if it does happen
2) initialise offset to make gcc happy.
# ia64-unknown-linux-gnu-gcc --version
ia64-unknown-linux-gnu-gcc (GCC) 3.4.5
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# make
kexec/arch/ia64/kexec-elf-ia64.c: In function `move_loaded_segments':
kexec/arch/ia64/kexec-elf-ia64.c:102: warning: 'offset' might be used
uninitialized in this function
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>
|
|
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>
|
|
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>
|
|
This code was copy-pasted into every architecture and was basically
identical.
Besides producing a nice net reduction in code, this factors a
portability challenge into a single function that can be easily replaced
at build-time.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reduces the kexec-tools' demands on the capabilities of the
toolchain, and improves standards conformance, without really changing
maintenance complexity.
Signed-off-by: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This continues the work that Jamey Sharp did on i386 to
cover all other architectures.
Cc: Jamey Sharp <jamey@thetovacompany.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Remove debug messages that were accidently added as part of
commit 91ce7876a6ec7e51532f3a2a949bd8d284f5aaad,
"kexec-tools: no machine machine to proc_iomem()"
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>
|
|
When I first added proc_iomem() it was for ia64 Xen as
certain regions are added /proc/iomem_machine instead of /proc/iomem
on that platform.
On further examination I have found that all regions need to be
added to /proc/iomem_machine.
This patch changes the ia64 implementation of proc_iomem()
to always return /proc/iomem_machine if xen is in use.
A subsequent patch will remove 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>
|
|
With the recent build changes a number of unneded files
crept into tarballs, including .o and .d files.
This patch is farily verbose, but hopefully in the long
run this system will be obvious enough to be maintainable.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since we use the implicit ruls for .c and .S, just colelct all sources
in the one variable.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Use /proc/iomem_machine for ia64 xen where pysical and machine efi maps
differ. Without this kexec gets a very jaded view of the world, and
/proc/vmcore after a kdump will only have a partial memory dump. Requires a
companion patch to kexec-tools.
Signed-off-by: Simon Horman <horms@verge.net.au>
kexec/arch/ia64/Makefile | 1 +
kexec/arch/ia64/kexec-iomem.c | 23 +++++++++++++++++++++++
2 files changed, 24 insertions(+)
1e7eca377b0b84a638c49eae614103b5e6fa7b42
|
|
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>
|
|
Make sure max_memory_ranges are cleared before incremented
I happened to call get_memory_ranges() twice on ia64 while debugging some
kdump issue the other day. This did not work as expected because the
variable max_memory_ranges was not cleared before being incremented.
So the second caller gets more ranges than needed.
This is normally not a problem - get_memory_ranges() is only called once -
but I think it is good coding practice to start from a known state.
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>
|
|
This patch fixes a efi_memmap overflow problem on large system.
Currently the kexec allocates statically 16k buffer to contain
efi_memmap. It can hold about 333 entries. It causes data
corruption on large system.
This patch would let kexec allocate the efi_memmap at run time using
the actual size allocated in the production kernel.
Signed-off-by: Jay Lan <jlan@sgi.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Move defines to the top of kexec/arch/ia64/kexec-elf-ia64.c
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Make kexec/arch/ia64/kexec-elf-ia64.c <= 80col wide
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
fix bogus mem_max = ULONG_MAX
Cc: Bob Montgomery <bob.montgomery@hp.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>
|
|
On Tue, Nov 21, 2006 at 07:13:56AM +0800, Zou Nan hai wrote:
> This patch make normal "kexec -l" first try physical address suggested
> by vmlinux.
>
> If there is no enough memory, kexec tools will search /proc/iomem and
> find a place to put the new kernel.
>
> This is necessary for "kexec -l" to work on SN platform.
>
> Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
>
Hi Nan hai,
sorry for not responding sooner.
I have take a look at your patch with an eye to including it into
kexec-tools-testing. It does seem like a good feature.
Below is an updated version of the patch that cleans up your
implementation a little. In particular.
* update_loaded_segments() returns -1 on error, 0 on success
- amongst other things the previous incarnation could return nothing
at all in once case.
* else { if () { ; } } -> else if () { ; }
* < 80 columns wide
* removed trailing whitespace
Is it ok to apply this incarntation of the patch?
I can make my changes a second patch if you prefer.
Signed-off-by: Simon Horman <horms@verge.net.au>
* Incremental version of above patch
* Include kexec-ia64.h in kexec-elf-ia64.c for update_loaded_segments()
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On Tue, 2006-11-21 at 07:33, Jay Lan wrote:
> Zou, Nanhai wrote:
> >> We do not rely on machine crash on CPU 0 any more. If the
> >> crashing CPU is not cpu 0 and the cpu 0 not being returned to
> >> the slave loop, this case is handled by our PROM now.
> >>
> >> However, if somebody tries to boot up a production kernel using
> '-le'
> >> option _after_ the kexec'ed kernel is up running, the third kernel
> >> would not boot unless we boot up the second kernel with cpu 0. I
> >> posted a question on "if running 'kexec -le' on a kexec'ed kdump
> >> kernel is legal" earlier and Vivek responded saying the scenario
> >> is not guranteed to work. So, i think we are fine here.
> >>
> >
> > Ok, so with this patch and the PROM fix, on a SN system,
> > 1. Kdump -> 2nd kernel works.
> > 2. Kdump -> 2nd kernel -> Kexec to third kernel will not work.
> > 3. Kexec -> 2nd Kernel -> Kexec -> 3rd kernel works?
> > 4. Kexec -> 2nd Kernel -> Kdump -> 3rd kernel works?
> >
> > I think if scenario 1, 3 and 4 works it will be ok. Scenario 2 is
> not so useful I guess.
> >
>
> With the patch Nanhai sent to me to fix '-l' option on SN system,
> now scenario 1, 3 and 4 all works. Of course, you need to include
> 'crashkernel' parameter in "append" option when you do 'kexec -l'
> in order for scenario #4 to work. You do not need crashkernel
> parameter for #3 though.
>
> Thanks,
> - jay
>
>
This is the patch,
This patch make normal "kexec -l" first try physical address suggested
by vmlinux.
If there is no enough memory, kexec tools will search /proc/iomem and
find a place to put the new kernel.
This is necessary for "kexec -l" to work on SN platform.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
|
|
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>
|
