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

Hi guys,

linux-2.6.27-rc3 kernel causes the kdump kernel to panic at
__free_pages_bootmem(). It has been fixed in 2.6.27-rc4.

So, avoid 2.6.27-rc3 if you want to use the 'kdump' feature
of KDB. (Or, kdump without KDB ;))

Regards,
 - jay



Jay Lan wrote:
> 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
> 

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