On Wed, Jan 25, 2012 at 09:35:15PM +0100, Steffen Persvold wrote:[]
Yes, 3.2.1 is our debug target right now.
OK, good! Could you please add an "ftrace_dump(DUMP_ALL)" before you
print the first set of error messages? (Preferably set up so that
you only dump once!)
Then before you start testing, could you please enable the
rcu_grace_period and rcu_grace_period_init trace events? This should
get a good picture of the sequence of grace-period-related events leading
up to the failure.
You will need to build the kernel with CONFIG_RCU_TRACE=y.
The usual commands suffice to enable tracing:
echo 1> /sys/kernel/debug/tracing/events/rcu_grace_period/enable
echo 1> /sys/kernel/debug/tracing/events/rcu_grace_period_init/enable
This should give some history that might help understand why the previous
grace period ended before the CPUs had all checked in. Maybe even why
the rcu_node structures got advance notice of the new grace period...
Are you talking about the data from /sys/kernel/debug/rcu/ ? I have
CONFIG_RCU_TRACE (and consequently CONFIG_TREE_RCU_TRACE) set, is
this enough to get the event data you want ?
Yep, if you have CONFIG_RCU_TRACE=y, then the two tracepoints should
be available.