Messages in this thread | | | Date | Wed, 25 Jan 2012 23:51:08 +0100 | From | Steffen Persvold <> | Subject | Re: RCU qsmask !=0 warnings on large-SMP... |
| |
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
| |