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.
Regards
Jason
---------------------------
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.
