Re: [ANNOUNCE] Support 'kdump' command from KDB in 2.6.27-rc2-*-2.bz2 patchset

jidong xiao wrote:
> 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.

I just found out the same KDB patchset that applied to 2.6.27-rc2 worked
fine, but it would cause the kdump kernel panic on __free_pages_bootmem
on 2.6.27-rc3. It was on ia64.

Now in addition to running the kdb sanity test every time i rebase
the KDB patchset to a newer release, it seems that i need to test
kdump as well. :(

Regards,
 - jay

> 
> Regards
> Jason
> 
>> Regards,
>>  - jay
>>
>>> Regards
>>> Jason
>>
> ---------------------------
> Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.

---------------------------
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.