On Sat, Sep 22, 2012 at 05:45:12PM +0200, Frederic Weisbecker wrote:

2012/9/22 Paul E. McKenney [off-list ref]:

quoted

On Fri, Sep 21, 2012 at 01:31:49PM -0700, Tony Lindgren wrote:

quoted

* Paul E. McKenney [off-list ref] [120921 12:58]:

quoted

Just to make sure I understand the combinations:

o   All stalls have happened when running a minimal userspace.
o   CONFIG_NO_HZ=n suppresses the stalls.
o   CONFIG_RCU_FAST_NO_HZ (which depends on CONFIG_NO_HZ=y) has
    no observable effect on the stalls.

The reason why you may need minimal userspace is to cut down
the number of timers waking up the system with NO_HZ.
Booting with init=/bin/sh might also do the trick for that.

Good point!  This does make for a very quiet system, but does not
reproduce the problem under kvm, even after waiting for four minutes.
I will leave it for more time, but it looks like I really might need to
ask Linaro for remote access to a Panda.

I have one. I'm currently installing Ubuntu on it and I'll try to
manage to build
a kernel and reproduce the issue.

I'll give more news soon.

Thank you!

My bet is that you have to have a userspace that is so small that it
registers only a few (but at least one!) RCU callback at boot time,
then never registers any callbacks ever again.  I have coded up a
crude test case, using Tony Lindgren's suggestion of "init=/bin/sh",
but I appear to have inadvertently fixed this bug in current -rcu
(git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git,
branch rcu/next).

But I have been wrong a few times already on this particular bug...

							Thanx, Paul