From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Jones <davej@redhat.com>, Hugh Dickins <hughd@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Paul McKenney <paul.mckenney@linaro.org>
Subject: Re: Debugging Thinkpad T430s occasional suspend failure.
Date: Fri, 15 Feb 2013 09:44:35 -0800 [thread overview]
Message-ID: <20130215174435.GA2792@linux.vnet.ibm.com> (raw)
In-Reply-To: <CA+55aFyVE0jyu9uw659ERw5E2DdOhwkQp3gk=gcXP0xrmMh9qA@mail.gmail.com>
On Thu, Feb 14, 2013 at 06:09:44PM -0800, Linus Torvalds wrote:
> On Thu, Feb 14, 2013 at 5:15 PM, Dave Jones <davej@redhat.com> wrote:
> >
> > Given I never saw this on a Fedora kernel, just my self-built ones, I eventually
> > gave up on bisecting code, and switched to bisecting config options.
> > I should have started this way, as I figured it out within an hour.
> >
> > 3.7 merge window is when I started seeing this, and here's what got introduced
> > during that time..
> >
> > commit e3ebfb96f396731ca2d0b108785d5da31b53ab00
> > Author: Paul E. McKenney <paul.mckenney@linaro.org>
> > Date: Mon Jul 2 14:42:01 2012 -0700
> >
> > rcu: Add PROVE_RCU_DELAY to provoke difficult races
> >
> > 'difficult' is an understatement. This explains why some of those 'good'
> > bisects survived 100 suspends on one day, and failed the next.
> >
> > Unfortunatly, I don't think there's any sane way to retrieve whatever debug
> > info might be getting spewed.
>
> Hmm. I have to say, that's a particularly unhelpful config option. It
> may make races much easier to hit, but when you do hit them, what's
> the symptoms of said race?
>
> Paul? Apparently you end up with a dead machine at least during resume
> and no oops. Which isn't very helpful. Maybe there is possibly some
> BUG_ON() in the RCU code somewhere?
>
> So Paul, if you know what the common symptoms of the bug that that
> debug option helps trigger are, is there some way to make them less
> lethal and still print out useful information?
This commit was designed to increase the probability of hitting the
races described in http://lwn.net/Articles/453002/. These races result
in deadlocks involving the runqueue lock (and perhaps also the priority
inheritance locks). And yes, I most certainly should have described
this in the commit message. :-(
So it looks like Dave is hitting some other race/bug than the one that
this commit was designed to expose.
I must confess that I don't know how to proceed without any meaningful
debug information here. Feel free to revert the above commit if you would
like -- I can of course always maintain it locally for my own testing.
Thanx, Paul
next prev parent reply other threads:[~2013-02-15 17:45 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 19:39 Dave Jones
2013-02-12 20:13 ` Linus Torvalds
2013-02-13 0:26 ` Hugh Dickins
2013-02-13 0:40 ` Dave Jones
2013-02-13 0:56 ` Hugh Dickins
2013-02-13 4:16 ` Dave Jones
2013-02-13 5:37 ` Hugh Dickins
2013-02-13 19:34 ` Dave Jones
2013-02-13 19:56 ` Linus Torvalds
2013-02-13 20:53 ` Dave Jones
2013-02-16 20:54 ` Paul E. McKenney
2013-02-15 1:15 ` Dave Jones
2013-02-15 2:09 ` Linus Torvalds
2013-02-15 15:50 ` Ingo Molnar
2013-02-15 22:33 ` Dave Jones
2013-02-15 17:44 ` Paul E. McKenney [this message]
2013-02-15 18:34 ` Linus Torvalds
2013-02-15 18:35 ` Linus Torvalds
2013-02-15 18:50 ` Linus Torvalds
2013-02-16 19:25 ` Paul E. McKenney
2013-02-16 19:46 ` Linus Torvalds
2013-02-16 21:07 ` Paul E. McKenney
2013-02-16 21:53 ` H. Peter Anvin
2013-02-17 22:49 ` H. Peter Anvin
2013-02-18 8:41 ` Ingo Molnar
2013-02-19 8:50 ` Paul E. McKenney
2013-02-19 8:56 ` Ingo Molnar
2013-02-17 15:11 ` Frederic Weisbecker
2013-02-17 17:32 ` Linus Torvalds
2013-02-17 18:17 ` Frederic Weisbecker
2013-02-17 20:58 ` Frederic Weisbecker
2013-02-17 21:02 ` Frederic Weisbecker
2013-02-18 15:53 ` Frederic Weisbecker
2013-02-18 18:12 ` Linus Torvalds
2013-02-19 10:08 ` Frederic Weisbecker
2013-02-18 19:58 ` Thomas Gleixner
2013-02-19 10:38 ` Frederic Weisbecker
2013-02-19 10:44 ` Thomas Gleixner
2013-02-15 2:09 ` Hugh Dickins
2013-02-15 2:15 ` Linus Torvalds
2013-02-16 21:45 ` Hugh Dickins
2013-02-16 23:02 ` Linus Torvalds
2013-02-17 0:01 ` Hugh Dickins
2013-02-17 2:21 ` Hugh Dickins
2013-02-17 13:38 ` Daniel Vetter
2013-02-17 14:54 ` Daniel Vetter
2013-02-17 16:31 ` Hugh Dickins
2013-02-17 17:28 ` Daniel Vetter
2013-02-13 2:17 ` Dave Jones
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=20130215174435.GA2792@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=davej@redhat.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paul.mckenney@linaro.org \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome