* 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 kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
