All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca>
Cc: cpufreq@lists.linux.org.uk, Jeremy Fitzhardinge <jeremy@goop.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Suspend to RAM regression tracked down
Date: Sat, 8 Jul 2006 02:23:45 -0400	[thread overview]
Message-ID: <20060708062345.GB3356@redhat.com> (raw)
In-Reply-To: <1152312530.14453.16.camel@idefix.homelinux.org>

On Sat, Jul 08, 2006 at 08:48:49AM +1000, Jean-Marc Valin wrote:
 > Le vendredi 07 juillet 2006 à 12:21 -0400, Dave Jones a écrit :
 > > On Fri, Jul 07, 2006 at 09:25:37PM +1000, Jean-Marc Valin wrote:
 > >  > > There was a race in ondemand and conservative which made them lock up on 
 > >  > > resume (possibly only on SMP systems though).  There's a patch for that 
 > >  > > in current -mm, but I suspect there's another problem (still haven't had 
 > >  > > any time to track it down).
 > >  > 
 > >  > OK, I tried the patch with 2.6.17 and it didn't work. My laptop failed
 > >  > to resume on the first try, so it must be something else. Could someone
 > >  > actually have a look at the changes in 2.6.12-rc5-git6 (which happen to
 > >  > be cpufreq-related)? I spend months pinpointing the problem to that
 > >  > version (it's takes several days to reproduce). I'd appreciate if
 > >  > someone could at least have a look at what changed there and maybe fix
 > >  > it.
 > > 
 > > Can you show /proc/cpuinfo for the affected system ?
 > > If it's 15/3/4 or 15/4/1, that would explain why this kernel,
 > > as this was when support for those models got introduced to
 > > speedstep-centrino.
 > 
 > Not sure what's the 15/..., but here's the content:

it was the family, of which yours is 6, so this isn't it.
which means it must be ..

 > > If it's not that, there is a pretty large delta in the ondemand
 > > governor in this update, but I don't see anything blindlingly
 > > obvious from looking over it.
 > 
 > Well, is there some way of doing a bisection over these changes? As far
 > as I know, the problem probably affects all Dell D600 owners, probably
 > others.

If you're prepared to play around with 'git bisect' a little, it shouldn't
take that many iterations, as you've already narrowed it down quite a lot.

$ git bisect start drivers/cpufreq/cpufreq_ondemand.c
$ git bisect bad
$ git bisect good v2.6.12-rc5

should get you most of the way there.

http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
has more info.

		Dave

-- 
http://www.codemonkey.org.uk

WARNING: multiple messages have this Message-ID (diff)
From: Dave Jones <davej@redhat.com>
To: Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	cpufreq@lists.linux.org.uk
Subject: Re: Suspend to RAM regression tracked down
Date: Sat, 8 Jul 2006 02:23:45 -0400	[thread overview]
Message-ID: <20060708062345.GB3356@redhat.com> (raw)
In-Reply-To: <1152312530.14453.16.camel@idefix.homelinux.org>

On Sat, Jul 08, 2006 at 08:48:49AM +1000, Jean-Marc Valin wrote:
 > Le vendredi 07 juillet 2006 à 12:21 -0400, Dave Jones a écrit :
 > > On Fri, Jul 07, 2006 at 09:25:37PM +1000, Jean-Marc Valin wrote:
 > >  > > There was a race in ondemand and conservative which made them lock up on 
 > >  > > resume (possibly only on SMP systems though).  There's a patch for that 
 > >  > > in current -mm, but I suspect there's another problem (still haven't had 
 > >  > > any time to track it down).
 > >  > 
 > >  > OK, I tried the patch with 2.6.17 and it didn't work. My laptop failed
 > >  > to resume on the first try, so it must be something else. Could someone
 > >  > actually have a look at the changes in 2.6.12-rc5-git6 (which happen to
 > >  > be cpufreq-related)? I spend months pinpointing the problem to that
 > >  > version (it's takes several days to reproduce). I'd appreciate if
 > >  > someone could at least have a look at what changed there and maybe fix
 > >  > it.
 > > 
 > > Can you show /proc/cpuinfo for the affected system ?
 > > If it's 15/3/4 or 15/4/1, that would explain why this kernel,
 > > as this was when support for those models got introduced to
 > > speedstep-centrino.
 > 
 > Not sure what's the 15/..., but here's the content:

it was the family, of which yours is 6, so this isn't it.
which means it must be ..

 > > If it's not that, there is a pretty large delta in the ondemand
 > > governor in this update, but I don't see anything blindlingly
 > > obvious from looking over it.
 > 
 > Well, is there some way of doing a bisection over these changes? As far
 > as I know, the problem probably affects all Dell D600 owners, probably
 > others.

If you're prepared to play around with 'git bisect' a little, it shouldn't
take that many iterations, as you've already narrowed it down quite a lot.

$ git bisect start drivers/cpufreq/cpufreq_ondemand.c
$ git bisect bad
$ git bisect good v2.6.12-rc5

should get you most of the way there.

http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
has more info.

		Dave

-- 
http://www.codemonkey.org.uk

  reply	other threads:[~2006-07-08  6:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-02 10:47 Suspend to RAM regression tracked down Jean-Marc Valin
2006-07-02 18:06 ` Jeremy Fitzhardinge
2006-07-02 22:52   ` Jean-Marc Valin
2006-07-03  6:02     ` Jeremy Fitzhardinge
2006-07-03  6:31       ` Jean-Marc Valin
2006-07-03  6:08     ` Jeff Chua
2006-07-07 11:25   ` Jean-Marc Valin
2006-07-07 16:21     ` Dave Jones
2006-07-07 22:48       ` Jean-Marc Valin
2006-07-08  6:23         ` Dave Jones [this message]
2006-07-08  6:23           ` Dave Jones
2006-07-08 22:55           ` Jean-Marc Valin
2006-07-09  3:21             ` Dave Jones
2006-07-09  5:28               ` Jean-Marc Valin

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=20060708062345.GB3356@redhat.com \
    --to=davej@redhat.com \
    --cc=Jean-Marc.Valin@USherbrooke.ca \
    --cc=cpufreq@lists.linux.org.uk \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@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.