lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F20875C.3000207@numascale.com>
Date:	Wed, 25 Jan 2012 23:51:08 +0100
From:	Steffen Persvold <sp@...ascale.com>
To:	paulmck@...ux.vnet.ibm.com
CC:	Daniel J Blueman <daniel@...ascale-asia.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	linux-kernel@...r.kernel.org, x86@...nel.org
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ