[sandybridge-m-gt2] GPU lockup render.IPEHR: 0x7a000003 with Google Maps(WebGL) in Chromium

Bug #966631 reported by Giovanni Pardini
276
This bug affects 72 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Critical
linux (Ubuntu)
Fix Released
High
Unassigned
Precise
Fix Released
High
Unassigned
xserver-xorg-video-intel (Ubuntu)
Fix Released
Undecided
Unassigned
Precise
Fix Released
High
Timo Aaltonen

Bug Description

Trying the WebGL enabled version of Google Maps with Chromium browser.

Chromium crashed as well, and here is its bug report:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/932481

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-20.33-generic 3.2.12
Uname: Linux 3.2.0-20-generic x86_64
.tmp.unity.support.test.0:

ApportVersion: 1.95-0ubuntu1
Architecture: amd64
Chipset: sandybridge-m-gt2
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
Date: Tue Mar 27 23:21:31 2012
DistUpgraded: Fresh install
DistroCodename: precise
DistroVariant: ubuntu
DkmsStatus: bbswitch, 0.4.1, 3.2.0-20-generic, x86_64: installed
DuplicateSignature: [sandybridge-m-gt2] GPU lockup render.IPEHR: 0x7a000003 Ubuntu 12.04
ExecutablePath: /usr/share/apport/apport-gpu-error-intel.py
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GpuHangFrequency: Continuously
GpuHangReproducibility: Yes, I can easily reproduce it
GpuHangStarted: Immediately after installing this version of Ubuntu
InterpreterPath: /usr/bin/python2.7
MachineType: ASUSTeK Computer Inc. U36SD
ProcCmdline: /usr/bin/python /usr/share/apport/apport-gpu-error-intel.py
ProcEnviron:

ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-20-generic root=UUID=56319b23-d221-4ca2-a1d2-fa8aa740a066 ro quiet splash vt.handoff=7
SourcePackage: xserver-xorg-video-intel
Title: [sandybridge-m-gt2] GPU lockup render.IPEHR: 0x7a000003
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

dmi.bios.date: 07/12/2011
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: U36SD.205
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: U36SD
dmi.board.vendor: ASUSTeK Computer Inc.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer Inc.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrU36SD.205:bd07/12/2011:svnASUSTeKComputerInc.:pnU36SD:pvr1.0:rvnASUSTeKComputerInc.:rnU36SD:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
dmi.product.name: U36SD
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK Computer Inc.
version.compiz: compiz 1:0.9.7.2-0ubuntu4
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.32-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 8.0.2-0ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 8.0.2-0ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.11.4-0ubuntu7
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.0-0ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

Revision history for this message
In , Aaron667 (aaron667) wrote :

Created attachment 58707
i915_error_state

xf86-video-intel git: 1c2932e9cb283942567c3dd2695d03b8045da27f
xorg-server: 1.12
firefox: 11.0
kernel: 3.3.0

dmesg:
[ 357.750313] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[ 357.750325] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[ 357.767446] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 7401 at 7390, next 7402)

Xorg.log:
[ 353.425] [mi] EQ overflowing. Additional events will be discarded until existing events are processed.
[ 353.425]
[ 353.425] Backtrace:
[ 353.426] 0: /usr/bin/X (xorg_backtrace+0x36) [0x56d2d6]
[ 353.426] 1: /usr/bin/X (mieqEnqueue+0x273) [0x54dd43]
[ 353.426] 2: /usr/bin/X (0x400000+0x4a3ae) [0x44a3ae]
[ 353.426] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fdf2082c000+0x62d1) [0x7fdf208322d1]
[ 353.426] 4: /usr/bin/X (0x400000+0x72267) [0x472267]
[ 353.426] 5: /usr/bin/X (0x400000+0x97ab3) [0x497ab3]
[ 353.426] 6: /lib64/libpthread.so.0 (0x7fdf24db8000+0x10420) [0x7fdf24dc8420]
[ 353.426] 7: /lib64/libc.so.6 (ioctl+0x7) [0x7fdf23da8807]
[ 353.426] 8: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x7fdf2233ef08]
[ 353.426] 9: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fdf21e07000+0x37524) [0x7fdf21e3e524]
[ 353.426] 10: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fdf21e07000+0x3a353) [0x7fdf21e41353]
[ 353.426] 11: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fdf21e07000+0x6256c) [0x7fdf21e6956c]
[ 353.426] 12: /usr/lib64/xorg/modules/drivers/intel_drv.so (0x7fdf21e07000+0x70720) [0x7fdf21e77720]
[ 353.426] 13: /usr/bin/X (WakeupHandler+0xa0) [0x43a280]
[ 353.426] 14: /usr/bin/X (WaitForSomething+0x1bc) [0x56a8cc]
[ 353.426] 15: /usr/bin/X (0x400000+0x35e52) [0x435e52]
[ 353.426] 16: /usr/bin/X (0x400000+0x24e6a) [0x424e6a]
[ 353.426] 17: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7fdf23cf522d]
[ 353.426] 18: /usr/bin/X (0x400000+0x24a09) [0x424a09]
[ 353.426]
[ 353.426] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack.
[ 353.426] [mi] mieq is *NOT* the cause. It is a victim.
[ 354.097] [mi] EQ overflow continuing. 100 events have been dropped.

Revision history for this message
In , Aaron667 (aaron667) wrote :

Created attachment 58710
i915_error_state after upgrade to mesa (git: ca760181b4420696c7e86aa2951d7203522ad1e8 )

Revision history for this message
Giovanni Pardini (gio.pardini) wrote :
tags: removed: need-duplicate-check
description: updated
Revision history for this message
In , Kenxeth (kenxeth) wrote :

It appears that the hang goes away if you disable HiZ. (This can be done via driconf, or by setting the environment variable hiz=false.)

The simulator is giving me interesting complaints; investigating further...

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Confirmed
Revision history for this message
Rob Castle (futuredub) wrote :

I have the same problem on a Thinkpad X1, running precise.
Unless I'm mistaken, it appears to be related to https://bugs.freedesktop.org/show_bug.cgi?id=47535
For me, setting INTEL_HIZ="0", as mentioned in the linked bug report, stops the lockup in webGL.

Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → High
Revision history for this message
Giovanni Pardini (gio.pardini) wrote :

INTEL_HIZ="0" also works for me.

Bryce Harrington (bryce)
summary: - [sandybridge-m-gt2] GPU lockup render.IPEHR: 0x7a000003
+ [sandybridge-m-gt2] GPU lockup render.IPEHR: 0x7a000003 with Google
+ Maps(WebGL) in Chromium
Revision history for this message
In , Kenxeth (kenxeth) wrote :

*** Bug 45806 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Kenxeth (kenxeth) wrote :

*** Bug 44108 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Eric Appleman (erappleman) wrote :

Confirming that disabling Hierarchical Z stops the hang.

However, overall MapsGL performance is uninspiring. Probably Google's fault since its still experimental.

Revision history for this message
In , ChadVersace (chad.versace) wrote :

MapsGL is also uninspiring on my MacBook Pro with a discrete NVidia card. It's definitely Google's fault.

Bryce Harrington (bryce)
Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Triaged
Changed in xserver-xorg-video-intel:
importance: Unknown → Critical
status: Unknown → In Progress
Revision history for this message
In , Daniel-ffwll (daniel-ffwll) wrote :

Maybe we're lucky and one of the SNB workarounds fixed this. Can someone try the latest kernel from my drm-intel-next-queued branch?

Revision history for this message
Maarten Deprez (deprez-maarten) wrote :

Strangely, i seem to experience this bug (at least, apport sent me here) most often (not every time) when LibreOffice.org is suggesting a word... On Ubuntu 12.04 testing, up-to-date. A few days ago, this would hang my system, requiring reboot, but now it recovered.

Dmesg output (i915_error_state attached):

[41633.259712] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[41633.259785] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[41633.285630] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 9872988 at 9872982, next 9872989)

Revision history for this message
In , Aaron667 (aaron667) wrote :

I just gave drm-intel-next-queued (a360bb1a83279243a0945a0e646fd6c66521864e) a try (running with mesa 8.0.2, libdrm-2.4.33 and xf86-video-intel-caf9144271a10f90ea580c246b2df3f69a10b7a0 ) and I'd say the situation definitely improved. I got one initial hang when using google maps, after that it ran almost smooth. Previously every single zoom on the map caused yet another hangcheck_hung entry.

The log message I got was:
[ 79.722665] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[ 79.722669] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[ 79.734067] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off

Revision history for this message
In , Aaron667 (aaron667) wrote :

Created attachment 60446
i915_error_state running with drm-intel-next-queued kernel

Revision history for this message
James (jamesasgrim) wrote :

A friends suggested I tried Google Maps with WebGL and my precise locked up as described. I don't mind that i

Except now I'm *constantly* getting the crash notifications. They won't go away. I don't have the option to "Don't offer to report this crash again" like I normally do, and this is getting massively frustrating, even after reboot. I get asked several questions, even if I untick "Send an error report to help fix this problem". If I tick it and try to send an error report it sends me here.

Revision history for this message
In , Kenxeth (kenxeth) wrote :

Mashing this register makes the problem go away for me:

$ sudo intel_reg_write 0x2120 '0x1206800'
Value before: 0x6820
Value after: 0x6800

Anyone care to try it out? I'll put together a kernel patch soon.

Revision history for this message
In , Rob Castle (futuredub) wrote :

I can confirm it works, for me at least.

Revision history for this message
In , Aaron667 (aaron667) wrote :

Works for me, too.

Revision history for this message
In , Kenxeth (kenxeth) wrote :

It turns out that Daniel already implemented a workaround for this in the kernel...but the register write isn't sticking. Apparently this register needs to be written later in the initialization process.

I've sent a preliminary (lame) patch to intel-gfx to spark some discussion on what the right fix should be. Hopefully we can land on something soon...

Reassigning to me.

Revision history for this message
Albert Damen (albrt) wrote :

A patch was submitted to intel-gfx yesterday: "[Intel-gfx] [PATCH v2] drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.". I have tested this patch on top of the precise kernel 3.2.0-24-generic. Googleearth no longer freezes when zooming in.
The patch is currently on it's way to Linus and stable.

Revision history for this message
In , Kenxeth (kenxeth) wrote :

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. :)

Marking fixed. 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.)

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>

Revision history for this message
madbiologist (me-again) wrote :

The patch mentioned above by Albert 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/

Revision history for this message
In , Kenxeth (kenxeth) wrote :

*** Bug 48526 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Kenxeth (kenxeth) wrote :

*** Bug 48791 has been marked as a duplicate of this bug. ***

Changed in xserver-xorg-video-intel:
status: In Progress → Fix Released
Revision history for this message
In , Kenxeth (kenxeth) wrote :

*** Bug 48748 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Arun Raghavan (arunraghavan) wrote :

Works a treat. Thank you!

Revision history for this message
James (jamesasgrim) wrote :

Will kernel 3.4 (or at least the fix for this bug) make it into precise at any point? Sorry if this is a stupid question.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

3.4 won't get in precise, but we can backport fixes to the 3.2.

This needs this commit:

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

affects: xserver-xorg-video-intel (Ubuntu) → linux (Ubuntu)
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Marking fixed in quantal, leaving the precise task open

Changed in linux (Ubuntu):
status: Triaged → Fix Released
Changed in linux (Ubuntu Precise):
importance: Undecided → High
status: New → Triaged
Timo Aaltonen (tjaalton)
Changed in xserver-xorg-video-intel (Ubuntu Precise):
importance: Undecided → High
status: New → Triaged
Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Fix Released
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Actually, that commit is already in the kernel in precise-proposed (3.2.0-25.40), so please test with that kernel!

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

anyone?

Changed in xserver-xorg-video-intel (Ubuntu Precise):
assignee: nobody → Timo Aaltonen (tjaalton)
Revision history for this message
David Overcash (funnylookinhat) wrote :

I tested 3.2.0-25.40 on a duplicate bug and it worked.
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/906269

I also just verified that Google Maps ( the WebGL version ) works without issue in Chrome with that same kernel.

Revision history for this message
Rob Castle (futuredub) wrote :

proposed 3.2.0-25.40 is also working for me. Tested webgl maps in Firefox/chromium & google earth.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

thanks, marking as fix committed!

Changed in linux (Ubuntu Precise):
status: Triaged → Fix Committed
Changed in xserver-xorg-video-intel (Ubuntu Precise):
status: Triaged → Fix Committed
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

Closing as fix released, since the new kernel is now available in precise-updates.

If you still have gpu hangs, please file a new bug.

Changed in linux (Ubuntu Precise):
status: Fix Committed → Fix Released
Changed in xserver-xorg-video-intel (Ubuntu Precise):
status: Fix Committed → Fix Released
Revision history for this message
Chris Polderman (chris-polderman) wrote :

Yeah baby! This is what open source is all about. Thank you all!

Revision history for this message
Eduard Fabra (edfabra) wrote : Re: [Bug 966631] Re: [sandybridge-m-gt2] GPU lockup render.IPEHR: 0x7a000003 with Google Maps(WebGL) in Chromium
Download full text (4.0 KiB)

Yes, thank you so much!

On Thu, Jun 14, 2012 at 9:59 AM, Chris Polderman
<email address hidden>wrote:

> Yeah baby! This is what open source is all about. Thank you all!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/966631
>
> Title:
> [sandybridge-m-gt2] GPU lockup render.IPEHR: 0x7a000003 with Google
> Maps(WebGL) in Chromium
>
> Status in X.org xf86-video-intel:
> Fix Released
> Status in “linux” package in Ubuntu:
> Fix Released
> Status in “xserver-xorg-video-intel” package in Ubuntu:
> Fix Released
> Status in “linux” source package in Precise:
> Fix Released
> Status in “xserver-xorg-video-intel” source package in Precise:
> Fix Released
>
> Bug description:
> Trying the WebGL enabled version of Google Maps with Chromium browser.
>
> Chromium crashed as well, and here is its bug report:
> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/932481
>
>
> ProblemType: Crash
> DistroRelease: Ubuntu 12.04
> Package: xserver-xorg-video-intel 2:2.17.0-1ubuntu4
> ProcVersionSignature: Ubuntu 3.2.0-20.33-generic 3.2.12
> Uname: Linux 3.2.0-20-generic x86_64
> .tmp.unity.support.test.0:
>
> ApportVersion: 1.95-0ubuntu1
> Architecture: amd64
> Chipset: sandybridge-m-gt2
> CompizPlugins: No value set for
> `/apps/compiz-1/general/screen0/options/active_plugins'
> CompositorRunning: compiz
> Date: Tue Mar 27 23:21:31 2012
> DistUpgraded: Fresh install
> DistroCodename: precise
> DistroVariant: ubuntu
> DkmsStatus: bbswitch, 0.4.1, 3.2.0-20-generic, x86_64: installed
> DuplicateSignature: [sandybridge-m-gt2] GPU lockup render.IPEHR:
> 0x7a000003 Ubuntu 12.04
> ExecutablePath: /usr/share/apport/apport-gpu-error-intel.py
> ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
> GpuHangFrequency: Continuously
> GpuHangReproducibility: Yes, I can easily reproduce it
> GpuHangStarted: Immediately after installing this version of Ubuntu
> InterpreterPath: /usr/bin/python2.7
> MachineType: ASUSTeK Computer Inc. U36SD
> ProcCmdline: /usr/bin/python /usr/share/apport/apport-gpu-error-intel.py
> ProcEnviron:
>
> ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-20-generic
> root=UUID=56319b23-d221-4ca2-a1d2-fa8aa740a066 ro quiet splash vt.handoff=7
> SourcePackage: xserver-xorg-video-intel
> Title: [sandybridge-m-gt2] GPU lockup render.IPEHR: 0x7a000003
> UpgradeStatus: No upgrade log present (probably fresh install)
> UserGroups:
>
> dmi.bios.date: 07/12/2011
> dmi.bios.vendor: American Megatrends Inc.
> dmi.bios.version: U36SD.205
> dmi.board.asset.tag: ATN12345678901234567
> dmi.board.name: U36SD
> dmi.board.vendor: ASUSTeK Computer Inc.
> dmi.board.version: 1.0
> dmi.chassis.asset.tag: No Asset Tag
> dmi.chassis.type: 10
> dmi.chassis.vendor: ASUSTeK Computer Inc.
> dmi.chassis.version: 1.0
> dmi.modalias:
> dmi:bvnAmericanMegatrendsInc.:bvrU36SD.205:bd07/12/2011:svnASUSTeKComputerInc.:pnU36SD:pvr1.0:rvnASUSTeKComputerInc.:rnU36SD:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0:
> dmi.product.name: U36SD
> dmi.product.version: 1.0
> dmi.sys.vendor: ASUSTeK Computer Inc.
> version.compi...

Read more...

Revision history for this message
kenorb (kenorb) wrote :
Revision history for this message
Mario (mario-roessler) wrote :

I also have this issue with my Intel-I7-2600 based PC. The board is a original Intel one.
With Ubuntu and Unity or Gnome (even Gnome in 2D mode) i get random lockups of the complete PC. It does not matter if i do anything or if i just leave the PC alone. If i do not login to Gnome or Unity the PC does not hang.
So i tried XFCE4 and there i do not get any lockup as well. Just from time to time i get the crash of the script mentioned above.
This lets me assume Gnome and Unity cannot handle these GPU lockups but XFCE does. Just the current window hangs for some seconds short before the error message appears.
BTW: I am running 3.6.2-030602-generic at the moment because i had several kernel-oops with the original 3.2 kernel of Ubuntu 12.04LTS with this PC (also after updates). These do not occure with 3.6.2. Thats apparently a different problem.

Revision history for this message
Jakob Eriksson (b-jakob-v) wrote :

Mario, (https://launchpad.net/~mario-roessler) I have the same trouble on a Thinkpad T420 Optimus (with Nvidia disabled in BIOS) and Ubuntu 12.10

I think I will try with XFCE instead of Unity.

Revision history for this message
markusj (markusj) wrote :

There appears to be a regression, at least on my machine, the GPU started to lock up randomly (some gnome shell actions, namely the hot corner, cause it more likely than general usage) after longer usage and previous suspend to disk/RAM. It seems not to appear if no suspend has been done before.

It appeared first at 2012-10-26, there have been some updates on related packages before:
linux-image-generic:amd64 3.2.0.31.34 -> 3.2.0.32.35
xserver-xorg-video-intel:amd64 2:2.17.0-1ubuntu4.1 -> 2:2.17.0-1ubuntu4.2

I am currently trying the workaround mentioned above and here:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/975689/comments/25

The first errors in Xorg.0.log
[ 21840.621] [mi] EQ overflowing. Additional events will be discarded until existing events are processed.
[ 21840.621]
Backtrace:
[ 21840.687] 0: /usr/bin/X (xorg_backtrace+0x26) [0x7f06040d1876]
[ 21840.687] 1: /usr/bin/X (mieqEnqueue+0x263) [0x7f06040b1f53]
[ 21840.687] 2: /usr/bin/X (0x7f0603f49000+0x62a34) [0x7f0603faba34]
[ 21840.687] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f05fe10f000+0x5d88) [0x7f05fe114d88]
[ 21840.687] 4: /usr/bin/X (0x7f0603f49000+0x8af37) [0x7f0603fd3f37]
[ 21840.687] 5: /usr/bin/X (0x7f0603f49000+0xb0d1a) [0x7f0603ff9d1a]
[ 21840.687] 6: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f060326f000+0xfcb0) [0x7f060327ecb0]
[ 21840.687] 7: /lib/x86_64-linux-gnu/libc.so.6 (ioctl+0x7) [0x7f06021cb527]
[ 21840.687] 8: /usr/lib/x86_64-linux-gnu/libdrm.so.2 (drmIoctl+0x28) [0x7f060075c1a8]
[ 21840.687] 9: /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1 (0x7f06000e5000+0x7c89) [0x7f06000ecc89]
[ 21840.687] 10: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f0600302000+0xb442) [0x7f060030d442]
[ 21840.687] 11: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f0600302000+0x124ba) [0x7f06003144ba]
[ 21840.687] 12: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f0600302000+0x32e53) [0x7f0600334e53]
[ 21840.687] 13: /usr/bin/X (miCopyRegion+0x18a) [0x7f06040b010a]
[ 21840.687] 14: /usr/bin/X (miDoCopy+0x392) [0x7f06040b0602]
[ 21840.687] 15: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7f0600302000+0x338ae) [0x7f06003358ae]
[ 21840.687] 16: /usr/bin/X (0x7f0603f49000+0x11971c) [0x7f060406271c]
[ 21840.687] 17: /usr/bin/X (0x7f0603f49000+0x4a943) [0x7f0603f93943]
[ 21840.687] 18: /usr/bin/X (0x7f0603f49000+0x4e8a1) [0x7f0603f978a1]
[ 21840.687] 19: /usr/bin/X (0x7f0603f49000+0x3d7ba) [0x7f0603f867ba]
[ 21840.687] 20: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xed) [0x7f060210076d]
[ 21840.688] 21: /usr/bin/X (0x7f0603f49000+0x3daad) [0x7f0603f86aad]
[ 21840.688] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack.
[ 21840.688] [mi] mieq is *NOT* the cause. It is a victim.

Revision history for this message
markusj (markusj) wrote :

Note: The mentioned workaround did not work for me, and i have also encountered IPEHR 0x01000000 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/978968), even without suspend to disk/ram. LibreOffice spell checking appears to trigger the problem sometimes.

Revision history for this message
Dinçer Kavraal (dkavraal) wrote :

Here do I the same.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.