Re: [ANNOUNCE] Support 'kdump' command from KDB in 2.6.27-rc2-*-2.bz2 patchset
"jidong xiao" <[email protected]> Thu, 21 Aug 2008 13:53:07 +0800
| Newsgroups | gmane.linux.kernel.debugging |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Aug 21, 2008 at 2:36 AM, Jay Lan <[email protected]> wrote: > jidong xiao wrote: >> On Sat, Aug 16, 2008 at 3:49 AM, Jay Lan <[email protected]> wrote: >>> Hi, >>> >>> The kdb 2.6.27-rc2-*-2.bz2 patchset contains implementation >>> of 'kdump' command. It was based on the original patch posted >>> by Dan Aloni last year, then modified to provide i386 support >>> by Jason Xiao. I added IA64 support. I also added hooks to >>> intercept and drop to KDB from oops. >>> >>> It looks quite different from your patch, Jason, especially >>> in kdb/kdbmain.c to a style i like better. Sorry about that. >>> >>> This implementation would catch die, panic, MCA, NMI conditions >>> and drop into KDB. After analyze the oops situation and data, >>> you can issue 'kdump' command and a kdump vmcore will be >>> created. >>> >>> I do not intercept 'echo c > /proc/sysrq-trigger' since i see >>> no need to create extra works if users already decide to create >>> a vmcore from user space. Besides, you can use KDB key sequence >>> to break into KDB and do a 'kdump' command to take a dump as well. >>> >>> Doing a 'go' after panic is undefined, and it also depends on >>> the value of CONFIG_KDB_CONTINUE_CATASTROPHIC. So, do 'kdump' >>> after panic if you want take a vmcore. >>> >>> I have tested on IA64 and X86_64 to see a kdump kernel booted >>> up and /proc/vmcore created. Due to bugs of makedumpfile and >>> crash against the latest kernels, i did not run crash to >>> check validity of the vmcore though. >>> >>> Please report any bugs to me. Thanks! >>> >>> Regards, >>> - jay >>> >>> >> Hi,Jay, >> >> arch/ia64/kdb/kdba_support.c, >> >> void >> kdba_kdump_prepare(struct pt_regs *fixed_regs) >> { >> int i; >> >> /* Set on KEXEC bit on all onlinr cpus */ >> for (i = 1; i < NR_CPUS; ++i) { >> if (!cpu_online(i)) >> continue; >> >> KDB_STATE_SET_CPU(KEXEC, i); >> } >> >> /* delaying for 5 seconds ... */ >> udelay(5*1000000); >> machine_crash_shutdown(fixed_regs); >> } >> >> I wonder why do we need this 5-seconds-delay. Thanks. > > I stole the code from ia64_init_handler() of arch/ia64/kernel/mca.c: > > /* > * Wait for a bit. On some machines (e.g., HP's zx2000 and > zx6000, INIT can be > * generated via the BMC's command-line interface, but since the > console is on the > * same serial line, the user will need some time to switch out > of the BMC before > * the dump begins. > */ > mprintk("Delaying for 5 seconds...\n"); > udelay(5*1000000); > ia64_wait_for_slaves(cpu, "INIT"); > > Since i can not test on those machines mentioned above, i can not tell > if the delay is really necessary. But it is IA64 specific, i guess. Okay, I see. Thanks. > > Have you tested the code on x86_32, Jason? I do not have an x86_32 > mchine set up for kdump testing... > I will test the code on x86_32 (and also ia64) soon. Will let you know the result. Regards Jason > Regards, > - jay > >> >> Regards >> Jason > > --------------------------- Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.