backporting kexec/kdump function

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


Hi Larry,

On 12/21/06, Larry Brigman <larry.brigman at gmail.com> wrote:
> I would like to get the list's opinion about
> which kernel tree I should use to backport the
> kexec/kdump functionality into
> a Montavista 2.6.10 kernel tree.

Great, more users! =)

> I am in a project that is wed to the MVL tool chain/kernel tree for now. MVL
> isn't going to support this function until about the middle of next
> year (2.6.16 kernel).

Right, and that's bleeding edge in the embedded world, right? =)

Which architectures are you going to support?

> I believe that I have functional change sets (which none apply
> cleanly) from 2.6.9 through
> 2.6.12.
>
> I have actually been able to get this partially working from the
> 2.6.9-mm1 but it
> doesn't get me a valid core dump (kexec -e and kexec -p both work).
> The file is marked correctly as a core but it is the size of all
> memory and gdb determine
> anything about the file. The lastest version of crash (with and outof
> data gdb) doesn't
> understand the file either.

I don't have any direct recommendation for kexec itself, but if you
are thinking of using kexec-on-panic aka kdump or CONFIG_CRASH_DUMP on
i386 or x86_64 then I would backport the code included in 2.6.19.
Older code will overwrite user space page tables which may not be what
you want if you hope to analyze the crash dump later.

> I am using the kexec-tools-1.101 with the kdump patch and gcc 3.4.3.

I think you should use kexec-tools-testing instead. Many things have
changed since kexec-tools-1.101 and I would say that the recent
release kexec-tools-testing-20061214 is very well tested - at least on
i386 and x86_64. I'm not sure about the other architectures - but if
it doesn't work for you then we will fix it.

> Also, is there other resources I should be looking at to examine the core dump.

readelf -a is you friend. =)

I would focus on getting kexec to work properly first if I were you.
And when that is in place I would spend time on fixing up kdump. The
kdump chain is pretty complex, and the kexec user space code is pretty
hairy. So after fixing up kexec you need to make sure the kdump chain
works. This is very similar to the work that we have been doing with
out Xen port.

Like I said - the kdump chain is pretty complex, but I've found myself
spending way too much time on the kexec user space tool itself. Simon,
I and other people on the list have lately been working on cleaning up
the code base - so again - I strongly recommend you to build on that
code.

Happy hacking!

/ magnus


[Netdev]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]     [Linux Media]     [Linux Resources]

Powered by Linux