lkml.org 
[lkml]   [2005]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
    From
    Date
    Itsuro Oda <oda@valinux.co.jp> writes:

    > Hi,
    >
    > On 03 Feb 2005 02:00:51 -0700
    > ebiederm@xmission.com (Eric W. Biederman) wrote:
    >
    > > > 5) dump kernel: export all valid physical memory (and saved register
    > > > information) to the user. (as /dev/oldmem /proc/vmcore ?)
    > >
    > > Or in user space, by just mmaping /dev/mem. That is part of the
    > > current conversation. The only real point for putting that code in
    > > the kernel (besides momentum) is it is a cheap way to get the exact
    > > data structures of the kernel you are using. But since:
    > > (a) it does not look like any primary kernel data structures need to
    > > be examined.
    > > (b) even simple compile options like SMP/NOSMP are enough to change
    > > the layout of the data structures.
    > > I think there is a pretty good case for moving all of the work to
    > > user space. But you still need a kernel that loads and
    > > runs in the reserved area.
    > >
    > I don't make sense. what do you mean ?
    >
    > What we want to do when the system is crashed is storing the whole
    > physical memory (and saved register information for x86 arch) to
    > some place (ex. a disk partition) for later analysis.
    > So the basic requirments to the dump kernel is that:
    > * supply a method to access whole (valid) physical memory.
    > * supply a method to access the saved register information.
    >
    > Does the kdump meet this requirment ?

    Yes, the discussion in this area is what is the best way to implement
    this requirement. How much should be in the kernel and how much
    should be in user space.

    At the moment things are broken but should be fixed shortly.
    So what has been implemented are /dev/oldmem which provides access
    to the old memory. And /proc/vmcore which provides both the old
    memory and the register information.

    > (I am not interesting to /proc/vmcore. Constructing the vmcore
    > image is area of analysis tools. not kernel's task.)

    There is a fine line there, as a simple ELF core dump has just enough
    information to describe discontiguous memory, and to have an out of
    band channel for register information. Adding anything extra like
    virtual addresses that match the kernel should be left for the
    crash dump analysis tools.

    In code that is currently in the mainstream kernel /dev/mem can
    mmap any area of memory that is not used by the kernel as ram.
    So what I believe we will end up is that /sbin/kexec (user space)
    will prepare an ELF header (data) that describes the memory regions
    and details where to find the kernels register information. The
    address of that ELF header will be passed to the crash dump
    capture kernel and user space combination. The something
    (probably a user space program reading /dev/mem) will look
    at the ELF header and save the already prepared ELF core
    dump to disk. Possibly doing little things like merging
    the MAX_NR_CPUS note segments into one so it actually conforms
    to the ELF spec.

    This thread started as the design discussion before finishing
    that part of the implementation. The proof of concept
    implementations have happened. We have all seen this kind
    of functionality implemented. Now is the time to come up
    with a good solid design that can be maintained and merged
    into the mainline kernel and distros.

    So thank you for ask questions, it means we have a better chance
    of getting a solid design and a design that those people who
    care about this functionality can use. And with a little luck
    we can all wind up on agreeing on the general principles. You came in
    a little late to this conversation so a lot of details have been
    settled, but if you have a good argument for doing something another
    way we can certainly look at that.

    Eric
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:10    [W:2.384 / U:0.420 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site