| Age | Commit message (Collapse) | Author |
|---|
|
* Rename md1 and md2 to md_src and md_dest respectively to make things
a little easier to follow.
* Remove p1 and p2, use src and dest instead
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
There is a farily complex if, for construct in patch_efi_memmap(),
that seems to be simplifyable to a somewhat simpler while statement.
Note that this does change the logic statement. In particular
the original code has if (seg->end < mend) towards the end,
and the new code effectively replaces this with if (seg->end <= mend).
However, in the original code this is copled with a separate
if (seg->end > mend) check at the begining, so I believe that
this is actually a minor (possibly never seen) logic error in
the original code. The node code just always checks (seg->end > mend).
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This patch removes a duplicated assignment of *md2.
It also replaces a switch statement with an if statement
which is much more compact in this instance.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This patch reduces the nesting in patch_efi_memmap() by
jumping to the next interation of the inner for loop
if the following condition is true.
if (seg->start < mstart || seg->start >= mend)
This is instead of a reasonably large ammount of code inside the if
conditional if the converse is true.
This makes things somewhat easier to read as the nesting is already
quite deep, and many lines do not fit easily within 80 columns.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Make purgatory code 80 columns wide
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Remove kexec/arch/ia64/kexec-ia64.h.orig and purgatory/arch/ia64/Makefile.orig
which were (presumably accidently) introduced in changest
9241000f28eb6b86a06c0be2d6cf31498373bc1c, "kdump ia64".
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>
|
|
o Currently DEBUG macro is being used at some places by purgatory code. We
need this DEBUG macro to be defined by user at compile time for including
or excluding the debug code. -DDEBUG is more common practice to use for
this purpose. Hence, changing DEBUG() to DEBUG_CHAR() and make space
for DEBUG to be defined by user.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
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>
|
|
The purgatory code in kexec-tools does not currently setup CS when booting a
64-bit ELF file such as a vmlinux file. This together with the fact that the
Linux kernel doesn't reload CS properly if booted from the 64-bit entry point
means that booting a vmlinux may fail under certain conditions.
The only known combination that triggers this problem is when kexec-tools and
kexec are used to load a x86_64 vmlinux under a dom0 Linux running under the
Xen hypervisor.
This patch is needed for sure to reload kernels with version <= 2.6.17. There
are fixes for this problem in the URL below, but if a fix will be included in
2.6.18 or not is unknown at this time.
http://permalink.gmane.org/gmane.linux.kernel/438998
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Removed some trailing whitespace
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Get rid of multiple definitions of backup region.
o Give more relevant name to backup source region.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
|
|
On Thu, Jul 27, 2006 at 12:32:56PM -0600, Eric W. Biederman wrote:
>
> I have found a couple of moments and have been able to
> catch up with most of the backlog of patches for kexec-tools.
> There are several details I need to follow up on, and there is
> some testing I want to do to make certain everything is working.
>
> The primary kexec-tools archive is:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/kexec-tools.git
>
> An archive to hold versions before 1.101 is at:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/kexec-tools-historic.git
>
> So far I have all version in there since 1.0 except 1.9, 1.92, and 1.93
> if someone happens to have a copy point me at it and I will update the
> history.
>
> Patches that hang out in quilt for a while can be annoying to import
> into git because their authorship information is not stored in an
> unambiguous way. git is general is much stricter about the format
> it's meta-data information is stored in.
>
> Maneesh in kdump10 there were two patches in particular that I have
> not sorted out their who wrote them. If you could help me sort that
> out I would appreciate it.
>
> ppc64-initrd-option.patch
> ppc64-kdump-device_tree-sort.patch
>
> Before I make a release here is my list of things I intend to look at:
> - Why we have defined the location of the crash backup region twice.
Hi Eric,
Are you referring to BACKUP_REGION_START and BACKUP_START declarations?
I am not sure why did I do that, may be somehow I thought that purgatory
code is not sharing the header files with main kexec code base.
Please have a look at the patch attached for i386. If this looks
fine, I shall generate the patches for x86_64 and ppc64 too.
Thanks & Regards
Vivek
Signed-off-by: Vivek Goyal <vgoyal@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>
|
|
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>
|
|
This patch implements the purgatory support to take backup
of the first 32KB of the first kernel
- Modified the v2wrap code to make the secondary cpus spin
directly in the v2wrap after pulling them out of kexec_wait
- Use the elf_rel function support to set the various
symbols used in purgatory
- load device-tree as a separate segment
- other miscellaneous compiler warnings cleanup
- add purgatory code support for backup
- build purgatory as relocatable for ppc64
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o This patch adds the support for saving first 640k to the backup
region for x86_64.
Signed-off-by: Murali <muralim@in.ibm.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch builds v2wrap from within purgatory
Signed-off-by: Mohan Kumar <mohan@in.ibm.com>
Signed-off-by: R Sharada <sharada@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>
|
|
--===============39718348520004598==
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi Milton,
first of all thanks for looking at the patches.
> 1) When patching the command line, you read the string from the
> optarg. While you clear the area in the kernel looking at
> COMMAND_LINE_SIZE, you do not limit the length that you copy into
> the kernel by this amount. This would seem like a buffer-overflow
> situation that could easily be trapped.
Yes, you're right. The kernel image could be damaged. Fixed.
> 2) I noticed your ramdisk code is quite similar in function to
> slurp_file in kexec/kexec.c. I realize this is probably a new
> function.
Fixed as well :)
> 3) Your elf-rel loading seem to not be implemented, but your probe
> returns 0 just like the image loader.
I think you're talking about the function machine_verify_elf_rel().
Unlike the probe functions this one should return 0 on error,
shouldn't it?
> 4) You seem to have several addresses hard-coded into the kexec-s390.h
> file. This would seem to limit the image you are loading, including
> any panic crash kernel options using the current scheme. I don't
> know your abi to know what other issues you might have with a more
> generic kexec to image interface. (It appears you setup your image
> to load as if it were from 0 but skipping IMAGE_READ_OFFSET bytes.
The hard coded addresses are part of the kernel abi. Nothing needs to
be changed here. Skipping the first 64k of the kernel image is ok too,
since you usually would only find a loader routine there which would
load the rest of the kernel image into ram and then start it.
If you are really interested you might have a look at
arch/s390/kernel/head.S in the kernel sources :)
Also we do not plan to use the kdump feature. It doesn't make too
much sense for the s390 architecture since we have already other
mechanisms which allow to reliably dump complete memory and register
contents at any given state of the system.
The patch below should be better (still against 1.101). Guess I will
come up with an improved kernel patch too.
Thanks,
Heiko
diffstat:
configure | 5 -
kexec/arch/s390/Makefile | 6 +
kexec/arch/s390/include/arch/options.h | 11 ++
kexec/arch/s390/kexec-elf-rel-s390.c | 23 +++++
kexec/arch/s390/kexec-image.c | 137 +++++++++++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.c | 104 +++++++++++++++++++++++++
kexec/arch/s390/kexec-s390.h | 25 ++++++
kexec/kexec-syscall.h | 7 +
purgatory/arch/s390/Makefile | 7 +
purgatory/arch/s390/include/limits.h | 54 +++++++++++++
purgatory/arch/s390/include/stdint.h | 24 +++++
11 files changed, 402 insertions(+), 1 deletion(-)
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
