All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Arend van Spriel <arend@broadcom.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	"Paul E. McKenney" <paul.mckenney@linaro.org>
Subject: Re: REGRESSION: 3.10-rc1: Dell Latitude e6410 hangs within 3 seconds
Date: Fri, 17 May 2013 18:47:25 -0700	[thread overview]
Message-ID: <20130518014724.GA4006@linux.vnet.ibm.com> (raw)
In-Reply-To: <519697CC.1070308@broadcom.com>

On Fri, May 17, 2013 at 10:49:16PM +0200, Arend van Spriel wrote:
> On 05/14/2013 10:38 PM, Arend van Spriel wrote:
> >On 05/14/2013 10:34 PM, Rafael J. Wysocki wrote:
> >>On Tuesday, May 14, 2013 03:03:58 PM Arend van Spriel wrote:
> >>>Laptop hangs pretty soon after booting. Workaround for me was to turn
> >>>off ACPI on kernel command line, ie. acpi=off
> >>>
> >>>Attached is my kernel configuration.
> >>
> >>Well, I have no idea what may be the source of this.
> >
> >Me neither.
> >
> >>Any chance to bisect?
> >
> >can try. Rebuilding kernels can be a drag :-p
> >
> >Regards,
> >Arend
> 
> Hi Rafael,
> 
> The bisect result found commit c0f4dfd4f as culprit. I also verified
> that the merge into Linus' tree introduced the issue upstream, ie.
> 6c24499 works and 1f889ec does not. I tried to revert the commit,
> but that was a bit risky (conflict to resolve) and did not give me a
> stable kernel. The only thing that works is selecting acpi=off. I
> tried also nohz=off but that resulted in /init failure.
> 
> Regards,
> Arend
> 
> ---8<----------------------------------------------------------------
> 
> commit 1f889ec62c3f0d8913f3c32f9aff2a1e15099346
>   Merge: 6c24499 8fcfae3
> 
>   commit 8fcfae31719c0a6c03f2cf63f815b46d378d8be4
>     Merge: d02a9a8 6d87669
> 
>     commit 6d87669357936bffa1e8fea7a4e7743e76905736
>       Merge: 3f944ad 81e5949 910ee45
> 
>       commit c0f4dfd4f90f1667d234d21f15153ea09a2eaa66
>       Author: Paul E. McKenney <paul.mckenney@linaro.org>
>       Date:   Fri Dec 28 11:30:36 2012 -0800
> 
>           rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks
> 
>           Because RCU callbacks are now associated with the number
>           of the grace period that they must wait for, CPUs can now
>           take advance callbacks corresponding to grace periods that
>           ended while a given CPU was in dyntick-idle mode. This
>           eliminates the need to try forcing the RCU state machine
>           while entering idle, thus reducing the CPU intensiveness
>           of RCU_FAST_NO_HZ, which should increase its energy
>           efficiency.
> 
>       Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
>       Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

Hello, Arend,

Thank you for tracking this down!  Could you please try out the following
patch?

							Thanx, Paul

------------------------------------------------------------------------

rcu: Fix comparison sense in rcu_needs_cpu()

Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
callbacks) introduced a bug that can result in excessively long grace
periods.  This bug reverse the senes of the "if" statement checking
for lazy callbacks, so that RCU takes a lazy approach when there are
in fact non-lazy callbacks.  This can result in excessive boot, suspend,
and resume times.

This commit therefore fixes the sense of this "if" statement.

Reported-by: Borislav Petkov <bp@alien8.de>
Reported-by: Bjørn Mork <bjorn@mork.no>
Reported-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Bjørn Mork <bjorn@mork.no>
Tested-by: Joerg Roedel <joro@8bytes.org>

diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 170814d..6d939a6 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -1667,7 +1667,7 @@ int rcu_needs_cpu(int cpu, unsigned long *dj)
 	rdtp->last_accelerate = jiffies;
 
 	/* Request timer delay depending on laziness, and round. */
-	if (rdtp->all_lazy) {
+	if (!rdtp->all_lazy) {
 		*dj = round_up(rcu_idle_gp_delay + jiffies,
 			       rcu_idle_gp_delay) - jiffies;
 	} else {

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Arend van Spriel <arend@broadcom.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	"Paul E. McKenney" <paul.mckenney@linaro.org>
Subject: Re: REGRESSION: 3.10-rc1: Dell Latitude e6410 hangs within 3 seconds
Date: Fri, 17 May 2013 18:47:25 -0700	[thread overview]
Message-ID: <20130518014724.GA4006@linux.vnet.ibm.com> (raw)
In-Reply-To: <519697CC.1070308@broadcom.com>

On Fri, May 17, 2013 at 10:49:16PM +0200, Arend van Spriel wrote:
> On 05/14/2013 10:38 PM, Arend van Spriel wrote:
> >On 05/14/2013 10:34 PM, Rafael J. Wysocki wrote:
> >>On Tuesday, May 14, 2013 03:03:58 PM Arend van Spriel wrote:
> >>>Laptop hangs pretty soon after booting. Workaround for me was to turn
> >>>off ACPI on kernel command line, ie. acpi=off
> >>>
> >>>Attached is my kernel configuration.
> >>
> >>Well, I have no idea what may be the source of this.
> >
> >Me neither.
> >
> >>Any chance to bisect?
> >
> >can try. Rebuilding kernels can be a drag :-p
> >
> >Regards,
> >Arend
> 
> Hi Rafael,
> 
> The bisect result found commit c0f4dfd4f as culprit. I also verified
> that the merge into Linus' tree introduced the issue upstream, ie.
> 6c24499 works and 1f889ec does not. I tried to revert the commit,
> but that was a bit risky (conflict to resolve) and did not give me a
> stable kernel. The only thing that works is selecting acpi=off. I
> tried also nohz=off but that resulted in /init failure.
> 
> Regards,
> Arend
> 
> ---8<----------------------------------------------------------------
> 
> commit 1f889ec62c3f0d8913f3c32f9aff2a1e15099346
>   Merge: 6c24499 8fcfae3
> 
>   commit 8fcfae31719c0a6c03f2cf63f815b46d378d8be4
>     Merge: d02a9a8 6d87669
> 
>     commit 6d87669357936bffa1e8fea7a4e7743e76905736
>       Merge: 3f944ad 81e5949 910ee45
> 
>       commit c0f4dfd4f90f1667d234d21f15153ea09a2eaa66
>       Author: Paul E. McKenney <paul.mckenney@linaro.org>
>       Date:   Fri Dec 28 11:30:36 2012 -0800
> 
>           rcu: Make RCU_FAST_NO_HZ take advantage of numbered callbacks
> 
>           Because RCU callbacks are now associated with the number
>           of the grace period that they must wait for, CPUs can now
>           take advance callbacks corresponding to grace periods that
>           ended while a given CPU was in dyntick-idle mode. This
>           eliminates the need to try forcing the RCU state machine
>           while entering idle, thus reducing the CPU intensiveness
>           of RCU_FAST_NO_HZ, which should increase its energy
>           efficiency.
> 
>       Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org>
>       Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

Hello, Arend,

Thank you for tracking this down!  Could you please try out the following
patch?

							Thanx, Paul

------------------------------------------------------------------------

rcu: Fix comparison sense in rcu_needs_cpu()

Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
callbacks) introduced a bug that can result in excessively long grace
periods.  This bug reverse the senes of the "if" statement checking
for lazy callbacks, so that RCU takes a lazy approach when there are
in fact non-lazy callbacks.  This can result in excessive boot, suspend,
and resume times.

This commit therefore fixes the sense of this "if" statement.

Reported-by: Borislav Petkov <bp@alien8.de>
Reported-by: Bjørn Mork <bjorn@mork.no>
Reported-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Bjørn Mork <bjorn@mork.no>
Tested-by: Joerg Roedel <joro@8bytes.org>

diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 170814d..6d939a6 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -1667,7 +1667,7 @@ int rcu_needs_cpu(int cpu, unsigned long *dj)
 	rdtp->last_accelerate = jiffies;
 
 	/* Request timer delay depending on laziness, and round. */
-	if (rdtp->all_lazy) {
+	if (!rdtp->all_lazy) {
 		*dj = round_up(rcu_idle_gp_delay + jiffies,
 			       rcu_idle_gp_delay) - jiffies;
 	} else {


  parent reply	other threads:[~2013-05-18  1:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-14 13:03 REGRESSION: 3.10-rc1: Dell Latitude e6410 hangs within 3 seconds Arend van Spriel
2013-05-14 20:34 ` Rafael J. Wysocki
2013-05-14 20:38   ` Arend van Spriel
2013-05-17 20:49     ` Arend van Spriel
2013-05-17 23:45       ` Rafael J. Wysocki
2013-05-18  1:47       ` Paul E. McKenney [this message]
2013-05-18  1:47         ` Paul E. McKenney
2013-05-18  7:14         ` Arend van Spriel
2013-05-18  7:14           ` Arend van Spriel
2013-05-18 23:06           ` Paul E. McKenney
2013-05-18 23:06             ` 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=20130518014724.GA4006@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=arend@broadcom.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul.mckenney@linaro.org \
    --cc=rjw@sisk.pl \
    /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.