| Age | Commit message (Collapse) | Author |
|---|
|
[BUILD] Make sure sha256.c is compiled without optimisation
sha256.c needs to be compiled without optimization, else
purgatory fails to execute (on ia64 at least).
By placing -O0 after $(CFLAGS), which is provided by
the prevailing environment, it overrides any other -O flags
provided.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
[BUILD] CPPFLAGS, CFLAGS and LDFLAGS fixes
* Set internal CPPFLAGS as EXTRA_CPPFLAGS, CFLAGS as EXTRA_CFLAGS,
and LDFLAGS as EXTRA_LDFLAGS
- Don't overwrite CPPFLAGS, LDLFAGS or CFLAGS from the environment
- They are irrelevant for BUILD_CC
- When cross-compiling for a ppc64 host on a non-ppc64 host,
EXTRA_CFLAGS, which is included in BUILD_CPPFLAGS contains
-mcall-aixdesc, which does not work on i386 at least
* Use LDFLAGS when linking kexec
- Append rather than overwrite in purgatory/Makefile
The purpose of these changes is three-fold.
* CPPFLAGS, CFLAGS and LDFLAGS from the environment really ought
to be honoured. For one thing;
* Without these changes, the confgiure taget in
the toplevel makefile can't work
* Without these changes, cross compiling does not work -
well, I can't work out how to get it to work anyway.
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>
|
|
o Fix ia64 compilation issues.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Fix ppc64 compilation issues.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Fix x86_64 compilation issues.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Fix ppc compilation issues.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Fix i386 compilation issues.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Adding a new parameter to elf functions. This flag can be used to alter
the function behaviour. Currently only one bit is being used for skipping
the elf file len check while builing the elf info.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a more verbose comment to explain why set_virtual_address_map is
replaced why a dummy function
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This unifies the comments in purgatory-ia64.c to always use C style
comments. Previously some comments where C style, while others were
C++ style.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
This makes the tail of patch_efi_memmap() slightly less nested,
and thus a little easier to read.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
Just use boot_param->efi_memdesc_size directly instead, it seems
at least as clean, and possibly easier to follow.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
len is assigned once and used once, just use boot_param->efi_memmap_size
directly instead.
Signed-Off-By: Simon Horman <horms@verge.net.au>
|
|
* 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>
|
|
[BUILD] Don't do a partial build on clean
$(OBJDIR)/kexec/purgatory.c is a target and needs special treatment,
else calling make clean on an already clean tree will cause it -
and as a result a whole bunch of other stuff - to be built only
to be immediately cleaned.
There are some more pathological cases, where users manually
removed .d files, and then these are regenerated (but not removed)
on make clean. However this change does ensure that the following
is a bit more sensible.
make clean; make clean
Signed-OFf-By: Simon Horman <horms@verge.net.au>
|
|
[BUILD] Remove configure as its a target of configure.ac
Generally only sources are stored in an SCM.
There seems little reason to store configure, which is a target,
as it can trivially be generated by autoconf and then
either used by developers or included in distributed tar balls.
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>
|
|
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>
|
|
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>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Put the debug code under #ifdef DEBUG instead of #if 0.
o This patch only takes care of x86_64 code. Rest of the arches can slowly
do similar modification.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
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>
|
|
o Sometimes while second kernel is booting, it stomps over the segments
stored by kexec/kdump. Of course this is an error condition and should
be fixed if such instances are met. Such error conditions are hard to
detect sometimes.
o This patch loads the vmcore elf headers towards the end of the reserved
hole instead of loading it towards the beginning of the hole. This
effectively keep kernel and elf header segment as far as possible and
chances of it getting stomped are less.
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>
|
|
This patch is against kexec-tools-1.101 with kdump10 patch.
This patch reserve efi memmap and boot param area for the first kernel
so that they will not be overlapped.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com>
Removed trailing whitespace
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>
|
|
fix triple underscore typo in x86 and x86_64 code
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The patch extends elf_rel_load() to handle section names correctly.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
elf_rel_build_load() is currently using the symbols purgatory and
purgatory_size as buffer and buffer size instead of using the arguments
passed to the function. This patch fixes this by changing the code to
use the function arguments as buffer and buffer size.
Signed-off-by: Magnus Damm <magnus@valinux.co.jp>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
* kexec-tools for PPC64 only support 4k page size and does not work with kernels
configured with 64k page size support. This patch adds support for 64k page
size on PPC64 arch.
* Replace PAGE_SIZE by getpagesize()
Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
o Can not think of a reason why somebody will generate ELF32 core headers
while running 64 bit kexec-tools on a 64 bit OS. Hence getting rid of it.
o It broke crash tool as 32 bit headers can not define 64 bit OS as vaddr
field is 32 bit and it overflows. The vaddr field is filled for linearly
mapped region so that gdb can access the symbols and open the dump.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
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>
|
|
o change BACKUP_START and BACKUP_END to BACKUP_SRC_START and BACKUP_SRC_END
to give more pertinent names and to be consistent with i386.
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>
|
|
Mohan Kumar M wrote:
>Hi,
>
>I am testing kexec/kdump functionality on a POWER5 box with 2.6.16-rc2 kernel.
>
>POWER5 box has 4 Mylex SCSI RAID controllers. But only 2 host controllers have
>SCSI disks connected. First controller [A] has one scsi disk and next
>controller [B] has three scsi disks.
>
>When I boot the kernel from yaboot, controller A becomes scsi0. controller B
>becomes scsi1. SCSI disk attached to controller A(scsi0) is sda.
>
>When I do kexec boot, the order of SCSI host controllers change. Controller B
>becomes scsi0 and controller A becomes scsi1 and hence disk attached to
>controller A becomes sdd and disks attached to controller B become sda, sdb and
>sdc. This results in mounting problem and kernel panics.
>
>I am attaching the partial diff between yaboot and kexec IPR initialization
>messages during boot for your reference.
>
>Why when we are doing kexec boot, the SCSI host controllers order get changed?
>It is related to device-tree ordering?
>
>Regards,
>Mohan.
>
>
>------------------------------------------------------------------------
>
>--- 2616rc2.ipr 2006-02-16 19:13:45.000000000 +0530
>+++ 2616rc2-kexec.ipr 2006-02-16 19:14:12.000000000 +0530
>@@ -1,98 +1,87 @@
> ipr: IBM Power RAID SCSI Device Driver version: 2.1.1 (November 15, 2005)
>-ipr 0000:c0:01.0: Found IOA with IRQ: 99
>-ipr 0000:c0:01.0: Starting IOA initialization sequence.
>-ipr 0000:c0:01.0: Adapter firmware version: 020A005E
>-ipr 0000:c0:01.0: IOA initialized.
>+ipr 0000:c8:01.0: Found IOA with IRQ: 103
>+ipr 0000:c8:01.0: Initializing IOA.
>+ipr 0000:c8:01.0: Starting IOA initialization sequence.
>+ipr 0000:c8:01.0: Adapter firmware version: 020A005E
>+ipr 0000:c8:01.0: IOA initialized.
> scsi0 : IBM 570B Storage Adapter
>- Vendor: IBM Model: HUS103014FL3800 Rev: RPQF
>- Type: Direct-Access ANSI SCSI revision: 04
> Vendor: IBM Model: VSBPD3E U4SCSI Rev: 4812
> Type: Enclosure ANSI SCSI revision: 02
> scsi: unknown device type 31
> Vendor: IBM Model: 570B001 Rev: 0150
> Type: Unknown ANSI SCSI revision: 00
>-PCI: Enabling device: (0002:c8:01.0), cmd 142
>-ipr 0002:c8:01.0: Found IOA with IRQ: 133
>-ipr 0002:c8:01.0: Initializing IOA.
>-ipr 0002:c8:01.0: Starting IOA initialization sequence.
>-ipr 0002:c8:01.0: Adapter firmware version: 020A005E
>-ipr 0002:c8:01.0: IOA initialized.
>+ipr 0002:c0:01.0: Found IOA with IRQ: 69
>+ipr 0002:c0:01.0: Initializing IOA.
>+ipr 0002:c0:01.0: Starting IOA initialization sequence.
>+ipr 0002:c0:01.0: Adapter firmware version: 020A005E
>+ipr 0002:c0:01.0: IOA initialized.
> scsi1 : IBM 570B Storage Adapter
>- Vendor: IBM Model: HUS103014FL3800 Rev: RPQF
>- Type: Direct-Access ANSI SCSI revision: 04
>- Vendor: IBM Model: HUS103014FL3800 Rev: RPQF
>- Type: Direct-Access ANSI SCSI revision: 04
>- Vendor: IBM Model: HUS103014FL3800 Rev: RPQF
>- Type: Direct-Access ANSI SCSI revision: 04
> Vendor: IBM Model: VSBPD3E U4SCSI Rev: 4812
> Type: Enclosure ANSI SCSI revision: 02
> scsi: unknown device type 31
> Vendor: IBM Model: 570B001 Rev: 0150
> Type: Unknown ANSI SCSI revision: 00
>-PCI: Enabling device: (0003:c0:01.0), cmd 142
>-ipr 0003:c0:01.0: Found IOA with IRQ: 69
>-ipr 0003:c0:01.0: Initializing IOA.
>-ipr 0003:c0:01.0: Starting IOA initialization sequence.
>-ipr 0003:c0:01.0: Adapter firmware version: 020A005E
>-ipr 0003:c0:01.0: IOA initialized.
>+ipr 0003:c8:01.0: Found IOA with IRQ: 133
>+ipr 0003:c8:01.0: Initializing IOA.
>+ipr 0003:c8:01.0: Starting IOA initialization sequence.
>+ipr 0003:c8:01.0: Adapter firmware version: 020A005E
>+ipr 0003:c8:01.0: IOA initialized.
> scsi2 : IBM 570B Storage Adapter
>+ Vendor: IBM Model: HUS103014FL3800 Rev: RPQF
>+ Type: Direct-Access ANSI SCSI revision: 04
>+ Vendor: IBM Model: HUS103014FL3800 Rev: RPQF
>+ Type: Direct-Access ANSI SCSI revision: 04
>+ Vendor: IBM Model: HUS103014FL3800 Rev: RPQF
>+ Type: Direct-Access ANSI SCSI revision: 04
> Vendor: IBM Model: VSBPD3E U4SCSI Rev: 4812
> Type: Enclosure ANSI SCSI revision: 02
> scsi: unknown device type 31
> Vendor: IBM Model: 570B001 Rev: 0150
> Type: Unknown ANSI SCSI revision: 00
>-PCI: Enabling device: (0005:c8:01.0), cmd 142
>-ipr 0005:c8:01.0: Found IOA with IRQ: 105
>-ipr 0005:c8:01.0: Initializing IOA.
>-ipr 0005:c8:01.0: Starting IOA initialization sequence.
>-ipr 0005:c8:01.0: Adapter firmware version: 020A005E
>-ipr 0005:c8:01.0: IOA initialized.
>+ipr 0005:c0:01.0: Found IOA with IRQ: 99
>+ipr 0005:c0:01.0: Initializing IOA.
>+ipr 0005:c0:01.0: Starting IOA initialization sequence.
>+ipr 0005:c0:01.0: Adapter firmware version: 020A005E
>+ipr 0005:c0:01.0: IOA initialized.
> scsi3 : IBM 570B Storage Adapter
>+ Vendor: IBM Model: HUS103014FL3800 Rev: RPQF
>+ Type: Direct-Access ANSI SCSI revision: 04
> Vendor: IBM Model: VSBPD3E U4SCSI Rev: 4812
> Type: Enclosure ANSI SCSI revision: 02
> scsi: unknown device type 31
> Vendor: IBM Model: 570B001 Rev: 0150
> Type: Unknown ANSI SCSI revision: 00
>-vio_register_driver: driver ibmvscsi registering
> st: Version 20050830, fixed bufsize 32768, s/g segs 256
> SCSI device sda: 286748000 512-byte hdwr sectors (146815 MB)
> sda: Write Protect is off
>-sda: Mode Sense: d3 00 10 08
> SCSI device sda: drive cache: write through w/ FUA
> SCSI device sda: 286748000 512-byte hdwr sectors (146815 MB)
> sda: Write Protect is off
>-sda: Mode Sense: d3 00 10 08
> SCSI device sda: drive cache: write through w/ FUA
>- sda: sda1 sda2 sda3 sda4 < sda5 >
>-sd 0:0:5:0: Attached scsi disk sda
>+ sda: unknown partition table
>+sd 2:0:3:0: Attached scsi disk sda
> SCSI device sdb: 286748000 512-byte hdwr sectors (146815 MB)
> sdb: Write Protect is off
>-sdb: Mode Sense: d3 00 10 08
> SCSI device sdb: drive cache: write through w/ FUA
> SCSI device sdb: 286748000 512-byte hdwr sectors (146815 MB)
> sdb: Write Protect is off
>-sdb: Mode Sense: d3 00 10 08
> SCSI device sdb: drive cache: write through w/ FUA
> sdb: unknown partition table
>-sd 1:0:3:0: Attached scsi disk sdb
>+sd 2:0:4:0: Attached scsi disk sdb
> SCSI device sdc: 286748000 512-byte hdwr sectors (146815 MB)
> sdc: Write Protect is off
>-sdc: Mode Sense: d3 00 10 08
> SCSI device sdc: drive cache: write through w/ FUA
> SCSI device sdc: 286748000 512-byte hdwr sectors (146815 MB)
> sdc: Write Protect is off
>-sdc: Mode Sense: d3 00 10 08
> SCSI device sdc: drive cache: write through w/ FUA
>- sdc: unknown partition table
>-sd 1:0:4:0: Attached scsi disk sdc
>+ sdc: sdc1 sdc2 sdc3 sdc4
>+sd 2:0:5:0: Attached scsi disk sdc
> SCSI device sdd: 286748000 512-byte hdwr sectors (146815 MB)
> sdd: Write Protect is off
>-sdd: Mode Sense: d3 00 10 08
> SCSI device sdd: drive cache: write through w/ FUA
> SCSI device sdd: 286748000 512-byte hdwr sectors (146815 MB)
> sdd: Write Protect is off
>-sdd: Mode Sense: d3 00 10 08
> SCSI device sdd: drive cache: write through w/ FUA
>- sdd: sdd1 sdd2 sdd3 sdd4
>-sd 1:0:5:0: Attached scsi disk sdd
>+ sdd: sdd1 sdd2 sdd3 sdd4 < sdd5 >
>+sd 3:0:5:0: Attached scsi disk sdd
>
>
>
Mohan,
Attaching a patch which should fix your device ordering issue.
In kexec-tools, the device-tree directory entries will be sorted in the
ascending order (assuming, even in the first kernel, PCI device entries
in /proc/device-tree are created in the same order when PCI probe
happens. I will confirm later). Also added set_proper_root_device_name()
to get the proper device name from /dev/disk/by_id such that persistent
partition name will be passed. But, kdump boot is not successful and
failed when the mount root partition happens (mount -o ro /dev/<name>).
Hence commented the code at this moment and will be looking into it
later. However, this patch should fix your issue since we are
rearranging the device-tree entries. This patch needs some more testing
and let me know if it works.
I tested on JS20 where ethernet device names getting changed in kdump
boot due to the device-tree ordering issue. With this fix, getting same
ethernet names even in the kdump boot. However, I could not test the
SCSI issue the you found since my system is having only one disk.
However, tested on my P5 box to make sure that it does not break on my
P5 box.
Thanks
Haren
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
Mohan Kumar M wrote:
>Hi Haren,
>
>In one of the mails you have mentioned that you have a patch to support
>--initrd option for ppc64 kexec tools.
>
>Can you please send the patch to us so that it can be included in the
>next consolidated kdump (kdump7) patch and posted to lse website?
>
>Regards,
>Mohan.
>
>
>
>
Mohan,
It is a simple fix - just alias to RAMDISK.
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
On Thu, Jul 27, 2006 at 12:32:56PM -0600, Eric W. Biederman wrote:
..
> - Why x86_64 arch_options is non-static.
I guess at the begining x86_64 had support for elf32 core headers and
arch_option was used out side kexec-x86_64.c also. But later this elf32
support was removed but arch_option continued to be extern.
The appended patch should correct it.
Thanks
Maneesh
o x86_64 arch_option is not used anywhere else, so make it "static"
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
Hi,
Attached is a patch which fills real_mode info correctly in case of
vesafb being active, so the new kernel comes up with a working
framebuffer console.
cheers,
Gerd
|
|
o Fix the logic to load a the files of type ET_DYN. Helpful in loading
the relocatable kernel to a different address than the address
executable is compiled for.
|
|
|
|
|
|
|
|
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
|
|
This patches changes argument parsing for ppc64 for the command "kexec -p".
We now ignore the args-linux option. This allows for more consistency
of the command line between archs. Intel platforms
use the --args-linux option ppc64 dose not. With this change the same
command-line can used now on both system types.
Signed-off-by: David Wilder <dwilder@us.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
|
