Re: kexec -p loads

Re: kexec -p loads

[Vivek Goyal]

On Tue, Aug 26, 2008 at 05:13:27PM -0500, Cliff Wickman wrote:
> 
> Hi Vivek,
> 
> I'm having trouble getting a system kernel to load a kdump kernel.
> 
> These are 2.6.26.2 kernels on an x86_64.
> The kdump kernel has no modules.
> The kdump kernel area is reserved as 64M@16M.
> 
> This is the way I try to load it:
> 
> /usr/local/sbin/kexec -p /boot/vmlinux-cpwcomm --args-linux --append="root=/dev/sda3 1 irqpoll maxcpus=1 reset_devices"
> 
> This works with -l.  But with -p the kernel objects to the 2 lowest
> segments, at 0x1000 and 0xa000 which I presume are the startup code
> and arguments.
> 

CCing to kexec mailing list.

Few questions.

- What version of kexec-tools are you using?
- Can you please provide output of /proc/iomem. (With crash kernel memory
  reserved).
- Looks like you have compiled your kernel for physical address 16MB?
  (CONFIG_PHYSICAL_START=0x1000000)
- Can you also try loading relocatable bzImage, instead of vmlinux and see
  what happens.
  

> I have this debugging output from my kexec:
> 
> cpw: elf_x86_64_load returning entry:0x1550
> cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550
> kexec_load: entry = 0x1550 flags = 1
> nr_segments = 6
> segment[0].buf   = 0x5237a0
> segment[0].bufsz = 7100
> segment[0].mem   = 0x1000
> segment[0].memsz = 9000
> 
> segment[1].buf   = 0x52aaf0
> segment[1].bufsz = 1000
> segment[1].mem   = 0xa000
> segment[1].memsz = 1000
> 

I think above two segments are not being loaded at right place. Looks like
kexec-tools decided to load first one at physical address 0x1000 and other at
physical address 0xa000. For crash kernel this is not right. It should
come out of reserved memory area and that's why you are encountering the
error.


For crash kernels, kexec-tools sets the value of mem-min and mem-max in
such a manner that it is with-in reserved memory area so that any memory
allocation in locate_hole() is done with-in reserved area and not outside
it.

In your case looks like something went wrong. Either memory area was not
reserved properly or value of mem-min, mem-max was not set properly etc.

Can you please paste the output of /proc/iomem and also do some
kexec-tools debugging. Especially value of mem-max and mem-min inside
locate_hole() function.

Thanks
Vivek

 
> segment[2].buf   = 0x7f9bd8461010
> segment[2].bufsz = 224668
> segment[2].mem   = 0x1000000
> segment[2].memsz = 225000
> 
> segment[3].buf   = 0x7f9bd8686010
> segment[3].bufsz = 75508
> segment[3].mem   = 0x1225000
> segment[3].memsz = 76000
> 
> segment[4].buf   = 0x7f9bd8761010
> segment[4].bufsz = c08
> segment[4].mem   = 0x129b000
> segment[4].memsz = 1000
> 
> segment[5].buf   = 0x7f9bd87fd010
> segment[5].bufsz = 30004
> segment[5].mem   = 0x129c000
> segment[5].memsz = c2000
> kexec_load failed: Cannot assign requested address
> 
> 
> And I have some debugging in the system kernel:
> 
> cleopatra1:/tmp/cpw # dmesg | tail
> 
> cpw: -p, call kimage_crash_alloc
> cpw: kimage_crash_alloc bad entry point 0x1550:0x1000000 0x1550:0x4ffffff
> cpw: kimage_crash_alloc segment 0: 0x1000-0x9fff
> cpw: kimage_crash_alloc pta EADDRNOTAVAIL 0x1000:0x1000000  0x9fff:0x4ffffff
> cpw: kimage_crash_alloc segment 1: 0xa000-0xafff
> cpw: kimage_crash_alloc pta EADDRNOTAVAIL 0xa000:0x1000000  0xafff:0x4ffffff
> cpw: kimage_crash_alloc segment 2: 0x1000000-0x1224fff
> cpw: kimage_crash_alloc segment 3: 0x1225000-0x129afff
> cpw: kimage_crash_alloc segment 4: 0x129b000-0x129bfff
> cpw: kimage_crash_alloc segment 5: 0x129c000-0x135dfff
> 
> The code that insists that the entry point must be within 64M@16M, and
> that every segment must also be in that range, seems to be old code.
> 
> I don't understand.
> Is kexec generating bad segments?  Or am I mis-using something?
> Can you tell from the above?
> 
> Thanks.
> -Cliff

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec -p loads

[Bernhard Walle]

* Vivek Goyal [2008-08-27 09:39]:
>
> On Tue, Aug 26, 2008 at 05:13:27PM -0500, Cliff Wickman wrote:
> > 
> > Hi Vivek,
> > 
> > I'm having trouble getting a system kernel to load a kdump kernel.
> > 
> > These are 2.6.26.2 kernels on an x86_64.
> > The kdump kernel has no modules.
> > The kdump kernel area is reserved as 64M@16M.
> > 
> > This is the way I try to load it:
> > 
> > /usr/local/sbin/kexec -p /boot/vmlinux-cpwcomm --args-linux --append="root=/dev/sda3 1 irqpoll maxcpus=1 reset_devices"
> > 
> > This works with -l.  But with -p the kernel objects to the 2 lowest
> > segments, at 0x1000 and 0xa000 which I presume are the startup code
> > and arguments.
> > 
> 
> CCing to kexec mailing list.
> 
> Few questions.
> 
> - What version of kexec-tools are you using?
> - Can you please provide output of /proc/iomem. (With crash kernel memory
>   reserved).
> - Looks like you have compiled your kernel for physical address 16MB?
>   (CONFIG_PHYSICAL_START=0x1000000)
> - Can you also try loading relocatable bzImage, instead of vmlinux and see
>   what happens.
>   
> 
> > I have this debugging output from my kexec:
> > 
> > cpw: elf_x86_64_load returning entry:0x1550
> > cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550
> > kexec_load: entry = 0x1550 flags = 1
> > nr_segments = 6
> > segment[0].buf   = 0x5237a0
> > segment[0].bufsz = 7100
> > segment[0].mem   = 0x1000
> > segment[0].memsz = 9000
> > 
> > segment[1].buf   = 0x52aaf0
> > segment[1].bufsz = 1000
> > segment[1].mem   = 0xa000
> > segment[1].memsz = 1000
> > 
> 
> I think above two segments are not being loaded at right place. Looks like
> kexec-tools decided to load first one at physical address 0x1000 and other at
> physical address 0xa000. For crash kernel this is not right. It should
> come out of reserved memory area and that's why you are encountering the
> error.

Relocatability in ELF image never worked on x86_64 because of GDB but
(so the binary was marked as ET_EXEC instead of ET_DYN).

You have to use bzImage for kdump in any case.



Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec -p loads

[Vivek Goyal]

On Wed, Aug 27, 2008 at 03:43:33PM +0200, Bernhard Walle wrote:
> * Vivek Goyal [2008-08-27 09:39]:
> >
> > On Tue, Aug 26, 2008 at 05:13:27PM -0500, Cliff Wickman wrote:
> > > 
> > > Hi Vivek,
> > > 
> > > I'm having trouble getting a system kernel to load a kdump kernel.
> > > 
> > > These are 2.6.26.2 kernels on an x86_64.
> > > The kdump kernel has no modules.
> > > The kdump kernel area is reserved as 64M@16M.
> > > 
> > > This is the way I try to load it:
> > > 
> > > /usr/local/sbin/kexec -p /boot/vmlinux-cpwcomm --args-linux --append="root=/dev/sda3 1 irqpoll maxcpus=1 reset_devices"
> > > 
> > > This works with -l.  But with -p the kernel objects to the 2 lowest
> > > segments, at 0x1000 and 0xa000 which I presume are the startup code
> > > and arguments.
> > > 
> > 
> > CCing to kexec mailing list.
> > 
> > Few questions.
> > 
> > - What version of kexec-tools are you using?
> > - Can you please provide output of /proc/iomem. (With crash kernel memory
> >   reserved).
> > - Looks like you have compiled your kernel for physical address 16MB?
> >   (CONFIG_PHYSICAL_START=0x1000000)
> > - Can you also try loading relocatable bzImage, instead of vmlinux and see
> >   what happens.
> >   
> > 
> > > I have this debugging output from my kexec:
> > > 
> > > cpw: elf_x86_64_load returning entry:0x1550
> > > cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550
> > > kexec_load: entry = 0x1550 flags = 1
> > > nr_segments = 6
> > > segment[0].buf   = 0x5237a0
> > > segment[0].bufsz = 7100
> > > segment[0].mem   = 0x1000
> > > segment[0].memsz = 9000
> > > 
> > > segment[1].buf   = 0x52aaf0
> > > segment[1].bufsz = 1000
> > > segment[1].mem   = 0xa000
> > > segment[1].memsz = 1000
> > > 
> > 
> > I think above two segments are not being loaded at right place. Looks like
> > kexec-tools decided to load first one at physical address 0x1000 and other at
> > physical address 0xa000. For crash kernel this is not right. It should
> > come out of reserved memory area and that's why you are encountering the
> > error.
> 
> Relocatability in ELF image never worked on x86_64 because of GDB but
> (so the binary was marked as ET_EXEC instead of ET_DYN).
> 
> You have to use bzImage for kdump in any case.
> 

True that vmlinux is not relocatable. But one can always compile the
vmlinux for a fixed physical address (Address in reserved region) and then
use it?  In this case his vmlinux seems to have been compiled for physical
address 16MB. Which should be usable if there is a reserved memory region
at 16MB.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec -p loads

[Bernhard Walle]

* Vivek Goyal [2008-08-27 11:28]:
> > > 
> > > > I have this debugging output from my kexec:
> > > > 
> > > > cpw: elf_x86_64_load returning entry:0x1550
> > > > cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550
> > > > kexec_load: entry = 0x1550 flags = 1
> > > > nr_segments = 6
> > > > segment[0].buf   = 0x5237a0
> > > > segment[0].bufsz = 7100
> > > > segment[0].mem   = 0x1000
> > > > segment[0].memsz = 9000
> > > > 
> > > > segment[1].buf   = 0x52aaf0
> > > > segment[1].bufsz = 1000
> > > > segment[1].mem   = 0xa000
> > > > segment[1].memsz = 1000
> > > > 
> > > 
> > > I think above two segments are not being loaded at right place. Looks like
> > > kexec-tools decided to load first one at physical address 0x1000 and other at
> > > physical address 0xa000. For crash kernel this is not right. It should
> > > come out of reserved memory area and that's why you are encountering the
> > > error.
> > 
> > Relocatability in ELF image never worked on x86_64 because of GDB but
> > (so the binary was marked as ET_EXEC instead of ET_DYN).
> > 
> > You have to use bzImage for kdump in any case.
> 
> True that vmlinux is not relocatable. But one can always compile the
> vmlinux for a fixed physical address (Address in reserved region) and then
> use it?  In this case his vmlinux seems to have been compiled for physical
> address 16MB. Which should be usable if there is a reserved memory region
> at 16MB.

Of course, that's true. I just thought when Cliff uses the same kernel
for "kexec -l" and "kexec -p", then it's the "normal" kernel. But I
didn't calculate the numbers.



Bernhard
-- 
Bernhard Walle, SUSE Linux Products GmbH, Architecture Development

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec -p loads

[Vivek Goyal]

On Wed, Aug 27, 2008 at 05:30:35PM +0200, Bernhard Walle wrote:
> * Vivek Goyal [2008-08-27 11:28]:
> > > > 
> > > > > I have this debugging output from my kexec:
> > > > > 
> > > > > cpw: elf_x86_64_load returning entry:0x1550
> > > > > cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550
> > > > > kexec_load: entry = 0x1550 flags = 1
> > > > > nr_segments = 6
> > > > > segment[0].buf   = 0x5237a0
> > > > > segment[0].bufsz = 7100
> > > > > segment[0].mem   = 0x1000
> > > > > segment[0].memsz = 9000
> > > > > 
> > > > > segment[1].buf   = 0x52aaf0
> > > > > segment[1].bufsz = 1000
> > > > > segment[1].mem   = 0xa000
> > > > > segment[1].memsz = 1000
> > > > > 
> > > > 
> > > > I think above two segments are not being loaded at right place. Looks like
> > > > kexec-tools decided to load first one at physical address 0x1000 and other at
> > > > physical address 0xa000. For crash kernel this is not right. It should
> > > > come out of reserved memory area and that's why you are encountering the
> > > > error.
> > > 
> > > Relocatability in ELF image never worked on x86_64 because of GDB but
> > > (so the binary was marked as ET_EXEC instead of ET_DYN).
> > > 
> > > You have to use bzImage for kdump in any case.
> > 
> > True that vmlinux is not relocatable. But one can always compile the
> > vmlinux for a fixed physical address (Address in reserved region) and then
> > use it?  In this case his vmlinux seems to have been compiled for physical
> > address 16MB. Which should be usable if there is a reserved memory region
> > at 16MB.
> 
> Of course, that's true. I just thought when Cliff uses the same kernel
> for "kexec -l" and "kexec -p", then it's the "normal" kernel. But I
> didn't calculate the numbers.
> 
> 

Its litle tricky. I think one can always do both "kexec -l" and "kexec -p"
on a vmlinux which has been built for kdump (for reserved region).

But one can not do "kexec -p" on normal kernel vmlinux.

So I am assuming that Cliff is running into first case. But he can tell
us more. 

Cliff, is it same vmlinux which you use for first kernel or a different
vmlinux compiled for dump capture.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec -p loads

[Cliff Wickman]

On Wed, Aug 27, 2008 at 11:36:22AM -0400, Vivek Goyal wrote:
> On Wed, Aug 27, 2008 at 05:30:35PM +0200, Bernhard Walle wrote:
> > * Vivek Goyal [2008-08-27 11:28]:
> > > > > 
> > > > > > I have this debugging output from my kexec:
> > > > > > 
> > > > > > cpw: elf_x86_64_load returning entry:0x1550
> > > > > > cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550
> > > > > > kexec_load: entry = 0x1550 flags = 1
> > > > > > nr_segments = 6
> > > > > > segment[0].buf   = 0x5237a0
> > > > > > segment[0].bufsz = 7100
> > > > > > segment[0].mem   = 0x1000
> > > > > > segment[0].memsz = 9000
> > > > > > 
> > > > > > segment[1].buf   = 0x52aaf0
> > > > > > segment[1].bufsz = 1000
> > > > > > segment[1].mem   = 0xa000
> > > > > > segment[1].memsz = 1000
> > > > > > 
> > > > > 
> > > > > I think above two segments are not being loaded at right place. Looks like
> > > > > kexec-tools decided to load first one at physical address 0x1000 and other at
> > > > > physical address 0xa000. For crash kernel this is not right. It should
> > > > > come out of reserved memory area and that's why you are encountering the
> > > > > error.
> > > > 
> > > > Relocatability in ELF image never worked on x86_64 because of GDB but
> > > > (so the binary was marked as ET_EXEC instead of ET_DYN).
> > > > 
> > > > You have to use bzImage for kdump in any case.
> > > 
> > > True that vmlinux is not relocatable. But one can always compile the
> > > vmlinux for a fixed physical address (Address in reserved region) and then
> > > use it?  In this case his vmlinux seems to have been compiled for physical
> > > address 16MB. Which should be usable if there is a reserved memory region
> > > at 16MB.
> > 
> > Of course, that's true. I just thought when Cliff uses the same kernel
> > for "kexec -l" and "kexec -p", then it's the "normal" kernel. But I
> > didn't calculate the numbers.
> > 
> > 
> 
> Its litle tricky. I think one can always do both "kexec -l" and "kexec -p"
> on a vmlinux which has been built for kdump (for reserved region).
> 
> But one can not do "kexec -p" on normal kernel vmlinux.
> 
> So I am assuming that Cliff is running into first case. But he can tell
> us more. 
> 
> Cliff, is it same vmlinux which you use for first kernel or a different
> vmlinux compiled for dump capture.

Sorry for the lag.  I was working on the problem and not watching my mail.

I'm using two different kernels.
The kdump vmlinux is compiled with
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x1000000

I'm using  kexec-tools-1.101

Here's the head of iomem:
cleopatra1:/tmp/cpw # cat /proc/iomem
00000000-0009bbff : System RAM
0009bc00-0009ffff : reserved
000d0000-000d7fff : reserved
000e4000-000fffff : reserved
00100000-cff5ffff : System RAM
  00200000-005c6448 : Kernel code
  005c6449-007da867 : Kernel data
  0088d000-0094b447 : Kernel bss
  01000000-04ffffff : Crash kernel
cff60000-cff68fff : ACPI Tables
cff69000-cff7ffff : ACPI Non-volatile Storage
cff80000-cfffffff : reserved
d0000000-d7ffffff : PCI Bus 0000:08
  d0000000-d7ffffff : 0000:08:01.0

I do have Bernhard's patch applied:

--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -444,6 +444,12 @@ void __init setup_arch(char **cmdline_p)
        contig_initmem_init(0, end_pfn);
 #endif

+       /*
+        * dma32_reserve_bootmem() allocates bootmem which may conflict
+        * with the crashkernel command line, so do that before
+        */
+       reserve_crashkernel();
+
        dma32_reserve_bootmem();

 #ifdef CONFIG_ACPI_SLEEP
@@ -484,7 +490,6 @@ void __init setup_arch(char **cmdline_p)
                }
        }
 #endif
-       reserve_crashkernel();

        reserve_ibft_region();



I'll try some printf's in  mem-max and mem-min inside locate_hole() as
you suggested.

-Cliff
-- 
Cliff Wickman
Silicon Graphics, Inc.
cpw@sgi.com
(651) 683-3824

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec -p loads

[Vivek Goyal]

On Wed, Aug 27, 2008 at 01:34:13PM -0500, Cliff Wickman wrote:
> 
> On Wed, Aug 27, 2008 at 11:36:22AM -0400, Vivek Goyal wrote:
> > On Wed, Aug 27, 2008 at 05:30:35PM +0200, Bernhard Walle wrote:
> > > * Vivek Goyal [2008-08-27 11:28]:
> > > > > > 
> > > > > > > I have this debugging output from my kexec:
> > > > > > > 
> > > > > > > cpw: elf_x86_64_load returning entry:0x1550
> > > > > > > cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550
> > > > > > > kexec_load: entry = 0x1550 flags = 1
> > > > > > > nr_segments = 6
> > > > > > > segment[0].buf   = 0x5237a0
> > > > > > > segment[0].bufsz = 7100
> > > > > > > segment[0].mem   = 0x1000
> > > > > > > segment[0].memsz = 9000
> > > > > > > 
> > > > > > > segment[1].buf   = 0x52aaf0
> > > > > > > segment[1].bufsz = 1000
> > > > > > > segment[1].mem   = 0xa000
> > > > > > > segment[1].memsz = 1000
> > > > > > > 
> > > > > > 
> > > > > > I think above two segments are not being loaded at right place. Looks like
> > > > > > kexec-tools decided to load first one at physical address 0x1000 and other at
> > > > > > physical address 0xa000. For crash kernel this is not right. It should
> > > > > > come out of reserved memory area and that's why you are encountering the
> > > > > > error.
> > > > > 
> > > > > Relocatability in ELF image never worked on x86_64 because of GDB but
> > > > > (so the binary was marked as ET_EXEC instead of ET_DYN).
> > > > > 
> > > > > You have to use bzImage for kdump in any case.
> > > > 
> > > > True that vmlinux is not relocatable. But one can always compile the
> > > > vmlinux for a fixed physical address (Address in reserved region) and then
> > > > use it?  In this case his vmlinux seems to have been compiled for physical
> > > > address 16MB. Which should be usable if there is a reserved memory region
> > > > at 16MB.
> > > 
> > > Of course, that's true. I just thought when Cliff uses the same kernel
> > > for "kexec -l" and "kexec -p", then it's the "normal" kernel. But I
> > > didn't calculate the numbers.
> > > 
> > > 
> > 
> > Its litle tricky. I think one can always do both "kexec -l" and "kexec -p"
> > on a vmlinux which has been built for kdump (for reserved region).
> > 
> > But one can not do "kexec -p" on normal kernel vmlinux.
> > 
> > So I am assuming that Cliff is running into first case. But he can tell
> > us more. 
> > 
> > Cliff, is it same vmlinux which you use for first kernel or a different
> > vmlinux compiled for dump capture.
> 
> Sorry for the lag.  I was working on the problem and not watching my mail.
> 
> I'm using two different kernels.
> The kdump vmlinux is compiled with
> CONFIG_CRASH_DUMP=y
> CONFIG_PHYSICAL_START=0x1000000
> 
> I'm using  kexec-tools-1.101

This is too old  a version. Can you try the version 2.0.0. from following
link.

http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.bz2

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec -p loads

[Cliff Wickman]

On Wed, Aug 27, 2008 at 03:01:57PM -0400, Vivek Goyal wrote:
> On Wed, Aug 27, 2008 at 01:34:13PM -0500, Cliff Wickman wrote:
> > 
> > On Wed, Aug 27, 2008 at 11:36:22AM -0400, Vivek Goyal wrote:
> > > On Wed, Aug 27, 2008 at 05:30:35PM +0200, Bernhard Walle wrote:
> > > > * Vivek Goyal [2008-08-27 11:28]:
> > > > > > > 
> > > > > > > > I have this debugging output from my kexec:
> > > > > > > > 
> > > > > > > > cpw: elf_x86_64_load returning entry:0x1550
> > > > > > > > cpw: after call to file_type[i].load: nr_segments:6 entry:0x1550
> > > > > > > > kexec_load: entry = 0x1550 flags = 1
> > > > > > > > nr_segments = 6
> > > > > > > > segment[0].buf   = 0x5237a0
> > > > > > > > segment[0].bufsz = 7100
> > > > > > > > segment[0].mem   = 0x1000
> > > > > > > > segment[0].memsz = 9000
> > > > > > > > 
> > > > > > > > segment[1].buf   = 0x52aaf0
> > > > > > > > segment[1].bufsz = 1000
> > > > > > > > segment[1].mem   = 0xa000
> > > > > > > > segment[1].memsz = 1000
> > > > > > > > 
> > > > > > > 
> > > > > > > I think above two segments are not being loaded at right place. Looks like
> > > > > > > kexec-tools decided to load first one at physical address 0x1000 and other at
> > > > > > > physical address 0xa000. For crash kernel this is not right. It should
> > > > > > > come out of reserved memory area and that's why you are encountering the
> > > > > > > error.
> > > > > > 
> > > > > > Relocatability in ELF image never worked on x86_64 because of GDB but
> > > > > > (so the binary was marked as ET_EXEC instead of ET_DYN).
> > > > > > 
> > > > > > You have to use bzImage for kdump in any case.
> > > > > 
> > > > > True that vmlinux is not relocatable. But one can always compile the
> > > > > vmlinux for a fixed physical address (Address in reserved region) and then
> > > > > use it?  In this case his vmlinux seems to have been compiled for physical
> > > > > address 16MB. Which should be usable if there is a reserved memory region
> > > > > at 16MB.
> > > > 
> > > > Of course, that's true. I just thought when Cliff uses the same kernel
> > > > for "kexec -l" and "kexec -p", then it's the "normal" kernel. But I
> > > > didn't calculate the numbers.
> > > > 
> > > > 
> > > 
> > > Its litle tricky. I think one can always do both "kexec -l" and "kexec -p"
> > > on a vmlinux which has been built for kdump (for reserved region).
> > > 
> > > But one can not do "kexec -p" on normal kernel vmlinux.
> > > 
> > > So I am assuming that Cliff is running into first case. But he can tell
> > > us more. 
> > > 
> > > Cliff, is it same vmlinux which you use for first kernel or a different
> > > vmlinux compiled for dump capture.
> > 
> > Sorry for the lag.  I was working on the problem and not watching my mail.
> > 
> > I'm using two different kernels.
> > The kdump vmlinux is compiled with
> > CONFIG_CRASH_DUMP=y
> > CONFIG_PHYSICAL_START=0x1000000
> > 
> > I'm using  kexec-tools-1.101
> 
> This is too old  a version. Can you try the version 2.0.0. from following
> link.
> 
> http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.bz2

Ahh.  That works.
I think I got 1.101 as the latest from sourceforge.  I should've looked
at the path in Documentation/kdump/kdump.txt

Thanks.
-Cliff
-- 
Cliff Wickman
Silicon Graphics, Inc.
cpw@sgi.com
(651) 683-3824

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec