From: Frank Rowand <frank.rowand@am.sony.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
"dipankar@in.ibm.com" <dipankar@in.ibm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH RT 0/2][RFC] fix RCU stall warning on ARM
Date: Tue, 4 Dec 2012 21:05:29 -0800 [thread overview]
Message-ID: <50BED619.8060102@am.sony.com> (raw)
In-Reply-To: <50BED1DA.7070907@am.sony.com>
On 12/04/12 20:47, Frank Rowand wrote:
> The RCU stall warning functions call trigger_all_cpu_backtrace()
> to print a backtrace on each cpu. This function is only
> implemented for x86. Add a version for ARM.
>
> With CONFIG_PREEMPT_RT_FULL enabled, flushing the output from
> printk() is inhibited in some contexts to avoid increasing
> real time latencies. The RCU stall warnings are inhibited
> on ARM due to this feature. (I have not tested whether this
> is also the case on other architectures.) Add back the
> oops_in_progress flag to allow the RCU stall warnings to
> print immediately.
When I first implemented these patches on a locally modified
3.0.27-rt67, the call to "bust_spinlocks(0)" that I added to
print_cpu_stall() led to LOCKDEP warning of inconsistent
lock state from a trylock in serial_omap_console_write():
else if (oops_in_progress)
locked = spin_trylock_irqsave(&up->port.lock, flags);
If I understand correctly, the warning is triggered on the
slow lock path. Some more of the warning is:
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/1/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&(&port->lock)->lock)->wait_lock){?.+...}, at: [<c0478ed0>] rt_spin_trylock_irqsave+0x24/0xe0
...
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&(&port->lock)->lock)->wait_lock);
<Interrupt>
lock(&(&(&port->lock)->lock)->wait_lock);
I have not been able to trigger the warning on recent versions
of the patches, but I suspect the latent problem might still
exist.
-Frank
WARNING: multiple messages have this Message-ID (diff)
From: frank.rowand@am.sony.com (Frank Rowand)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RT 0/2][RFC] fix RCU stall warning on ARM
Date: Tue, 4 Dec 2012 21:05:29 -0800 [thread overview]
Message-ID: <50BED619.8060102@am.sony.com> (raw)
In-Reply-To: <50BED1DA.7070907@am.sony.com>
On 12/04/12 20:47, Frank Rowand wrote:
> The RCU stall warning functions call trigger_all_cpu_backtrace()
> to print a backtrace on each cpu. This function is only
> implemented for x86. Add a version for ARM.
>
> With CONFIG_PREEMPT_RT_FULL enabled, flushing the output from
> printk() is inhibited in some contexts to avoid increasing
> real time latencies. The RCU stall warnings are inhibited
> on ARM due to this feature. (I have not tested whether this
> is also the case on other architectures.) Add back the
> oops_in_progress flag to allow the RCU stall warnings to
> print immediately.
When I first implemented these patches on a locally modified
3.0.27-rt67, the call to "bust_spinlocks(0)" that I added to
print_cpu_stall() led to LOCKDEP warning of inconsistent
lock state from a trylock in serial_omap_console_write():
else if (oops_in_progress)
locked = spin_trylock_irqsave(&up->port.lock, flags);
If I understand correctly, the warning is triggered on the
slow lock path. Some more of the warning is:
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/1/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&(&port->lock)->lock)->wait_lock){?.+...}, at: [<c0478ed0>] rt_spin_trylock_irqsave+0x24/0xe0
...
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&(&port->lock)->lock)->wait_lock);
<Interrupt>
lock(&(&(&port->lock)->lock)->wait_lock);
I have not been able to trigger the warning on recent versions
of the patches, but I suspect the latent problem might still
exist.
-Frank
next prev parent reply other threads:[~2012-12-05 5:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-05 4:47 [PATCH RT 0/2][RFC] fix RCU stall warning on ARM Frank Rowand
2012-12-05 4:47 ` Frank Rowand
2012-12-05 4:52 ` [PATCH RT 1/2][RFC] ARM version of arch_trigger_all_cpu_backtrace() Frank Rowand
2012-12-05 4:52 ` Frank Rowand
2012-12-05 4:52 ` [PATCH RT 2/2][RFC] let RCU stall messages escape with CONFIG_PREEMPT_RT_FULL Frank Rowand
2012-12-05 4:52 ` Frank Rowand
2012-12-10 14:29 ` Paul E. McKenney
2012-12-10 14:29 ` Paul E. McKenney
2012-12-10 19:08 ` Frank Rowand
2012-12-10 19:08 ` Frank Rowand
2012-12-05 4:52 ` [PATCH RT 0/2][RFC] fix RCU stall warning on ARM Frank Rowand
2012-12-05 4:52 ` Frank Rowand
2012-12-05 5:05 ` Frank Rowand [this message]
2012-12-05 5:05 ` Frank Rowand
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=50BED619.8060102@am.sony.com \
--to=frank.rowand@am.sony.com \
--cc=dipankar@in.ibm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
/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.