| Age | Commit message (Collapse) | Author |
|---|
|
Hi,
This fixes a minor regression that occured with Jeremy's recent
reworking of the build system. I guess he wasn't dealing with
compressed images and thus didn't notice that zlib support had
been disabled.
The fix involves updating an #ifdef to use the new symbol,
and ensuring that -lz is passed to the linker as neccessary.
Cc: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Instead of putting a heap of -D directives in CPPFLAGS, use a config.h
header.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Just use fclose() instead of close() to close a pointer of type FILE *.
That fixes the compile warning
kexec/kexec.c: In function 'check_reuse_initrd':
kexec/kexec.c:793: warning: passing argument 1 of 'close' makes integer from pointer without a cast
Signed-off-by: Bernhard Walle <bwalle@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Adds a generic --reuseinitrd option and performs some sanity checks on
it. Can be used with the retain_initrd kernel option.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Move memory range variables
The common kexec code is currently using two global variables to keep
track of memory ranges. Other data is kept in a per-instance structure.
This mix is of per-instance and global variables is confusing and leads
to messy code in general. So let's not.
This patch moves the global variables into struct kexec_info and makes
sure that structure is passed along where needed. No logic is changed.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
kexec/kexec.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes zero-size xmalloc failure, which I ran
across with a uClibc implementation of malloc(), kexec'ing
x86_64 vmlinux.
Additionally, it removes inefficiencies related to creating
zero-sized memory ranges, which I noticed under the same
conditions.
Signed-off-by: Roman Kononov <kononov195-uclibc@yahoo.com>
Reformated and rediffed as it wouldn't apply to my tree for some reason.
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
* Exit if malloc fails - previously the error was ignored
* Free allocated memory before returning
Signed-off-by: Simon Horman <horms@verge.net.au>
Acked-by: Magnus Damm <magnus@valinux.co.jp>
|
|
Make kexec/kexec.c 80col wide or less
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
fix spelling of address in help text
Cc: Dave Anderson <anderson@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
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>
|
|
o With relocatable kernel in picture, the kernel text map offset
(__START_KERNEL_map) is no longer constant. It depends on where kernel
is loaded.
o Now /proc/kcore is read to determine the virtual address the kernel
is mapped at and /porc/iomem is read for determining the physical
address where kernel is loaded at. This information is enough to
create to fill virtual address and phy addr info for elf header
mapping kernel text and data.
o Virtual address for kernel text are needed by gdb as well as crash to
retrieve the meaningful data from core file.
o This patch requires "elf note memsz" fix in the kernel. Currently
that fix is in -mm tree. It will still work with older kernels. It will
display the warning messages (/proc/kcore could not be parsed) and hardcode
the kernel virtual address and size.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Attached herewith is a patch to update the man page for kexec, specifically
help message for -u option.
Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
|
|
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
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>
|
|
o "kexec -l bzImage" fails on i386 system with more than 4G of RAM. Error
message displayed is "Could not put setup code above the kernel parameters".
o Now with 64bit resource patch, memory more than 4G is exported through
/proc/iomem. locate_hole() is using local varibles of size unsigned long
and that truncates memory values at some placed and leads to undesired
results.
o hole_align is also unsigned long and which ends up resetting top 32 bits
of 64bit memory start field while alignment operation is done.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
|
|
o This patch fixes a problem reported on the platform where memory end is not
page aligned. There kexec gives an error "Invalid memory segment". The
problem has been identified by Aaron Klingaman.
o Problem occurs when add_buffer() tries to add a buffer of size memsz which
is not integral multiple of page size. Add buffer calls locate_hole() which
returns successfully. Later add_buffer() calls add_segment() which in turn
makes all segment sizes page aligned and then verifies if memory range is
valid or not. This creates a problem if memory end is not page aligned and
a buffer has been allocated on memory end boundary. Because memsz has been
made page aligned after calling locate_buffer(), it might have crossed
valid memory locations.
o Problem is fixed by page aligning the memsz in add_buffer() before calling
locate_hole().
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>
|
|
A good first attempt but it conflicts with other work :(
This reverts commit caa2e42897cb8cb00c7040b9133e8b740809241c.
|
|
|
|
|
|
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
