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.
