[lkml]   [2009]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: T400 suspend/resume regression -- bisected to a mystery merge commit

On Sat, 26 Sep 2009, Theodore Ts'o wrote:
> One of the things I've been trying to track for the last couple of days
> is a suspend/resume regression which I've noticed on my T400 Lenovo
> laptop. I first noticed it on a 2.6.31-git9 kernel with a some
> additional ext4 patches. I've since bisected it to the following merge
> commit: a03fdb76. The commit does have some merge conflict fix ups, but
> only for the some files in the m68knommu and mips architectures.

Yeah, no conflicts on the x86 side. But there can obviously be
interactions between the timer changes and the other changes, although
looking at it that does look rather unlikely.

One thing that _can_ be done for these kinds of merge conflicts is to just
turn the merge into rebase, and then bisecting that rebase. So in this
case, you could do something like this:

# Check out the timer side of the merge
git checkout -b timer-branch a03fdb76^2

# instead of merging it into the mainline, rebase it on top of it
git rebase a03fdb76^

# resolve the trivial problem in arch/mips/lemote/lm2e/setup.c
# the same way the merge did (do the 'git add' just to make
# checkout happy
git rm arch/mips/lemote/lm2e/setup.c
git rebase --continue

and now you have the exact same tree as the merge resulted in (apart from
the 'arch/mips/loongson/common/time.c' that was broken in the merge
anyway, but that also doesn't matter), and now you can bisect the series
and see exactly _which_ commit it is that has problems.

So now you can just bisect it by doing

git bisect start
git bisect bad timer-branch
git bisect good a03fdb76

and off you go.

The above is a generic way to handle bisection problems with merges,
although admittedly it only really works in practice for the simple cases
(if there is lots and lots of independent development on both sides, it's
not going to be a reasonable thing to do).

That said, I do wonder if you're hitting some timing-dependent thing. The
whole "second suspend fails" is not an uncommon problem case. Others have
had it, and it's possible that it's not going to be the actual merge that
is the problem, but that just some odd combination of code ends up hitting
the case that causes it for you. But the bisect above should still be
interesting, since it will point to _some_ commit that triggers it, and
then we can say whether that commit makes sense or not..


 \ /
  Last update: 2009-10-18 23:28    [W:0.070 / U:3.224 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site