[i965gme] GPU lockup render.IPEHR: 0x81323232 - GPU hang after executing supertuxkart

[Mafiosso]

This bug is reproducible on my laptop with graphics: VGA compatible controller: Intel Corporation Mobile GME965/GLE960 Integrated Graphics Controller (rev 0c) when I run supertuxkart.

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6
Uname: Linux 3.2.0-17-generic i686
NonfreeKernelModules: wl
ApportVersion: 1.94-0ubuntu1
Architecture: i386
Chipset: i965gme
Date: Sat Mar 3 08:55:29 2012
DistroCodename: precise
DistroVariant: ubuntu
DuplicateSignature: [i965gme] GPU lockup render.IPEHR: 0x81323232 Ubuntu 12.04
ExecutablePath: /usr/share/apport/apport-gpu-error-intel.py
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
InterpreterPath: /usr/bin/python2.7
ProcCmdline: /usr/bin/python /usr/share/apport/apport-gpu-error-intel.py
ProcEnviron:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-17-generic root=UUID=7baf4285-107e-4516-a46b-27c03bb6d43d ro quiet splash vt.handoff=7
RelatedPackageVersions:
 xserver-xorg 1:7.6+10ubuntu1
 libdrm2 2.4.30-1ubuntu1
 xserver-xorg-video-intel 2:2.17.0-1ubuntu4
SourcePackage: xserver-xorg-video-intel
Title: [i965gme] GPU lockup render.IPEHR: 0x81323232
UdevDb: Error: [Errno 2] No such file or directory
UpgradeStatus: Upgraded to precise on 2012-02-27 (4 days ago)
UserGroups:

dmi.bios.date: 08/20/2008
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68MVU Ver. F.02
dmi.board.name: 3618
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 12.00
dmi.chassis.asset.tag: CNU9040M7W
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68MVUVer.F.02:bd08/20/2008:svnHewlett-Packard:pn:pvrF.02:rvnHewlett-Packard:rn3618:rvrKBCVersion12.00:cvnHewlett-Packard:ct10:cvr:
dmi.product.version: F.02
dmi.sys.vendor: Hewlett-Packard

[Bryce Harrington (bryce)]

Forwarding this bug from Ubuntu reporter Mafiosso:
http://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/945441

[Problem]
This bug is reproducible on my laptop with graphics: VGA compatible controller: Intel Corporation Mobile GME965/GLE960 Integrated Graphics Controller (rev 0c) when I run supertuxkart.

Time: 1330761329 s 272131 us
PCI ID: 0x2a12
EIR: 0x00000000
PGTBL_ER: 0x00000000
Render command stream:
  ACTHD: 0x0a68d2c8
  IPEIR: 0x00000000
  IPEHR: 0x81323232
  INSTDONE: 0xff65fafd
  INSTDONE1: 0x000ffff3
  INSTPS: 0x8001e022
  INSTPM: 0x00000000
  seqno: 0x0000c172

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6
Uname: Linux 3.2.0-17-generic i686
NonfreeKernelModules: wl
ApportVersion: 1.94-0ubuntu1
Architecture: i386
Chipset: i965gme
Date: Sat Mar 3 08:55:29 2012
DistroCodename: precise
DistroVariant: ubuntu
DuplicateSignature: [i965gme] GPU lockup render.IPEHR: 0x81323232 Ubuntu 12.04
ExecutablePath: /usr/share/apport/apport-gpu-error-intel.py
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
InterpreterPath: /usr/bin/python2.7
ProcCmdline: /usr/bin/python /usr/share/apport/apport-gpu-error-intel.py
ProcEnviron:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-17-generic root=UUID=7baf4285-107e-4516-a46b-27c03bb6d43d ro quiet splash vt.handoff=7
RelatedPackageVersions:
 xserver-xorg 1:7.6+10ubuntu1
 libdrm2 2.4.30-1ubuntu1
 xserver-xorg-video-intel 2:2.17.0-1ubuntu4
SourcePackage: xserver-xorg-video-intel
Title: [i965gme] GPU lockup render.IPEHR: 0x81323232
UdevDb: Error: [Errno 2] No such file or directory
UpgradeStatus: Upgraded to precise on 2012-02-27 (4 days ago)
UserGroups:

dmi.bios.date: 08/20/2008
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68MVU Ver. F.02
dmi.board.name: 3618
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 12.00
dmi.chassis.asset.tag: CNU9040M7W
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68MVUVer.F.02:bd08/20/2008:svnHewlett-Packard:pn:pvrF.02:rvnHewlett-Packard:rn3618:rvrKBCVersion12.00:cvnHewlett-Packard:ct10:cvr:
dmi.product.version: F.02
dmi.sys.vendor: Hewlett-Packard

[Bryce Harrington (bryce)]

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

[Bryce Harrington (bryce)]

Created attachment 58093
BootDmesg.txt

[Bryce Harrington (bryce)]

Created attachment 58094
CurrentDmesg.txt

[Bryce Harrington (bryce)]

Created attachment 58095
i915_error_state.txt

[Chris Wilson (ickle)]

It's either a genuine wild write from a mesa batchbuffer or the finish-gpu-esque bug.

Reassigning to Mesa because we have other SuperTuxCart bugs open and this may be related.

[Kenxeth (kenxeth)]

Hi! I believe this was fixed by the following commit, which is already part of the Mesa 8.0.3 release:

commit 93e94cbb48a679b7bf67594adb6f858526b37935
Author: Eric Anholt <email address hidden>
Date: Fri Feb 10 12:54:25 2012 -0800

    intel: Fix rendering from textures after RenderTexture().

    There's a serious trap for drivers: RenderTexture() does not indicate
    that the texture is currently bound to the draw buffer, despite
    FinishRenderTexture() signaling that the texture is just now being
    unbound from the draw buffer.

    We were acting as if RenderTexture() *was* the start of rendering and
    that we could make texturing incoherent with the current contents of
    the renderbuffer. This caused intel oglconform sRGB
    Mipmap.1D_textures to fail, because we got a call to TexImage() and
    thus RenderTexture() on a texture bound to a framebuffer that wasn't
    the draw buffer, so we skipped validating the new image into the
    texture object used for rendering.

    We can't (easily) make RenderTexture() indicate the start of drawing,
    because both our driver and gallium are using it as the moment to set
    up the renderbuffer wrapper used for things like MapRenderbuffer().
    Instead, postpone the setup of the workaround render target miptree
    until update_renderbuffer time, so that we no longer need to skip
    validation of miptrees used as render targets. As a bonus, this
    should make GL_NV_texture_barrier possible.

    (This also fixes a regression in the gen4 small-mipmap rendering since
    3b38b33c1648b07e75dc4d8340758171e109c598, which switched
    set_draw_offset from image->mt to irb->mt but didn't move the irb->mt
    replacement up before set_draw_offset).

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44961
    NOTE: This is a candidate for the 8.0 branch.

I tested it on a GM965, and it seems to be working for me. Feel free to reopen if problems persist.