[lkml]   [2011]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectQuery about kdump_msg hook into crash_kexec()

    I noticed following commit which hooks into crash_kexec() for calling

    I think it is not a very good idea to pass control to modules after
    crash_kexec() has been called. Because modules can try to take locks
    or try to do some other operations which we really should not be doing
    now and fail kdump also. The whole design of kdump is built on the
    fact that in crashing kernel we do minimal thing and try to make
    transition to second kernel robust. Now with this hook, kmsg dumper
    breaks that assumption.

    Anyway, if an image is loaded and we have setup to capture dump also
    why do we need to save kmsg with the help of an helper. I am assuming
    this is more of a debugging aid if we have no other way to capture the
    kernel log buffer. So if somebody has setup kdump to capture the
    vmcore, why to call another handler which tries to save part of the
    vmcore (kmsg) separately.


    commit 0f4bd46ec252887f44f1f065b41867cac8f70dfb
    Author: KOSAKI Motohiro <>
    Date: Tue Dec 22 03:15:43 2009 +0000

    kmsg_dump: Dump on crash_kexec as well

    crash_kexec gets called before kmsg_dump(KMSG_DUMP_OOPS) if
    panic_on_oops is set, so the kernel log buffer is not stored
    for this case.

    This patch adds a KMSG_DUMP_KEXEC dump type which gets called
    when crash_kexec() is invoked. To avoid getting double dumps,
    the old KMSG_DUMP_PANIC is moved below crash_kexec(). The
    mtdoops driver is modified to handle KMSG_DUMP_KEXEC in the
    same way as a panic.

    Signed-off-by: KOSAKI Motohiro <>
    Acked-by: Simon Kagstrom <>
    Signed-off-by: David Woodhouse <>


     \ /
      Last update: 2011-02-01 00:03    [W:0.032 / U:51.248 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site