Re: RCU qsmask !=0 warnings on large-SMP...

[Steffen Persvold]

On 1/25/2012 22:51, Paul E. McKenney wrote:
> 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.

It seems that I don't have the /sys/kernel/debug/tracing/events 
interface on the kernel I'm running now. Perhaps I need to enable the 
CONFIG_FTRACE feature also ? If so what FTRACE interfaces do I need ?

Cheers,
--
Steffen Persvold, Chief Architect NumaChip
Numascale AS - www.numascale.com
Tel: +47 92 49 25 54 Skype: spersvold
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/