Re: ia64: What the stack trace of a slave cpu kdump should save?

[Jay Lan <jlan@sgi.com>]

Zou, Nanhai wrote:
>> -----Original Message-----
>> From: linux-ia64-owner@vger.kernel.org
>> [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Jay Lan
>> Sent: 2006Äê11ÔÂ3ÈÕ 2:49
>> To: fastboot; Linux-IA64
>> Subject: ia64: What the stack trace of a slave cpu kdump should save?
>>
>> Hi,
>>
>> I have a vmcore created by NMI on an SN. The gdb backtrace
>> showed the slave cpu as below:
>>
>> # gdb vmlinux vmcore-nmi-10
>> GNU gdb 6.4
>> Copyright 2005 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> This GDB was configured as "ia64-suse-linux"...Using host libthread_db
>> library "/lib/libthread_db.so.1".
>>
>> #0  crash_save_this_cpu () at arch/ia64/kernel/crash.c:57
>>
>> warning: Source file is more recent than executable.
>> 57              memcpy(buf, name, note->n_namesz);
>> (gdb) bt
>> #0  crash_save_this_cpu () at arch/ia64/kernel/crash.c:57
>> #1  0xa00000010005f580 in kdump_cpu_freeze (info=<value optimized out>,
>>     arg=0x1) at arch/ia64/kernel/crash.c:166
>> #2  0xa00000010000c9f0 in unw_init_running () at include/linux/bitmap.h:237
>> #3  0xa00000010005ef70 in kdump_init_notifier (self=0xa000000100b47d78,
>>     val=<value optimized out>, data=0xe000003007157b70)
>>     at arch/ia64/kernel/crash.c:217
>> #4  0xa0000001000cf0d0 in notifier_call_chain (nl=0xe000003014bcb3f8,
>> val\x13,
>>     v=0xe000003007157b70) at kernel/sys.c:144
>> #5  0xa0000001000cf170 in atomic_notifier_call_chain
>> (nh=0xe000003014bcb3f0,
>>     val!, v=0xe000003007157b70) at kernel/sys.c:229
>> #6  0xa000000100048480 in ia64_init_handler (regs=0xe000003007157e40,
>>     sw=<value optimized out>, sos=<value optimized out>)
>>     at include/asm/kdebug.h:88
>> #7  0xa0000001000493a0 in ia64_os_init_virtual_begin ()
>>     at include/asm/kdebug.h:88
>> (gdb)
>>
>> It is the stack _after_ NMI is triggered. Is this supposed to be?
>> What do you see on other (ie not SN) ia64 platforms?
>>
>  Yes, this is the stack on all other platforms.., 
>  
>  You may call it INIT instead of NMI because NMI is another kind of interrupt that can be masked by psr.i...
>  Kdump construct an additional switch stack frame on top of current stack thus crash tool can do its unwind from that.
>  Kdump also capture ip, sp, bsp and other register related to current stack frame to help gdb to unwind the stack.
>  What you see is the stack of INIT , you may use crash tools to back trace stack of other process.

Yes, the crash tools Dave released today (4.0-3.9) showed the stacks
nicely. Thanks for your explanation, Nanhai.

- jay


>  However INIT can break CPU in any context include PROM code, so it is not possible to back trace the stack of INIT happening..
> 
> Thanks
> Zou Nan hai
> -