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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: linux-ia64-owner@xxxxxxxxxxxxxxx
> [mailto:linux-ia64-owner@xxxxxxxxxxxxxxx] 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=13,
>     v=0xe000003007157b70) at kernel/sys.c:144
> #5  0xa0000001000cf170 in atomic_notifier_call_chain
> (nh=0xe000003014bcb3f0,
>     val=21, 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.
 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
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel]     [Sparc Linux]     [DCCP]     [Linux ARM]     [Yosemite News]     [Linux SCSI]     [Linux x86_64]     [Linux for Ham Radio]

  Powered by Linux