From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: "Bruce, Becky" <bbruce@ti.com>,
"Paul E. McKenney" <paul.mckenney@linaro.org>,
"<linux-kernel@vger.kernel.org>" <linux-kernel@vger.kernel.org>,
"<linux-omap@vger.kernel.org>" <linux-omap@vger.kernel.org>,
"<linux-arm-kernel@lists.infradead.org>"
<linux-arm-kernel@lists.infradead.org>,
"Hilman, Kevin" <khilman@ti.com>,
"Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
"Hunter, Jon" <jon-hunter@ti.com>,
"<snijsure@grid-net.com>" <snijsure@grid-net.com>,
fweisbec@gmail.com
Subject: Re: rcu self-detected stall messages on OMAP3, 4 boards
Date: Fri, 21 Sep 2012 11:58:27 -0700 [thread overview]
Message-ID: <20120921185827.GC2454@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1209211803290.8839@utopia.booyaka.com>
On Fri, Sep 21, 2012 at 06:08:59PM +0000, Paul Walmsley wrote:
> cc Frederic Weisbecker - context is here:
>
> http://marc.info/?l=linux-kernel&m=134749030206016&w=2
>
> On Thu, 20 Sep 2012, Paul E. McKenney wrote:
>
> > Fair point. I am wondering whether there is some path into the idle
> > loop that somehow avoids telling RCU that the CPU has in face entered
> > idle. There needs to be an rcu_idle_enter() call on the way to idle,
> > otherwise RCU CPU stall warnings are expected behavior.
>
> As far as I know, our only idle entry point is in
> arch/arm/common/process.c:cpu_idle().
In mainline, this is arch/arm/kernel/process.c, correct?
> Looking at the x86 idle entry, they call rcu_idle_{enter,exit}() inside
> {stop,start}_critical_timings(). Making that change here didn't help.
The reason x86 does this is that they have idle notifiers deeper in the
idle loop that use RCU read-side critical sections. So this was an
expected result.
> Also tried commenting out the code from the stop_critical_timings() call
> to the WARN_ON(irqs_disabled()), and adding a local_irq_enable(). That
> also didn't help, which suggests that the problem is not caused by the
> OMAP-specific PM idle code.
I must admit that you make a convincing case here. Though it does leave
me wondering what is different about Panda (and MX28, IIRC).
I may take your advice of remote access to a Panda board, though that
is likely to take a bit of time due to timezones. Regardless of the
underlying issue here, I clearly need to make the stall-warning messages
do a better job of printing out needed information.
Thanx, Paul
WARNING: multiple messages have this Message-ID (diff)
From: paulmck@linux.vnet.ibm.com (Paul E. McKenney)
To: linux-arm-kernel@lists.infradead.org
Subject: rcu self-detected stall messages on OMAP3, 4 boards
Date: Fri, 21 Sep 2012 11:58:27 -0700 [thread overview]
Message-ID: <20120921185827.GC2454@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1209211803290.8839@utopia.booyaka.com>
On Fri, Sep 21, 2012 at 06:08:59PM +0000, Paul Walmsley wrote:
> cc Frederic Weisbecker - context is here:
>
> http://marc.info/?l=linux-kernel&m=134749030206016&w=2
>
> On Thu, 20 Sep 2012, Paul E. McKenney wrote:
>
> > Fair point. I am wondering whether there is some path into the idle
> > loop that somehow avoids telling RCU that the CPU has in face entered
> > idle. There needs to be an rcu_idle_enter() call on the way to idle,
> > otherwise RCU CPU stall warnings are expected behavior.
>
> As far as I know, our only idle entry point is in
> arch/arm/common/process.c:cpu_idle().
In mainline, this is arch/arm/kernel/process.c, correct?
> Looking at the x86 idle entry, they call rcu_idle_{enter,exit}() inside
> {stop,start}_critical_timings(). Making that change here didn't help.
The reason x86 does this is that they have idle notifiers deeper in the
idle loop that use RCU read-side critical sections. So this was an
expected result.
> Also tried commenting out the code from the stop_critical_timings() call
> to the WARN_ON(irqs_disabled()), and adding a local_irq_enable(). That
> also didn't help, which suggests that the problem is not caused by the
> OMAP-specific PM idle code.
I must admit that you make a convincing case here. Though it does leave
me wondering what is different about Panda (and MX28, IIRC).
I may take your advice of remote access to a Panda board, though that
is likely to take a bit of time due to timezones. Regardless of the
underlying issue here, I clearly need to make the stall-warning messages
do a better job of printing out needed information.
Thanx, Paul
next prev parent reply other threads:[~2012-09-21 18:58 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 22:51 rcu self-detected stall messages on OMAP3, 4 boards Paul Walmsley
2012-09-12 22:51 ` Paul Walmsley
2012-09-13 1:12 ` Paul E. McKenney
2012-09-13 1:12 ` Paul E. McKenney
2012-09-13 18:52 ` Paul Walmsley
2012-09-13 18:52 ` Paul Walmsley
2012-09-20 0:03 ` Paul E. McKenney
2012-09-20 0:03 ` Paul E. McKenney
2012-09-20 0:03 ` Paul E. McKenney
2012-09-20 7:56 ` Paul Walmsley
2012-09-20 7:56 ` Paul Walmsley
2012-09-20 15:03 ` Bruce, Becky
2012-09-20 15:03 ` Bruce, Becky
2012-09-20 21:49 ` Bruce, Becky
2012-09-20 21:49 ` Bruce, Becky
2012-09-20 22:01 ` Paul E. McKenney
2012-09-20 22:01 ` Paul E. McKenney
2012-09-20 22:01 ` Paul E. McKenney
2012-09-20 22:47 ` Paul Walmsley
2012-09-20 22:47 ` Paul Walmsley
2012-09-20 23:21 ` Paul E. McKenney
2012-09-20 23:21 ` Paul E. McKenney
2012-09-20 23:21 ` Paul E. McKenney
2012-09-21 18:08 ` Paul Walmsley
2012-09-21 18:08 ` Paul Walmsley
2012-09-21 18:58 ` Paul E. McKenney [this message]
2012-09-21 18:58 ` Paul E. McKenney
2012-09-21 19:11 ` Paul Walmsley
2012-09-21 19:11 ` Paul Walmsley
2012-09-21 19:57 ` Paul E. McKenney
2012-09-21 19:57 ` Paul E. McKenney
2012-09-21 20:31 ` Tony Lindgren
2012-09-21 20:31 ` Tony Lindgren
2012-09-21 22:03 ` Paul E. McKenney
2012-09-21 22:03 ` Paul E. McKenney
2012-09-22 15:45 ` Frederic Weisbecker
2012-09-22 15:45 ` Frederic Weisbecker
2012-09-22 16:00 ` Paul E. McKenney
2012-09-22 16:00 ` Paul E. McKenney
2012-09-21 22:12 ` Paul E. McKenney
2012-09-21 22:12 ` Paul E. McKenney
2012-09-22 18:42 ` Paul Walmsley
2012-09-22 18:42 ` Paul Walmsley
2012-09-22 20:10 ` Paul E. McKenney
2012-09-22 20:10 ` Paul E. McKenney
2012-09-22 21:59 ` Paul E. McKenney
2012-09-22 21:59 ` Paul E. McKenney
2012-09-22 22:25 ` Paul Walmsley
2012-09-22 22:25 ` Paul Walmsley
2012-09-22 23:11 ` Paul E. McKenney
2012-09-22 23:11 ` Paul E. McKenney
2012-09-22 23:11 ` Paul E. McKenney
2012-09-23 7:55 ` Paul Walmsley
2012-09-23 7:55 ` Paul Walmsley
2012-09-23 7:55 ` Paul Walmsley
2012-09-23 12:11 ` Paul E. McKenney
2012-09-23 12:11 ` Paul E. McKenney
2012-09-23 12:11 ` Paul E. McKenney
2012-09-23 1:42 ` Paul Walmsley
2012-09-23 1:42 ` Paul Walmsley
2012-09-23 1:56 ` Paul E. McKenney
2012-09-23 1:56 ` Paul E. McKenney
2012-09-23 1:56 ` Paul E. McKenney
2012-09-23 2:01 ` Paul Walmsley
2012-09-23 2:01 ` Paul Walmsley
2012-09-24 9:41 ` Shilimkar, Santosh
2012-09-24 9:41 ` Shilimkar, Santosh
2012-09-24 13:18 ` Paul E. McKenney
2012-09-24 13:18 ` Paul E. McKenney
2012-10-01 8:55 ` Linus Walleij
2012-10-01 8:55 ` Linus Walleij
2012-10-01 13:28 ` Paul E. McKenney
2012-10-01 13:28 ` Paul E. McKenney
2012-09-21 18:59 ` Paul Walmsley
2012-09-21 18:59 ` Paul Walmsley
2012-09-21 17:47 ` Paul Walmsley
2012-09-21 17:47 ` Paul Walmsley
2012-09-21 17:51 ` Paul Walmsley
2012-09-21 17:51 ` Paul Walmsley
2012-09-21 21:20 ` Paul E. McKenney
2012-09-21 21:20 ` Paul E. McKenney
2012-09-21 21:20 ` Paul E. McKenney
2012-09-21 22:41 ` Paul Walmsley
2012-09-21 22:41 ` Paul Walmsley
2012-09-22 0:05 ` Paul E. McKenney
2012-09-22 0:05 ` Paul E. McKenney
2012-09-22 18:16 ` Paul Walmsley
2012-09-22 18:16 ` Paul Walmsley
2012-09-22 18:16 ` Paul Walmsley
2012-09-22 19:52 ` Paul E. McKenney
2012-09-22 19:52 ` Paul E. McKenney
2012-09-22 19:52 ` Paul E. McKenney
2012-09-22 22:20 ` Paul Walmsley
2012-09-22 22:20 ` Paul Walmsley
2012-09-22 22:20 ` Paul Walmsley
2012-09-22 23:17 ` Paul E. McKenney
2012-09-22 23:17 ` Paul E. McKenney
2012-09-24 21:54 ` Paul Walmsley
2012-09-24 21:54 ` Paul Walmsley
2012-09-24 22:00 ` Paul E. McKenney
2012-09-24 22:00 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120921185827.GC2454@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=bbruce@ti.com \
--cc=fweisbec@gmail.com \
--cc=jon-hunter@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul.mckenney@linaro.org \
--cc=paul@pwsan.com \
--cc=santosh.shilimkar@ti.com \
--cc=snijsure@grid-net.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.