X freezes completely running google earth on xserver-xorg-video-intel - IPEHR: 0x7a000002

For GPU lockup bugs with Intel graphics, you need to collect the output of 'dmesg' and your /sys/kernel/debug/dri/0/i915_error_state file. Both of these must be collected while the machine is locked up (e.g. by sshing into the sick machine over ethernet). See https://wiki.ubuntu.com/X/Troubleshooting/Freeze for additional info.

Fwiw, we've had several other reports of people experiencing gpu lockups with google earth. No leads yet on a solution though.

Here's a log of dmesg, Xorg.0.conf, and i915_error_state while X was frozen.

The system did actually recover partially after a minute this time. Unity crashed (I guess because the 3d acceleration was disabled when the GPU lockup was detected) so all I could do was reboot via a tty console.

Rocko - I've forwarded this bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=48937 - please subscribe yourself to this bug, in case they need further information or wish you to test something. Thanks ahead of time!

Is there a way to recover from this without killing X? I can ssh into the system or blindly restart LightDM via a virtual terminal (it won't switch to it, but you can log in and run commands), but I'd like to keep X alive. :-(

My machine is doing the same thing.

Ubuntu 12.04

Gateway DX4860-US20P, with integrated Intel HD

I have the same problem. Google Earth 6.2.2.

Intel CoreI-5 2300.
Ubuntu 12.04 64Bits.

It looks like this is a kernel issue rather than a xserver issue, as kernel commit 3a69ddd6f872180b6f61fda87152b37202118fbc fixes the problem for me:

commit 3a69ddd6f872180b6f61fda87152b37202118fbc
Author: Kenneth Graunke <email address hidden>
Date: Fri Apr 27 12:44:41 2012 -0700

    drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.

    Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in
    OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when
    using separate stencil buffers. Without it, the GPU tries to use the
    LRA eviction policy, which isn't supported. This was supposed to be off
    by default, but seems to be on for many machines.

    This cannot be done in gen6_init_clock_gating with most of the other
    workaround bits; the render ring needs to exist. Otherwise, the
    register write gets dropped on the floor (one printk will show it
    changed, but a second printk immediately following shows the value
    reverts to the old one).

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535
    Cc: <email address hidden>
    Cc: Rob Castle <email address hidden>
    Cc: Eric Appleman <email address hidden>
    Cc: <email address hidden>
    Cc: Keith Packard <email address hidden>
    Signed-off-by: Kenneth Graunke <email address hidden>
    Reviewed-by: Daniel Vetter <email address hidden>
    Acked-by: Daniel Vetter <email address hidden>
    Signed-off-by: Dave Airlie <email address hidden>

The attached patch stops the crash with the 3.2.16 kernel, so it should work with the Ubuntu 3.2 kernel as well.

The attachment "patch for 3.2" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Seems to work fine with a patched Ubuntu 3.2.0-24.37 kernel.

It also seems to fix the hang in bug 808384.

Sorry, wrong bug, I meant this one: bug 950300.

Thanks Rocko, I've flagged this for the kernel team to review.

@Rocko

Can you provide some information on the status of the patch with regards to getting it merged upstream? Has it been sent upstream, what sort of feedback has it received, is it getting applied to a subsystem maintainer's tree, etc?

People affected by this bug are probably wondering why the kernel team doesn't just apply the patch and fix it. The reason is that the kernel team is reluctant (not opposed) to apply any patch to a stable kernel that is not from upstream. Applying patches that don't come from upstream add greatly to the support of the kernel as other upstream patches may touch the same area as the non-upstream patch and may prevent them from applying cleanly.

See the upstream bug mentioned in the commit. In https://bugs.freedesktop.org/show_bug.cgi?id=47535#c14 it says "Linus merged the patch into the upstream kernel, and Greg picked it up for 3.3 stable. Hopefully should be landing in a distro near you. :)", which might not help 3.2, of course.

I just saw the commit in the overnight git log, saw that it fixed the problem, and worked out how to modify it to apply to 3.2 as a proof-of-concept.

From the upstream comment, it appears there is another workaround:

"If upgrading kernels is inconvenient, you can also apply the workaround manually via "sudo intel_reg_write 0x2120 0x1206800", or by disabling HiZ and separate stencil (export hiz=false). (The kernel patch does the register write, so the intel_reg_write workaround is just as good.)"

The patch mentioned in comments #11 and #18 has been included upstream in kernel 3.4-rc5, and cc'd to stable.

A PPA of kernel 3.4-rc5 is available at http://kernel.ubuntu.com/~kernel-ppa/mainline/

This bug has plagued me for a year now since I got my laptop. Upgrading to the 3.4-rc5 kernel from the ubuntu kernel packages, as this comment thread suggested, has fixed it. I have so far seen zero adverse effects, and only good ones, in that games play now without me waiting for the inevitable lockup.

I have exactly the same problem on Ubuntu 12.04, 64bit, Intel graphic.

Apparantly the wrong version of the patch went into 3.4-rc5, so there is a follow up patch now:
drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+.

See http://lists.freedesktop.org/archives/intel-gfx/2012-May/017391.html

this exact same issue occurs on kubuntu 12.04 on samsung notebook (RV520). although a 64 bit machine here I've installed kubuntu 32 bit. but because it worked in kubuntu 11.10 my suspicion is that its the kernel causing the freeze. and once the freeze occurs we reach for a new power up. even the clock stops updating (one reason to always display seconds). yeah we can get to it via win7 but we try to stay away from that thing as much as possible.

I am currently testing with the following every time I start X:

sudo intel_reg_write 0x2120 0x1206800

(intel_reg_write is located in the intel_gpu_tools package)

Workaround is mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=47535

Curious if it fixes it as this bug is really bugging me :)

I have encountered this one once more even though i had added the workaround to the X session start sequence.

As I suspect that the GPU is completely reinitialized when suspending (I do that a lot), I have now added it to the sleep/suspend sequence:

/etc/pm/sleep.d/20_intel_workaround
(do not forget to make it executable)
--------------

#!/bin/sh

case "$1" in
  hibernate|suspend) echo "Intel workaround";;
  resume|thaw) intel_reg_write 0x2120 0x1206800;;
esac

Yes indeed, the value gets back to 0x1206820 after resuming from S3.

However, I can inform you that with this workaround my sandybridge laptop has been running for the third day in a row without freezing, whereas before that I usually had had up to several freezes a day (since I suspend my machine quite a lot).

Good to know, something to look forward to!

:-)

Chris

I updated to kernel 3.3.5 from kernel-ppa/mainline and to xserver-xorg-video-intel 2:2.19.0-0ubuntu1~xup1 from ppa:ubuntu-x-swat/x-updates, and the problem is still there. When I zoom in the map the screen goes black and then I get the lightdm login screen. I tried with googleearth 6.0 and 6.2, with the same results.

I tested googleearth after running sudo intel_reg_write 0x2120 '0x1206800' and still had the same problem. Since I'm running ubuntu 64bit, I tried to install libgl1-mesa-dri:i386 and the problem is gone, maybe that helps others users...

Computer HP probook 4531s
processor: sandy bridge i3-2330M
display 1366x768
kernel 3.2.0-24-generic

same bug, google earth freezes, sometimes x freezes after login

so far the fix 'intel_reg_write 0x2120 '0x1206800' fixed the bug, (google earth runs flawlessly now)

Best regards,

Otto

Probook 6360b,
 i5-2410M CPU
3.2.0-24-generic x86_64

same bug also, comment #25 seems to fix it.
(Note: libgl1-mesa-dri:i386 was already installed..)

Thanks

Same problem (complete freeze while running google earth after half a minute) here:
Core i5-2510E 2.5 Ghz