kexec and kdb

Preetesh Parekh preetesh at
Mon May 14 19:20:29 EDT 2007

Hi Vivek,

I did modify "arch/i386/kernel/traps.c" file at 2 places as per your
suggestion but still problem is not solved. Please let us know.

File content of traps.c in function __kprobes die_nmi:
#ifdef  CONFIG_KDB
        kdb(KDB_REASON_NMI, 0, regs);
#endif  /* CONFIG_KDB */
        console_silent();        spin_unlock(&nmi_print_lock);

        /* If we are in kernel we are probably nested up pretty bad
         * and might aswell get out now while we still can.
        if (!user_mode_vm(regs)) {
                current->thread.trap_no = 2;

File content of traps.c in function die:
        die.lock_owner = -1;
        spin_unlock_irqrestore(&die.lock, flags);
#ifdef  CONFIG_KDB
        kdb_diemsg = str;
        kdb(KDB_REASON_OOPS, err, regs);
#endif  /* CONFIG_KDB */

        if (!regs)

        if (kexec_should_crash(current))


-----Original Message-----
From: Vivek Goyal [mailto:vgoyal at] 
Sent: Thursday, May 10, 2007 9:23 PM
To: Preetesh Parekh
Cc: kexec at
Subject: Re: kexec and kdb

On Thu, May 10, 2007 at 03:10:16PM -0700, Preetesh Parekh wrote:
> Hi,
> I have a question about kexec and kdb. Please advice or point me to
> right mailing list that can answer this.
> I have a linux 2.6.20 kernel (patched with kdb patches) on i686
> I have setup a crash kernel using "kexec -p" command which is working
> very well. I tested this by triggering a crash by using "echo c >
> /proc/sysrq-trigger" command. 
> The requirement is to allow kdb to invoke first after the kernel crash
> which is not happening now (The system directly gets booted with the
> dump kernel). 

crash_kexec() is the entry point for dump capture start process. I think
before that you need to put the KDB entry point so that upon a crash
control first goes to kdb.


More information about the kexec mailing list