| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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>
|
|
Hi,
I'd like to apply this patch to kexec-tools-testing if there are no
objections.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
Help message for --noio option
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch is to fix a "--noio option" patch posted on 9/20/2006 by
Nanhai that disables I/O in purgatory code.
The "--noio" option should specify zero argument to avoid eating out
the next option.
Signed-off-by: Jay Lan <jlan@sgi.com>
* Removed spurious white-space change
* Forward-ported to kexec-tools-testing
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This adds vmm support to kexec-tool for ia64. This is annalogous
to the same feature that is present in the latest version of elilo.
It is a method of booting a vmm (hypervisor) such as Xen.
Essentially it works as follows.
* If the --vmm argument is not provided, then the kernel is booted as normal,
no changes
* Else, the image specified by --vmm is placed loaded into the elf
segments, where the Linux kernel image would otherwise have gone.
And the Linux kernel image, allong with its length is loaded into a
seprate segment, and passed as new entry at the end of the boot parameters.
This is somewhat similar to how initramfs/initramd images are passed
to a booting kernel, and can work in conjunction with that feature.
On boot (or in this case on kexec) the vmm (hypervisor) will be
loaded instead of a Linux kernel, and the hypervisor will then load up
the Linux kernel as it sees fit.
This is needed in order for kexec from Xen to Xen, using the
port of kexec to Xen that I am working on, to work.
I am not entirely fond of this design, and i think that developing
an ia64 variant of multiboot would be much nicer. However it is
an existing method that is currently in widespread use through
its incarntation in elilo. And if multiboot is added in future,
it can be done as a separate boot method, and thus orthogonal to this
patch.
In order to use this code a number of other changes are needed,
in particular:
1. Xen and the corresponding Linux Kernel needs to be patched with
the port of kexec to ia64-xen that I have been working on.
I will post the latest version of these patches to xen-devel
shortly.
2. The currently hardcoded PAGE_OFFSET value in purgatory needs
to be changed from the Linux value to the Xen value. I will
post a very hackish, definately not to be released, patch
after this patch which includes a comment that explains this problem
more clearly.
Also, xen->linux and linux->xen is still very much work in progress due
to the problem described at the following link
http://permalink.gmane.org/gmane.linux.ports.ia64/14995
However, from an infastructure point of view I think it would be good to
apply this code, so that kexec-tool is one step closer to being able to
support vmms (hypervisors). The patch does not alter any existing
behaviour, it just adds a new feature. Bugs asside, the only real danger
seems to be confusion for end-users, perhaps we could comment out the help
text to hide the feature from the lay user, or attach a big fat warning to it.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
o Fix ia64 compilation issues.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
SN platform support PIO in a different way to generic IA64 platform. It
does not support most of the legacy I/O ports.
Give an --noio option to kexec-tools to disable I/O in purgatory code.
This patch also removed an unused io.h in kexec-tools.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Edited to consistently use tabs instead of spaces for intentation,
remove one instance of trailing whitespace, and fix indentation
of noio line in options[].
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
without this patch, crash tool will not able to analyze efi memmap of
first kernel from vmcore file.
This patch is against kexec-tools-1.101 with kdump10 patch.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Removed bogus fragments caused by whitespace addition
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>
|
|
This patch adds support for kexec-tools on ia64. This patch applies on
top of -kdump7 patch from <http://lse.sourceforge.net/kdump/>.
Signed-off-by: Khalid Aziz <khalid.aziz@hp.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
|
