Crash during vmcore_init

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



America,

To clarify, crashkernel=480 at 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?

tim
On Nov 16, 2011 4:47 AM, "Am?rico Wang" <xiyou.wangcong at gmail.com> wrote:

> On Wed, Nov 16, 2011 at 6:57 AM, Tim Hartrick <tim at edgecast.com> wrote:
> >
> > Americo,
> >
> > I downloaded the source for kexec-tools 1:2.0.2-1ubuntu3 and rebuilt it
> > with -DDEBUG and installed.  Below are the results using the
> > 2.6.38-8-server Ubuntu kernel as base and crashkernel.  Note that the
> > crashkernel size has been increased to 479M.
>
>
> Thanks for testing!
>
> >
> > While I have the list's attention, I would like to mention another
> > problem in this area.  The 2.6.38-8-server kernel cannot create a
> > crashkernel area greater than 479M in size (e.g. crashkernel=480M).  If
> > the crashkernel is relocated (e.g. crashkernel=480M at 8G), then the kernel
> > will create the area but kexec (1:2.0.1-1ubuntu3) fails while attempting
> > to load crashkernel into the reserved area.
>
>
> I am afraid kexec can't load the kernel to memory above 4G.
>
> >
> > This is a fatal problem since the 2.6.38-8-server kernel running as
> > crashkernel requires more than 479M of crashkernel area to successfully
> > take a dump on our systems.  I will be happy to provide additional
> > information about this one as well.
>
> Well, this is not kernel problem, it is a problem of your kdump tool
> on Ubuntu, the initrd of the second kernel should do as minimum things
> as possible.
>
>
> > Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr =
> 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400
> > Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr =
> 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400
> > Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr =
> 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400
> > Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr =
> 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400
> > Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr =
> 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400
> > Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr =
> 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400
> > Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr =
> 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400
> > Elf header: p_type = 4, p_offset = 0xdb74000000000000 p_paddr =
> 0xdb74000000000000 p_vaddr = 0x0 p_filesz = 0x400 p_memsz = 0x400
>
> You have 8 cpus, but it is strange that these PT_NOTE program headers
> are all same...
>
> So, can you show us the output of the following commands on your machine?
>
> #hexdump -C /sys/kernel/crash_notes
> #for i in /sys/devices/system/cpu/cpu*/crash_notes; do hexdump -C $i; done
>
> Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20111116/8563ab18/attachment.html>


[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux