Björn Steinbrink wrote:
> On 2008.08.22 10:51:36 -0700, Andrew Morton wrote:
>> On Fri, 22 Aug 2008 19:16:51 +0200 Petr Baudis <pasky@suse.cz> wrote:
>>> On Fri, Aug 22, 2008 at 09:25:49AM -0700, Andrew Morton wrote:
>>>> One (probably wrong) approach is to run
>>>>
>>>> 	gitk 1c89ac55017f982355c7761e1c912c88c941483d
>>>>
>>>> then peer at the output, work out which real commits were in that
>>>> merge.
>>>>
>>>> It looks like the merge ended with
>>>> b1b135c8d619cb2c7045d6ee4e48375882518bb5 and started with
>>>> 40c42076ebd362dc69210cccea101ac80b6d4bd4, so perhaps you can do
>>>>
>>>> 	git bisect bad b1b135c8d619cb2c7045d6ee4e48375882518bb5
>>>> 	git bisect good 40c42076ebd362dc69210cccea101ac80b6d4bd4
>>> ...I don't quite get this - according to the bisection log,
>>>
>>> 	# good: [b1b135c8d619cb2c7045d6ee4e48375882518bb5] fix spinlock recursion in hvc_console
>>>
>>> and now you want to mark it as bad?
>> <what bisection log?>
> 
> Alan provided his bisection log as an attachment to the original bug
> report.
> 
>> I assume that Alan's bisection search ended up saying that the merge
>> commit (1c89ac55017f982355c7761e1c912c88c941483d) was the first bad
>> commit.
> 
> Yep, and that's totally correct as far as bisect is concerned. The
> parents of that merge commit are:
> 88fa08f67bee1a0c765237bdac106a32872f57d2
> b1b135c8d619cb2c7045d6ee4e48375882518bb5
> 
> And Alan marked both of them as good.
> 
> So, unless Alan made a mistake during his bisection, each of the
> branches is correct, but the merge did not lead to a correct result. So
> while there were no textual conflicts, there were still incompatible
> changes regarding the code semantics and compatibility was not restored
> during the merge.

It's important to note that even if I did make a mistake during the
bisection process (and I certainly wouldn't discount that), recent
kernels still fail: but when I take out that commit from a recent
kernel, it fails.

I put in Andrew's suggested patch (to help find things), and now I
repeatedly get the problems in the attached log.

Not being an x86 knowledgeable person, I'm a bit concerned about the RSP
value?! (I enabled stack overflow checking, but that didn't stop things.)

Alan