cpollock at embarqmail.com
Thu Feb 19 14:27:44 UTC 2015
On Wed, 2015-02-18 at 21:06 -0800, NoOp wrote:
> 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 wdtv.com> 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 freedesktop.org, 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.
Thanks for the links, oddly enough as I was opening one of them the
system decided to hang. I updated to kernel 3.19.0-031900-generic
yesterday afternoon at 5:34pm, the hang this morning happened at
07:18:55. The 'hangcheck' error was not present this time. What was in
my syslog at the time of the lockup is here:
I added a comment to both bug reports and also the output of 'dmesg'.
FWIW here is the output of the command above:
dpkg -l | grep xorg | grep intel
X.Org X server -- Intel i8xx, i9xx display driver
So, the problem continues, sort of. I'll continue running the 3.19
kernel to see what happens as I figure that's the only way this may get
fixed especially if the errors change.
31.11°N 97.89°W (Elev. 1092 ft)
08:16:56 up 52 min, 2 users, load average: 0.08, 0.21, 0.33
Ubuntu 14.04.1 LTS, kernel 3.19.0-031900-generic
More information about the ubuntu-users