|
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>
|
