[Xen-devel] Re: PROBLEM: 3.0-rc kernels unbootable since -rc3

["Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>]

On Tue, Jul 12, 2011 at 02:01:51PM -0400, Konrad Rzeszutek Wilk wrote:
> > > http://darnok.org/xen/loop_cnt.log
> > > 
> > > which seems to imply that we are indeed stuck in that loop
> > > forever.
> > 
> > It does indeed, thank you!  Also it looks like interrupts are
> > disabled, and that timekeeping is similarly out of action.
> 
> .. With the latest patch the time looks to be advancing.

Sounds like an improvement.  ;-)

> > Disabling CONFIG_NO_HZ would be an interesting test case.
> 
> Hadn't done that yet. Compiling a kernel with "# CONFIG_NO_HZ is not set"
> right now.
> > 
> > > > o       Problems due to portions of the code attempting to use
> > > >         RCU read-side critical sections while in dyntick-idle mode.
> > > >         Frederic Weisbecker has located some of these, (though not yet
> > > >         in Xen) and he has some diagnositics which may be found at:
> > > > 
> > > >         
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
> > > > 
> > > >         on branch eqscheck.2011.07.08a.
> > > > 
> > > >         You need to enable CONFIG_PROVE_RCU for these diagnostics to
> > > >         be executed.
> > > 
> > > Ok, let me try those too.
> > 
> > Thank you!
> 
> Will shortly do this.
> > 
> > > > o       As always, there might be bugs in RCU.  ;-)
> > > > 
> > > > But the loop in task_waking_fair() looks like the most prominent smoking
> > > > gun at the moment.
> > 
> > And could you also please try out the patch that I posted earlier?
> 
> With the previous patch and the .. this is getting confusing. With this patch:
> http://darnok.org/xen/loop_cnt-extra.patch

That is indeed the patch I intended.

> I get this output: http://darnok.org/xen/log.loop_cnt-extra-patch (one guest
> with 4 VCPUS) and http://darnok.org/xen/loop_cnt-extra-patch.log (the guest 
> with 16 VCPUs)

OK, so the infinite loop in task_waking_fair() happens even if RCU callbacks
are deferred until after the scheduler is fully initialized.  Sounds like
one for the scheduler guys.  ;-)

                                                        Thanx, Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel