Re: [Bug #12422] 2.6.28-git can't resume from str

[Ingo Molnar]

* Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:

> Am Sonntag 11 Januar 2009 schrieb Ingo Molnar:
> > 
> > * Jeff Chua <jeff.chua.linux@xxxxxxxxx> wrote:
> > 
> > > On Sun, Jan 11, 2009 at 10:18 PM, Christian Borntraeger
> > > <borntraeger@xxxxxxxxxx> wrote:
> > > > Am Sonntag 11 Januar 2009 schrieb Daniel Drake:
> > > >> Rafael J. Wysocki wrote:
> > > >> > This message has been generated automatically as a part of a report
> > > >> > of recent regressions.
> > > >> >
> > > >> > The following bug entry is on the current list of known regressions
> > > >> > from 2.6.28.  Please verify if it still should be listed and let me 
> know
> > > >> > (either way).
> > > >> >
> > > >> >
> > > >> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=12422
> > > >> > Subject             : 2.6.28-git can't resume from str
> > > >> > Submitter   : Jeff Chua <jeff.chua.linux@xxxxxxxxx>
> > > >> > Date                : 2009-01-10 1:39 (2 days old)
> > > >> > References  : http://marc.info/?l=linux-kernel&m=123155157909282&w=4
> > > >>
> > > >> The bisection looks invalid. It is unlikely to be this commit at fault.
> > > >> Jeff, do you even have that camera?
> > > >>
> > > >> It is also easy to revert that commit by hand. Just delete the
> > > >> unusual_devs entry for it.
> > > >
> > > > I found a nearby commit during bisect, which looks much saner:
> > > >
> > > > http://marc.info/?l=linux-kernel&m=123167815028388&w=2
> > > 
> > > This was committed earlier than
> > > a0e280e0f33f6c859a235fb69a875ed8f3420388, and
> > > a0e280e0f33f6c859a235fb69a875ed8f3420388 was the last working kernel
> > > that is able to suspend/resume. Go one before, and suspend/resume
> > > breaks.
> > 
> > so you mean a0e280e0f33f6c859a235fb69a875ed8f3420388 seems good, while the 
> > next step in Linus's tree, 52fefcec97c25b15887e6a9a885ca54e7f7c0928 is 
> > already broken?
> 
> I guess Jeff, meant the other way around.
> Since a0e280e0f33f6c859a235fb69a875ed8f3420388 is a fix for a known S2R 
> problem , the earlier patch (before) does of course not work.

ah, okay.

So i suspect that at every bisection point, this should be done:

  git cherry-pick a0e280e0f33f6c859a235fb69a875ed8f3420388

To make sure the bisection finds the secondary breakage too.

(the cherry-pick will fail harmlessly on kernels that have that commit 
already - so it can be done unconditionally at every bisection point.)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/