17 Oct, 2007

1 commit

  • This patch set frees the restriction that makedumpfile users should install a
    vmlinux file (including the debugging information) into each system.

    makedumpfile command is the dump filtering feature for kdump. It creates a
    small dumpfile by filtering unnecessary pages for the analysis. To
    distinguish unnecessary pages, it needs a vmlinux file including the debugging
    information. These days, the debugging package becomes a huge file, and it is
    hard to install it into each system.

    To solve the problem, kdump developers discussed it at lkml and kexec-ml. As
    the result, we reached the conclusion that necessary information for dump
    filtering (called "vmcoreinfo") should be embedded into the first kernel file
    and it should be accessed through /proc/vmcore during the second kernel.
    (http://www.uwsg.iu.edu/hypermail/linux/kernel/0707.0/1806.html)

    Dan Aloni created the patch set for the above implementation.
    (http://www.uwsg.iu.edu/hypermail/linux/kernel/0707.1/1053.html)

    And I updated it for multi architectures and memory models.
    (http://lists.infradead.org/pipermail/kexec/2007-August/000479.html)

    Signed-off-by: Dan Aloni
    Signed-off-by: Ken'ichi Ohmichi
    Signed-off-by: Bernhard Walle
    Signed-off-by: Daisuke Nishimura
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Ken'ichi Ohmichi
     

27 Sep, 2006

1 commit


26 Sep, 2006

1 commit

  • Assume that a cpu is *physically* offlined at boot time...

    Because smpboot.c::smp_boot_cpu_map() canoot find cpu's sapicid,
    numa.c::build_cpu_to_node_map() cannot build cpunode map for
    offlined cpu.

    For such cpus, cpu_to_node map should be fixed at cpu-hot-add.
    This mapping should be done before cpu onlining.

    This patch also handles cpu hotremove case.

    Signed-off-by: KAMEZAWA Hiroyuki
    Cc: "Luck, Tony"
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    KAMEZAWA Hiroyuki
     

26 Apr, 2006

1 commit


25 Mar, 2006

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds