| Age | Commit message (Collapse) | Author |
|---|
|
Add a new type `multiboot2-x86` that allows loading multiboot2 [1] images
within the relocation range specified in the image header. The image is
always placed at the lowest available address, regardless of the
preference information.
[1] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html
Signed-off-by: Varad Gautam <vrd@amazon.de>
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>
|
|
--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>
|
|
Vivek pointed out that I missed the i386 part in this commit,
commit 1100580b05e3fdfe648d9be8617d962b11f4b88b
Author: Amerigo Wang <amwang@redhat.com>
Date: Thu Mar 3 00:10:43 2011 +0800
get the backup area dynamically
Yes. The customer who reported that bug definitely only
tested it on x86_64. Now make it complete.
Signed-off-by: Amerigo Wang <amwang@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
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>
|
|
Because the get_memory_ranges() function was the same on i386 and x86_64, and
because that /sys/firmware/memmap interface should also be used for x86_64
without *new* code duplication, that part was moved out in a new file called
kexec-x86-common.c. That file only contains the memory map parsing for both the
"old" /proc/iomem interface and the new /sys/firmware/memmap interface.
That file is now built for i386 and x86_64.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
get_memory_ranges_sysfs()
With the previous patch, we have a duplication between that both functions
for following tasks:
- don't report the interrupt table as RAM,
- set the mem_min and mem_max limits for kdump.
This patch removes that redundancy into the function get_memory_ranges()
that calls both functions internally.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
After the patch that provides /sys/firmware/memmap has been merged in the 'tip'
tree by Ingo Molnar, kexec should use that interface.
This patch implements architecture-independent parsing in a new file called
firmware_memmap.c. The x86 part is ported to use that memory map for
kexec. We don't use that memory map for building the ELF core headers,
that was the intention for that new interface.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes following compiler warning:
kexec/arch/i386/kexec-x86.c:234: \
warning: missing initializer
kexec/arch/i386/kexec-x86.c:234: \
warning: (near initialization for 'arches[5].arch')
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Bernhard Walle <bernhard.walle@gmx.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch just removes trailing whitespace from kexec/arch/i386/kexec-x86.c
before modifying something.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Bernhard Walle <bernhard.walle@gmx.de>
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>
|
|
Removes the machine parameter to proc_iomem() which is no
longer of any use.
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
|
|
Correct spelling/typos in baud_rate.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On i386, kexec generates ELF64 core headers by default if the user doesn't
override this via a command line option. Because GDB cannot analyse
ELF64 core dumps on 32 bit platforms, it's a bad idea to use ELF64 if it's not
needed.
This patch selects ELF32 if the biggest memory address fits in 32 bit address
space, which should be the case on non PAE systems. If the user specifies
a command line option, that option overrides the detection.
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On Wed, Dec 14, 2005 at 02:50:52PM -0600, Milton Miller wrote:
[..]
> >>(2) why do you stat the files instead of just trying to open them and
> >>check for ENOENT?
> >>
> >>milton
> >>
> >
> >I wanted to differentiate between two cases. One being sysfs not
> >mounted
> >and other being file not being present (Due to kernel bug or cpu not
> >present), hence used stat(). In case of sysfs not being mounted, we
> >simply exit after giving an error message. In other case we continue
> >to loop through other cpus and ignore cpu, which is not present.
> >
>
> Ok, but try to open the file first. IF you want to do this diagnostic
> after the open fails, that is ok. But don't do this check n times (n =
> number of cpus) when the file exists.
>
I have moved the sysfs mounted check in failure condition.
>
> >
> >On Tue, Dec 13, 2005 at 09:36:26AM -0800, Haren Myneni wrote:
> >>Vivek, I believe, we should push this func into arch independent code.
> >>Otherwise, we have to copy it for every platform.
> >>
> >
> >We have reworked the patch and moved this code to architecture
> >independent
> >portion.
> >
>
>
> Only the x86 code has the fallback the old name, not the genric code.
>
Only i386 port of kdump was available when crash_notes was exported
through /sys/kernel/crash_notes. Rest of the architectures see new arch-
independent percpu crash_notes sysfs interface only. Hence thought no
point copying backward compatibility code in generic code.
>
> Also, there are error paths that do not set the address, others that
> zero it.
>
The error paths which do not set address to zero are non return path. They
call die() which inturn calls exit(1) after printing appropriate error
messasge.
> What happens if the base kernel is too old for kexec-panic, where
> neiter file will exist?
>
In that case kexec will fail much earlier. There will be no reserved
memory area for loading second kernel (crashkernel=X&Y) hence attempt to
load the second kernel will fail and control will not reach this place at
all.
Modifed patch appended.
Thanks
Vivek
o This patch moves per cpu interface to retrieve crash_notes address to
architecture independent section. (As suggested by Haren)
o For i386, kernels older than 2.6.15-rc1-mm2 used to export crash_notes
through /sys/kernel/crash_notes. This patch also provides backward
compatibility with older kernel versions.
o Definition of MAX_NOTE_BYTES moved to architecture independent header
file as everybody is using same definition.
o Definition of MAX_LINE moved to architecture independent header file.
Seems to be a better option than defining it in many C files.
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
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>
|
|
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
