Kernel 'bisection'

NoOp glgxg at
Thu Feb 19 05:06:55 UTC 2015

On 02/17/2015 07:42 AM, Chris wrote:
> On Tue, 2015-02-17 at 15:55 +0100, Liam Proven wrote:
>> On 14 February 2015 at 17:50, Gene Heskett <gheskett at> wrote:
>> >
>> > You Liam, I would think would know what that is, but when you are building
>> > your own kernels, and the next version you build doesn't work, you backup
>> > to an older version that does work, then apply half of the patches in the
>> > same sequence as they were applied to get from one that works to one that
>> > doesn't to build an intermediate kernel & see if it works, if not, next
>> > pass only applies 1/4 of the patches, or if it does work, apply 1/4 of the
>> > remaining patches.  In 8 or maybe 9 such builds you can nail it down to
>> > the specific patch that broke it.  Successive approximation, works well
>> > for finding bad patches.  Works well if you are following the -rc# as they
>> > are released, but it does get cumbersome to find whu a 2.6.32 works, but a
>> > 3.18 doesn't. That may take twice the builds.
>> I don't build my own kernels, though, and haven't done this century.
>> Sure, I used to in the mid-1990s, when you had to do that kind of
>> fooling around, but things, as I keep telling you and you resolutely
>> keep utterly ignoring, have moved on since then.
> I've given up on trying to do this as whenever I ask a question on the
> bug report or add information none of the, what would you call them,
> those the bug is reported to, ever respond. The same goes for the bug
> report I've added information to at, no one seems to
> care and questions I have don't get answered. There has to be a reason
> for it as I'm not the only one having this issue as shown in the two bug
> reports but no help is forthcoming. 
> Chris

Eventually it will probably go into the 'Expired' bin like the others:
and then you'll need to file yet another "New" bug - especially if
'clean up Christopher' :-) gets on to it.

And no... you're not alone:
(use this one instead of Google & you'll get cleaner/better results)

This might be of interest (around comment 30)
and from comment 43
Known issues

I have the lastest Intel driver:
dpkg -l | grep xorg | grep intel
ii  xserver-xorg-video-intel
2:2.99.911-0intel1                                          amd64
 X.Org X server -- Intel i8xx, i9xx display driver
and that hasn't made any difference (also still get pixel corruption as
well) only different freeze output (see my previous comment in this
thread regarding the 1384342 bug report...

Next laptop I buy will not have Intel graphics.

More information about the ubuntu-users mailing list