From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Jochen Striepe <jochen@tolot.escape.de>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: 3.10.5: rcu_sched detected stalls on CPUs/tasks
Date: Tue, 10 Sep 2013 10:54:53 -0700 [thread overview]
Message-ID: <20130910175453.GQ3966@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130910074550.GE17483@pompeji.miese-zwerge.org>
On Tue, Sep 10, 2013 at 09:45:50AM +0200, Jochen Striepe wrote:
> Hello,
>
> On Mon, Sep 09, 2013 at 03:27:51PM -0700, Paul E. McKenney wrote:
> > On Mon, Sep 09, 2013 at 11:58:36PM +0200, Jochen Striepe wrote:
> > > I just got this on 3.10.11 on the same machine. Could that be
> > > related?
> >
> > Several people helped track down another source of spurious stall
> > warnings on large systems, please see below for the patch.
> [...]
> > This is quite rare, but apparently occurs deterministically
> > on systems with about 6TB of memory.
>
> Hmm. My system is an ASUS Eee PC netbook with a total of 2G memory.
> The latest stall was just when booting, while /dev was to be filled
> by udev (and taking a really long time on that). So I think this
> patch should not help at my machine, right?
>
> I tried to reproduce the stall, but without success. Is there anything
> that could help reproducing?
Their stall was due to old-style creation of sysfs entries for memory.
Yours might be having a similar issue with the creation of /dev entries,
so it would be worth trying it.
One thing to try would be to insert delays into the code involved in
creating the /dev entries. These delays will need to be busy-waits
rather than sleeps.
Thanx, Paul
next prev parent reply other threads:[~2013-09-10 17:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-13 10:32 3.10.5: rcu_sched detected stalls on CPUs/tasks Jochen Striepe
2013-08-18 18:02 ` Paul E. McKenney
2013-08-18 18:48 ` Jochen Striepe
2013-09-09 21:58 ` Jochen Striepe
2013-09-09 22:27 ` Paul E. McKenney
2013-09-10 7:45 ` Jochen Striepe
2013-09-10 17:54 ` Paul E. McKenney [this message]
2013-09-11 10:34 ` Jochen Striepe
2013-09-14 11:28 ` Jochen Striepe
2013-09-14 18:36 ` Paul E. McKenney
2013-09-23 16:49 ` Jochen Striepe
2013-12-06 0:26 ` Paul E. McKenney
2013-12-06 13:58 ` Jochen Striepe
2013-12-06 14:54 ` Paul E. McKenney
2013-12-10 11:22 ` Jochen Striepe
2013-12-16 22:40 ` Paul E. McKenney
2013-12-22 2:25 ` Jochen Striepe
2013-12-22 4:58 ` Paul E. McKenney
2013-12-27 17:15 ` Jochen Striepe
2013-12-27 18:08 ` 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=20130910175453.GQ3966@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=jochen@tolot.escape.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.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 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.