From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: linux-next: Tree for April 14 (Call-traces: RCU/ACPI/WQ related?) Date: Sun, 24 Apr 2011 09:43:31 -0700 Message-ID: <20110424164331.GN2628@linux.vnet.ibm.com> References: <20110422005046.GQ2235@linux.vnet.ibm.com> <20110422150222.GA2300@linux.vnet.ibm.com> <20110423210539.GI2628@linux.vnet.ibm.com> <20110424062728.GM2628@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from e2.ny.us.ibm.com ([32.97.182.142]:51821 "EHLO e2.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757651Ab1DXQng (ORCPT ); Sun, 24 Apr 2011 12:43:36 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-next-owner@vger.kernel.org List-ID: To: sedat.dilek@gmail.com Cc: Stephen Rothwell , linux-next@vger.kernel.org, LKML , peterz@infradead.org On Sun, Apr 24, 2011 at 11:36:44AM +0200, Sedat Dilek wrote: > On Sun, Apr 24, 2011 at 8:27 AM, Paul E. McKenney > wrote: [ . . . ] > > OK, this looks unrelated, but just in case, could you please try it > > again with the following patch? =A0(Not mainlinable, debug only.) > > > > Also, it does look like you are still seeing a grace-period hang. > > Could you please send the output of the script? =A0Same one as last= time. > > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanx, Paul > > > > -------------------------------------------------------------------= ----- > > > > =A0debugobjects.c | =A0 =A08 +++++--- > > =A01 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/lib/debugobjects.c b/lib/debugobjects.c > > index 9d86e45..10a7c7a 100644 > > --- a/lib/debugobjects.c > > +++ b/lib/debugobjects.c > > @@ -289,10 +289,12 @@ static void debug_object_is_on_stack(void *ad= dr, int onstack) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return; > > > > =A0 =A0 =A0 =A0limit++; > > - =A0 =A0 =A0 if (is_on_stack) > > + =A0 =A0 =A0 if (is_on_stack) { > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct rcu_head *p =3D (struct rcu_he= ad *)addr; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_WARNING > > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"ODEBUG: object is on = stack, but not annotated\n"); > > - =A0 =A0 =A0 else > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"ODEBUG: object is on = stack, but not annotated: %p\n", > > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0p->func); > > + =A0 =A0 =A0 } else > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printk(KERN_WARNING > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "ODEBUG: object is not = on stack, but annotated\n"); > > =A0 =A0 =A0 =A0WARN_ON(1); > > >=20 > Somehow your attached patch was not applicable. > As the changes were a few lines I applied it by myself. > Attached are log, dmesg and patches (orig + mine) Hmmm... Does 0xc10231a1 correspond to a function in your build? If so= , could you please let me know which one? OK, so according to "ps" the per-CPU kthread is runnable, but it appear= s to never run. You only have one CPU, so it cannot be waiting due to running on the wrong CPU. The only other loop is in wait_event(), and that code looks good -- besides, if wait_event() was broken, we would be seeing breakage everywhere. Peter, any thoughts on what I might have done wrong to get the schedule= r into a state where it was ignoring a runnable realtime task? Thanx, Paul