Are there any existing method/code to get a reliable back trace dump for oops? Kgdb is not usable here because I have no serial port. Do I need to copy gdb code to analysis the stack? If I am not wrong, dump_stack() just print out any stack address falled in the text section, and that will make the result hard to understand. For example, I often find some interrupt functions mixed with normal function names and repeated functions, e.g. 8e1c7968: redzone 1: 0x0, redzone 2: 0x170fc2a5. slab error in cache_free_debugcheck(): cache `dentry_cache': double free, or memory nCall Trace: [<8035de48>] cache_free_debugcheck+0x1dc/0x2d4 [<8035de1c>] cache_free_debugcheck+0x1b0/0x2d4 [<8035f35c>] kmem_cache_free+0x60/0x248 [<8033f7e4>] __rcu_process_callbacks+0xdc/0x360 /* between kmem_cache_free? */ [<8035f35c>] kmem_cache_free+0x60/0x248 [<80300e10>] ll_cputimer_irq+0xc/0x14 [<8033f7e4>] __rcu_process_callbacks+0xdc/0x360 [<804c1480>] int_timer_do+0x1c/0x30 [<8033fa8c>] rcu_process_callbacks+0x24/0x48 [<803338d8>] run_timer_softirq+0x128/0x244 [<804c1480>] int_timer_do+0x1c/0x30 [<8032ee50>] tasklet_action+0xd4/0x1b8 [<8032e7e4>] __do_softirq+0x94/0x15c [<8032e93c>] do_softirq+0x90/0xbc [<80303814>] do_IRQ+0x24/0x34 [<8035e220>] cache_alloc_debugcheck_after+0x17c/0x1b4 /* do_IRQ happens inside debugcheck? */ [<8035e220>] cache_alloc_debugcheck_after+0x17c/0x1b4 [<80300e10>] ll_cputimer_irq+0xc/0x14 [<803a961c>] d_alloc+0x34/0x22c [<8035e5e8>] kmem_cache_alloc+0x128/0x220 [<803a961c>] d_alloc+0x34/0x22c /* where is the ROOT of current trace... ?? */ [<80478660>] memset_partial+0x44/0x6c [<8039a808>] __link_path_walk+0x790/0x1a38 [<8039a870>] __link_path_walk+0x7f8/0x1a38 [<8035d8a0>] check_poison_obj+0x40/0x238 [<8039bb90>] link_path_walk+0xe0/0x438 [<8035e174>] cache_alloc_debugcheck_after+0xd0/0x1b4 [<80380114>] get_unused_fd+0x158/0x20c [<8039bfc8>] path_lookup+0xe0/0x3e8 [<8038235c>] get_empty_filp+0x5c/0x110 [<8038235c>] get_empty_filp+0x5c/0x110 [<8039d2f8>] open_namei+0xa4/0xdf4 [<8038235c>] get_empty_filp+0x5c/0x110 [<8037fee4>] filp_open+0x74/0xe0 [<80398bdc>] getname+0x2c/0x13c [<80380114>] get_unused_fd+0x158/0x20c [<803802e0>] do_sys_open+0x84/0x144 [<80303814>] do_IRQ+0x24/0x34 [<8030c5a4>] stack_done+0x20/0x3c [<80478670>] memset_partial+0x54/0x6c 8e1c78d4: redzone 1: 0x170fc2a5, redzone 2: 0x10. IOPortBase = 2af34000 Ralf Baechle 写道: > On Tue, Mar 21, 2006 at 04:02:19PM -0800, Srinivas Kommu wrote: > >> I'm running gdb on vmlinux connected to a remote target (2.4 kernel). I >> have the task_struct address of 'current' and other processes. Is it >> possible to get a symbolic stack trace of the kernel stack? Where is the >> kernel stack located? I tried to print (task_struct->reg29)[13]. Is this >> the PC? > > I assume you meant task_struct->reg29)[31] which is the address at which > the process is going to resume execution when it's time has arrived. But > in most cases this address isn't terribly interesting. So we have two > cases here: > > o $31 pointing to ret_from_fork > This is a new born process which will begin it's active life of > execution on a CPU at ret_from_fork. This is where the resume function > will jump to which may well be not the scheduler function. > o Otherwise: > The thread is regaining the CPU and the resume() call is going to return > straight to it's caller, kernel/sched.c:context_switch() which inlined > into schedule() and what we actually want is schedule's caller, so we > dig through the scheduler's stack frame. To make things more > entertaining the stack frame will change with configuration options and > compiler used, so we basically have to disassemble the stackframe. > > For get_wchan We repeat that exercise in the cases we one of the other > scheduler functions may have called schedule() until we reach a > non-schedule function. So now we have a pointer that actually points to > something interesting, a driver or other kernel subsystem. > > The whole thing is a bit of a mindbender. Why? The scheduler is designed > to deliver best possible performance and we've not compromized on > performance to make the job of backtracing any easier. > >> PS. I broke into gdb using a hotkey on the serial console; so the gdb >> backtrace shows the serial driver. > > In which you need to be extra careful about the validity of any pointer > you might encounter. > > Ralf > > >
