# Re: AAARGH bisection is hard (Re: \[2.6.39 regression\] X locks up hard right after logging in)

- From: Andrew Lutomirski \<hidden\>
- Date: 2011-05-13 13:39:37 
- List: netdev
- Page: https://ratatoskr.run/netdev/2011/05/3714807
- Thread: https://ratatoskr.run/netdev/2011/05/3714413/t.md

```text
[resend because the Android gmail client apparently generates HTML
emails even for plain text]

On Thu, May 12, 2011 at 1:37 PM, Linus Torvalds
[ref] wrote:
> On Thu, May 12, 2011 at 10:15 AM, Andrew Lutomirski [ref] wrote:
>>
>> OK, this sucks.  In the course of bisecting this, I've hit two other
>> apparently unrelated bugs that prevent my from testing large numbers
>> of kernels.  Do I have two questions:
>>
>> 1. Anyone have any ideas from looking at the log?
>
> Nope, that doesn't look very helpful.
>
>> 2.  The !&$#@ bisection is skipping all over the place.  I've seen
>> 2.6.37 versions and all manner of -rc's out of order.
>
> That's the _point_ of bisection. It jumps around. You can start off
> trying to pick points on my development tree, but I only have a
> hundred merges or so. You're going to start delving into the actual
> development versions very quickly. And if you don't do it early,
> bisection is going to be much much slower, because it's not going to
> pick half-way points.
>
> So bisection works so well exactly because it picks points that are
> far away from each other, and you should just totally ignore the
> version number. It's meaningless. Looking at it just confuses you.
> Don't do it.
>

I actually had better results looking at the version number, saying
"blech", and running git merge v2.6.38.  (git bisect good gets a
little confused if I feed it the merge result, but I can just lie.)

Anyway, I must have made a mistake somewhere.  The regression is in
drm (presumably i915) and it has a new thread now.

--Andy
```