Re: T400 suspend/resume regression -- bisected to a mystery merge commit

[Linus Torvalds <torvalds@linux-foundation.org>]

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..

		Linus