Messages in this thread | | | Date | Sat, 22 Sep 2012 09:00:31 -0700 | From | "Paul E. McKenney" <> | Subject | Re: rcu self-detected stall messages on OMAP3, 4 boards |
| |
On Sat, Sep 22, 2012 at 05:45:12PM +0200, Frederic Weisbecker wrote: > 2012/9/22 Paul E. McKenney <paulmck@linux.vnet.ibm.com>: > > On Fri, Sep 21, 2012 at 01:31:49PM -0700, Tony Lindgren wrote: > >> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> [120921 12:58]: > >> > > >> > 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
| |