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
Created attachment 58093 [details] BootDmesg.txt
Created attachment 58094 [details] CurrentDmesg.txt
Created attachment 58095 [details] i915_error_state.txt
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.
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 <eric@anholt.net> 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.
marking dup to show the relation.
*** This bug has been marked as a duplicate of bug 44961 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.