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.
