| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
There are two memory_ranges arrays declared in the IA64 kexec code.
One in kexec-ia64.c and the other one in crashdump-ia64.c.
They currently were allocated as a hard-coded size of array. Since
SN systems may scale to hunders of nodes and each node may contain
up to 12 DIMMs, the hard-coded size of 1024 is not enough for very
large systems.
The size of either array can not be greater than the number of
entries in /proc/iomem, which is saved as "max_memory_ranges"
and is used to dynamically allocate the two arrays.
Signed-off-by: Jay Lan <jlan@sgi.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>
|
|
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 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>
|
|
- Initial import into git
- initial nbi image formage support
- ppc32 initial register setting fixes.
- gzipped multiboot file support
|
