<p>America,</p>
<p>To clarify, crashkernel=480@2G or @1G doesn"t work either.  Further, for older kernels (2.6.32) it was possible to create crashkernel areas larger than 480M (crashkernel=512M).  Starting somewhere around 2.6.36, this stopped working.  Are you saying this was an intentional change?</p>

<p>tim</p>
<div class="gmail_quote">On Nov 16, 2011 4:47 AM, "Américo Wang" <<a href="mailto:xiyou.wangcong@gmail.com">xiyou.wangcong@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Nov 16, 2011 at 6:57 AM, Tim Hartrick <<a href="mailto:tim@edgecast.com">tim@edgecast.com</a>> wrote:<br>
><br>
> Americo,<br>
><br>
> I downloaded the source for kexec-tools 1:2.0.2-1ubuntu3 and rebuilt it<br>
> with -DDEBUG and installed.  Below are the results using the<br>
> 2.6.38-8-server Ubuntu kernel as base and crashkernel.  Note that the<br>
> crashkernel size has been increased to 479M.<br>
<br>
<br>
Thanks for testing!<br>
<br>
><br>
> While I have the list's attention, I would like to mention another<br>
> problem in this area.  The 2.6.38-8-server kernel cannot create a<br>
> crashkernel area greater than 479M in size (e.g. crashkernel=480M).  If<br>
> the crashkernel is relocated (e.g. crashkernel=480M@8G), then the kernel<br>
> will create the area but kexec (1:2.0.1-1ubuntu3) fails while attempting<br>
> to load crashkernel into the reserved area.<br>
<br>
<br>
I am afraid kexec can't load the kernel to memory above 4G.<br>
<br>
><br>
> This is a fatal problem since the 2.6.38-8-server kernel running as<br>
> crashkernel requires more than 479M of crashkernel area to successfully<br>
> take a dump on our systems.  I will be happy to provide additional<br>
> information about this one as well.<br>
<br>
Well, this is not kernel problem, it is a problem of your kdump tool<br>
on Ubuntu, the initrd of the second kernel should do as minimum things<br>
as possible.<br>
<br>
<br>
> Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr = 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400<br>
> Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr = 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400<br>
> Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr = 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400<br>
> Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr = 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400<br>
> Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr = 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400<br>
> Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr = 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400<br>
> Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr = 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400<br>
> Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr = 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400<br>
<br>
You have 8 cpus, but it is strange that these PT_NOTE program headers<br>
are all same...<br>
<br>
So, can you show us the output of the following commands on your machine?<br>
<br>
#hexdump -C /sys/kernel/crash_notes<br>
#for i in /sys/devices/system/cpu/cpu*/crash_notes; do hexdump -C $i; done<br>
<br>
Thanks.<br>
</blockquote></div>