On 02/05/2013 06:52 PM, Steven Rostedt wrote:
On Tue, 2013-02-05 at 18:26 -0800, Ben Greear wrote:
Well, here it is..something is calling rcu_read_lock lots and lots,
Or a bug in the way lockdep handles rcu mappings.
it seems. Any way to get a better idea of where those calls are
made?
Yeah, with ftrace.
96 locks held by swapper/0/0:
#0: (rcu_read_lock){.+.+..}, at: [<ffffffff81476836>] rcu_read_lock+0x0/0x6f
#1: (rcu_read_lock){.+.+..}, at: [<ffffffff81476836>] rcu_read_lock+0x0/0x6f
[...]
#92: (rcu_read_lock){.+.+..}, at: [<ffffffff81476836>]
rcu_read_lock+0x0/0x6f
#93: (&(&wl->cfg_spin_lock)->rlock){..-...}, at: [<ffffffffa07bc4d0>]
handle_rcv+0x15d/0x1dd [wanlink]
#94: (&wl_threads[q].my_wq){..-...}, at: [<ffffffff810abe4d>]
__wake_up+0x1d/0x48
#95: (&p->pi_lock){-.-.-.}, at: [<ffffffff810b09c1>]
try_to_wake_up+0x29/0x20b
If you haven't already configured ftrace into your kernel, can you
please do so. Specifically:
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
Then, before triggering this, run the following as root:
# mount -t debugfs nodev /sys/kernel/debug
# cd /sys/kernel/debug/tracing
# echo net_rx_action > set_graph_function
# echo function_graph > current_tracer
In the kernel, where you added the above dump, before any of the printks
happen, add this too:
trace_printk("BUG\n");
tracing_off();
This will stop the trace at the point of the error. The trace_printk()
is a nice way to see the trace too.
Then after you trigger the bug, do the following:
cat /sys/kernel/debug/tracing/trace
and reply with that.
It's huge, so here's a link:
http://www.candelatech.com/~greearb/debug.tgz
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
