| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
I'd like to submit a patch to kexec that addresses a serious problem
with kdump on the Unisys ES7000/600 system. We initially encountered
this issue on SUSE's SLES 10 beta distributions.
On the ES7000/600, the ACPI data is located in the 3GB range, and above
that is an ACPI NVS region. The problem is that kexec, when loading a
dump kernel, does not include the ACPI NVS region in the memory map it
provides to the dump kernel. This causes a kernel panic early in the
dump kernel's boot process:
Bootdata ok (command line is root=/dev/sda2 showopts console=tty0
console=ttyS0,115200n8 earlyprintk=serial,ttyS0,115200n8 memmap=exactmap
memmap=640K@0K memmap=3296K@16384K memmap=61599K@20321K
elfcorehdr=20320K memmap=408K#3144128K)
Linux version 2.6.16.14-6-kdump (geeko@buildhost) (gcc version 4.1.0
(SUSE Linux)) #1 Tue May 9 12:09:06 UTC 2006
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000100 - 000000000009e400 (usable)
BIOS-e820: 000000000009e400 - 00000000000a0000 (reserved)
BIOS-e820: 0000000000100000 - 00000000bfe70000 (usable)
BIOS-e820: 00000000bfe70000 - 00000000bfed6000 (ACPI data)
BIOS-e820: 00000000bfed6000 - 00000000bff00000 (ACPI NVS)
BIOS-e820: 00000000bff00000 - 00000000e8000000 (usable)
BIOS-e820: 00000000f8000000 - 00000000fec00000 (reserved)
BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000810000000 (usable)
user-defined physical RAM map:
user: 0000000000000000 - 00000000000a0000 (usable)
user: 0000000001000000 - 0000000001338000 (usable)
user: 00000000013d8400 - 0000000005000000 (usable)
user: 00000000bfe70000 - 00000000bfed6000 (ACPI data)
kernel direct mapping tables up to bfed6000 @ 8000-8000
PANIC: early exception rip 10 error ffffffff8131433b cr2 2b0ed2682180
Call Trace: <ffffffff8131433b>{reserve_bootmem_core+78}
<ffffffff81312b52>{reserve_bootmem_generic+19}
<ffffffff81310ea7>{smp_scan_config+145}
<ffffffff81310f02>{find_intel_smp+54}
<ffffffff8130b6af>{setup_arch+2158}
<ffffffff813045de>{start_kernel+42} <ffffffff81304259>{_sinittext
+601}
RIP 0x10
We have determined that the cause of this panic is that the kernel
attempts to reserve the ACPI NVS region, which is defined by a pointer
stored in the ACPI data region, but cannot reserve memory above the
maximum usable memory limit. The kernel determines the maximum usable
memory by taking the highest address of usable memory specified in the
memory map; so it is setting the value to 0x5000000, as listed in the
map, then attempting to reserve memory above 0xbfed6000, which triggers
a panic.
By modifying kexec to also pass the ACPI NVS region as reserved memory
in the memory map, the kernel will not panic. We have tested this on
both the ES7000/600 and a Dell server system which exhibited the same
problem and it worked on both. The attached patch file contains the
changes that we made, and applies to kexec-tools-1.101.
-- Ben
Signed-off-by: Benjamin Romer <benjamin.romer@unisys.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
I had to look through the source to remember what these are one too many
times.
Patch below is against Maneesh's kexec-tools-1.101-kdump8 patches.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
If the first kernel command line or the --command-line parameter doesn't
have a 'root=', we seg fault on ppc64.
Patch below is against Maneesh's kexec-tools-1.101-kdump8 patches.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
I posted this man page on May 11. It was pointed out to me that the
something had trashed the nroff formating.
This is a reposting of the man page. (not a patch, just the man page).
Thanks
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch makes kexec tool use /proc/iomem to determine memory layout
on ia64. This is based upon code written by Zou Nan hai.
Signed-off-by: Khalid Aziz <khalid.aziz@hp.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
- In recent kernels, the plaform property is removed from the /proc/device-tree.This property is used to determine whether the platform is LPAR or non-lpar, and reads htab-* and tce-* properties based on the platform. Fixed this issue such that read these properties if exists, otherwise continue instead of exiting with an error message.
Signed-off-by: David Wilder <dwilder@us.ibm.com>
Signed-off-by: Haren Myneni <haren@us.ibm.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>
|
|
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>
|
|
Cleanup the warnings generated in GCC 4.1.0 compilation of kexec-tools.
This patch is created on top of the following level of
kexec-tools:
- kexec-tools-1.101.tar.gz (from eric biederman's site or
from lse site)
- kexec-tools-1.101-kdump6.patch (consolidated patch posted
on
http://lse.sourceforge.net/kdump/patches/1.101-kdump6/kexec-tools-1.101-kdump6.patch)
Review and suggestions are welcome.
Note:
Resending the patch since its not delivered to both fastboot and
linuxppc64-dev mailing list.
Regards,
Mohan.
Signed-off-by: Mohan <mohan@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
Hi,
Latest kexec tools for PPC64 with purgatory patch
(ppc64-kdump-purgatory-backup-support.patch) was not working with gcc
version 4.1.0 due to the change in object file generation.
Here is the patch to fix this issue.
This patch is created on top of the following level of
kexec-tools:
- kexec-tools-1.101.tar.gz (from eric biederman's site or
from lse site)
- kexec-tools-1.101-kdump6.patch (consolidated patch posted
on
http://lse.sourceforge.net/kdump/patches/1.101-kdump6/kexec-tools-1.101-kdump6.patch)
Review and suggestions are welcome.
Note:
Resending the patch since its not delivered to both fastboot and
linuxppc64-dev mailing list.
Regards,
Mohan.
GCC 4.1.0 (for ppc) generates object files without
dot-symbols. This new format breaks subroutine calls using
assembly language mnemonic. This patch restores the old
convention, i.e produce the object files with dot-symbols
using the flag "-mcall-aixdesc".
Note:
Earlier versions of gcc compilers generated object files
with dot-symbols.
Signed-off-by: Mohan <mohan@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
Hi Haren,
I found out that 'continue' statement is missing in kexec-elf-rel.c.
So I am sending a patch which includes 'continue' statement for
STN_UNDEF condition.
I tried with this patch and I am able to do ./kexec -p and not getting
any relocation error, but kernel OOPS.
Even kexec -l and kexec -e also not working. I am getting "kexec:
waiting for cpu 1 (physical 1) to go down" message and kernel did not
boot.
I used /home/hbabu/2.6.15-mm1/linux-2.6.15-mm1 for testing purpose.
Initrd image is not built from linux-2.6.15-mm1, I used existing initrd
image (initrd-2.6.15-rc5cel.img).
As I am having fever, I may not be able to come office tomorrow. Sorry
for the inconvenience.
Regards,
Mohan.
|
|
o An additional PT_LOAD type ELF header was being generated for ACPI tables
region. ELF headers should be generated only for memory type RAM_RANGE.
This was leading to bloated /proc/vmcore file size.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
|
|
Olaf,
The attached patch will fix the problem that you reported -
"unrecognized architecture powerpc64" when building kexec-tools.
Even though the configure script can recognize powerpc64, getting
unrecognized architecture "powerpc64" when we run "autoreconf .." tool
since it modifies the configure script based on configure.ac script. But
the powerpc64 support is missing in configure.ac. Similarly for s390.
Thanks
Haren
Signed-off-by: Haren Myneni <haren@us.ibm.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>
|
|
This patch implements the elf core header generation
- creates elf core headers as 64 bit elf code headers
- includes required #defines
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch provides the basic functionality for
loading crash dump segment and required features.
- Code for loading the crashdump segments
- It modifies the crash dump cmdline parameter to
add the new parameters, elfcorehdr and savemaxmem
- other miscellaneous cleanups and re-ordering
of some existing code in kexec-elf-ppc64.c
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch provides the support for setting up te various
memory regions required for crashdump functionality.
- limit mem_min and mem_max to crash_base and crash_end
- create usable_memory_regions for use by second kernel
- exclude regions not to be dumped by second kernel.
For example - tce-table and crash reserved region
- include rtas region in crash_memory_ranges if it falls
within crash reserved region, as we want to obtain the
rtas image in the dump core file.
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Haren Myneni <hbabu@us.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This patch provides the extra functionality and features in
the flattened device-tree that is required for crashdump
functionality.
- create add_usable_mem_property in device-tree which is
used by the second kernel for booting with restricted
memory. This provides similar feature as the
memmap= option on other archs
- move initrd creation/modification code to putnode
- add code to prepare correct commandline for bootargs.
If "root=" option is not specified in user cmdline,
add it from existing bootargs
- include mem_rgns_t definition in kexec-ppc64.h. Move
initrd variables out to .c file
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Haren Myneni <hbabu@us.ibm.com>
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
Fix the input parameters for get_memory_ranges and arch_compat_trampoline
keeping in line with the function prototypes defined in kexec/kexec.h. Also
changed variable references in /proc/device-tree
- modified the function parameters for get_memory_ranges and
arch_compat_trampoline
- fixed the names for kernel_end, htab_base and htab_size, in
line with the kernel variable names for the same
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
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 Patch to initialize ACPI in second kernel in kexec on panic. x86_64 kernel
assumes ACPI tables to be directly mapped, unlike i386, where few fix
virtual addresses are reserved for mapping ACPI tables.
o This patch passes the location of ACPI tables to new kernel with the
help of memmap= options. This ensures that direct mappings are created
for ACPI tables in second kernel.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o In some cases, the number of segments on kexec load exceeds
the existing cap of 8. This patch increases the KEXEC_MAX_SEGMENTS
from 8 to 16.
Signed-off-by: Rachita Kothiyal <rachita@in.ibm.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o Now kernel does per cpu dynamic allocation of memory for storing per cpu
register states and exports pointers to those memory buffers through
"/sys/devices/system/cpu/cpuX/crash_notes". This patch introduces the
support for the same.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o Calls prepare_crash_memory_elf64_headers to create elfcore headers for
each memory chunck.
o Creates a segment for storing elf headers.
o Create a backup region segment to store backup data.
Signed-off-by:Murali M Chakravarthy <muralim@in.ibm.com>
Signed-off-by: Vivek Goyal <vgoyal@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>
|
|
o Modifying the command line agruments to append memmap= and elfcore=
options for the capture kernel.
o Introducing get_crash_memory_ranges to traverse through /proc/iomem
which will be useful when perparing elf-headers as we have to prepare
elf headers for each chunck.
Signed-off-by: Murali M Chakravarthy <muralim@in.ibm.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o This patch is to generate the elf-core headers for x86_64.
Not sure whether to retain the options --elf32 and --elf64
but as of now, we port them to x86_64 also.
o We conditionally fill up the vaddr in the phdr as we got
two linearly memory mapped regions in x86_64 unlike i386.
To get the virtual address, we make of use of __START_KERNEL_map
for the frist 0 to 40MB and for others we make use of PAGE_OFFSET.
o Support for per cpu dynamic allocation of crash notes.
Signed-off-by: Murali M Chakravarthy <muralim@in.ibm.com>
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o Add support for kexec tools for x86_64 to read the /proc/iomem to
get the Crash Kernel memory.
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>
|
|
Hi Eric,
I just realized that my recent patches of kdump for i386 broke kexec-tools
compilation on x86-64 machine. Here is a patch attached to fix the problem.
Thanks
Vivek
o This patch fixes a x86_64 compilation failure issue. Recent patches
changed the function signature of funciton setup_linux_system_parameters().
Additional parameter kexec_flags is being passed now. This patch makes
sure that this function is called with appropriate parameters.
o x86_64 code also compiles i386 elf32 vmlinux loader code. i386 elf loader
code inturn uses crashdump code (crashdump-x86.c). Modified x86_64
makefile to compile crashdump-x86.c as well.
o phdr->vaddr size type unsigened int. Did minor modificaition to make sure
it compiles without warnings in x86_64 context.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
|
|
o Problem: If --elf32-core-headers option is specified after --initrd option
then initrd effectively becomes null and capture kernel does not see
any initrd.
o This problem happens because OPT_ELF32_CORE and OPT_RAMDISK are having
same value. This problem got introduced when option --elf32-core-headers
was moved from loader option to architecture dependent option.
o This patch needs to be applied after applying consolidated kdump patch.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
This adds the device tree blob option to kexec. This option is useful
if you want to generate you own device tree blobs. Also, you can now
do something like:
dtc -I fs /proc/device-tree -O dts -f > dt.dts
<insert some massaging[1] of dt.dts>
dtc -I dts dt.dts -O dtb -f > dt.dtb
kexec -l vmlinux --devicetreeblob=dt.dtb
taskset 1 kexec -e
And get a similar results to just running kexec normally.
Also, the --devicetreeblob option won't work with the --initrd option.
1. massaging includes (from memory)
- removal of htab entries
- ensure CPU are ordered from 0 onwards
- adding of reserve map entries (need to create fake last entry for
the blob which kexec will patch after loading)
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
Patch cleans up how the reserve memory maps entry for the device tree
are modified. Shouldn't change any functionality.
Signed-off-by: Michael Neuling <mikey@neuling.org>
o Adjusted minor rejects manually in the patch from Michael Neuling
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o This fixes the -m64 flag setting in configure script to avoid -m64 flags
for other architectures.
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
Hello,
The basic_kexec_tools_for_ppc64 had a few issues with variable
redeclarations that was throwing some compile warnings on GCC 4, though I
was not seeing some of those on my GCC ver 3 on SLES9. This is a revised
patch, which cleans up the errors and this should compile ok on ppc64. I also
cleaned up a few other compile warnings that were showing up on my system.
Thanks to Michael Neuling for pointing this out.
Thanks and Regards,
Sharada
This provides the basic functionality in kexec-elf-ppc64.c to load the various
segments required for kexec-tools on ppc64. It also adds ppc64 arch support
in build scripts and cleans up some misc error in member deferencing to allow
the build to succeed.
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Mohan Kumar <mohan@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>
|
|
This patch adds functionality to obtain the base memory ranges from
/proc/device-tree/memory@xxx nodes and exclude ranges not valid for
passing into kexec-tools. It adds the functionality of the get_memory_ranges
function.
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
Hello,
The basic_kexec_tools_for_ppc64 had a few issues with variable
redeclarations that was throwing some compile warnings on GCC 4, though I
was not seeing some of those on my GCC ver 3 on SLES9. This is a revised
patch, which cleans up the errors and this should compile ok on ppc64. I also
cleaned up a few other compile warnings that were showing up on my system.
Thanks to Michael Neuling for pointing this out.
Thanks and Regards,
Sharada
This provides the basic functionality in kexec-elf-ppc64.c to load the various
segments required for kexec-tools on ppc64. It also adds ppc64 arch support
in build scripts and cleans up some misc error in member deferencing to allow
the build to succeed.
Signed-off-by: R Sharada <sharada@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
|
|
o This is temporary hack patch to avoid any kexec segment being put in
small memory hole between data and bss segments (Valid only for some older
ld versions). This data is stomped by new kernel as kernel somehow thinks
it to be part of bss.
o This should be removed once the problem is fixed at kernel level.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Maneesh Soni <maneesh@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 For i386, Physical memory upto 896MB is linearly mapped. Hence virtual
addresses for linearly mapped region are known.
o This patch sets the appropriate virtual addresses in core headers for
linearly mapped region.
o Enables gdb to debug linearly mapped region without any special user space
utility. Otherwise, capture tools first need to analyze the core image (Read
page tables and/or vm areas) and determine virtual addresses for memory
chunks and then regenerate the elf headers suitable for debugging with gdb.
o Some cases like 4G/4G split deviate from 896MB linearly mapped region and
might have different value for PAGE_OFFSET. Probably its a good idea to
export the linear region from kernel and use that instead of hard coding it.
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>
|
|
A good first attempt but it conflicts with other work :(
This reverts commit caa2e42897cb8cb00c7040b9133e8b740809241c.
|
|
|
|
|
|
|
