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

Ingo Molnar
2009-01-11T16:39:04Z

* Christian Borntraeger <borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> wrote:

> Am Sonntag 11 Januar 2009 schrieb Ingo Molnar:
> >
> > * Jeff Chua <jeff.chua.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > On Sun, Jan 11, 2009 at 10:18 PM, Christian Borntraeger
> > > <borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > > >> > 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