1

I bisected problem in kernel and the first bad commit is merge commit:

Parents of 2b90506a8186 (both are good):

Also v5.12-rc2 is good.

I need to do second bisect to find actual first non-merge bad commit (i.e. one of 028a1e968435..2b90506a8186 - 4885 commits or 01d713689441..2b90506a8186 - 46 commits).

I remember previously on similar case I checkouted into one of the parents (first branch) and applied one-by-one all commits from the other parent (second branch) on the top of the first branch. With this special branch, where I needed to solve few conflicts I could rebase as the history was linear.

But I don't remember how I got the list of commits from the other parent. It was probably quite straightforward, founding it's parent with git log --first-parent.

But for this case it I'm not able to generate the list, probably due fact that parents are also merge commits.

I tried to read various sources, but no luck:

UPDATE I don't believe there is kernel regression for all devices, just problem with device tree for my particular arm64 device. Finding a problematic commit can help me to temporarily revert problematic commit until I find what needs to be fixed in device tree for my device.

pevik
  • 4,523
  • 3
  • 33
  • 44
  • 2
    (a) what's your test for good vs bad? and (b) what's your question? 2b90506 has no hunks with any differences from one parent or the other, there's nothing unusual about that merge. Please be specific, edit: not just about where you're looking or how you interpret what you see, but what you're looking at and what you're looking for. – jthill Jun 12 '21 at 01:05
  • 1
    @jthill (b) I need to do second bisect to find actual first non-merge bad commit. Whole problem is that there are so many merge commits around the first bad that I got confused :) (a) *good*: my device is booting, *bad*: device resets in the middle of booting. – pevik Jun 12 '21 at 05:51

1 Answers1

1

Parents of 2b90506a8186 (both are good): […] I need to do second bisect to find actual first non-merge bad commit

You know merging 2b90506^2 produces a kernel that won't boot on your rig, so that commit has the bug that will show up in integration: it's bad.

git bisect 2b90506^2 $(git merge-base 2b90506^1 2b90506^2)

and when testing, merge to 2b90506^1 first to check whether a commit will fail integration testing, since that's your real "bad" condition.

jthill
  • 55,082
  • 5
  • 77
  • 137
  • Yep, bisecting it's not magic. But why it's tricky is that some "bugs" (problems for particular device) manifest in combination of certain commits. I guess I'll have to make my tree, when adding linearly all commits from one parent to the top of the other parent. Because bisecting `git bisect 2b90506^2 $(git merge-base 2b90506^1 2b90506^2)` I already did. – pevik Jun 12 '21 at 20:19
  • But +1 for `merge-base`, I didn't know this. – pevik Jun 12 '21 at 20:19
  • 1
    What I'm suggesting is that you test the results of merging each commit with 2b90506^1 to decide whether it's good. You say in your question that 2b90506^2 is "good" but you know merging it with ^1 makes a broken kernel. It's not good. That's the test you should be doing when you bisect. – jthill Jun 12 '21 at 20:52