Alan D. Brunelle wrote: > 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@xxxxxxx> 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. s/fails/succeeds/ > > 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 > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
