[snb-gt2] GPU lockup render.IPEHR: 0x7b009004 (Needs 8.0.2)

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

This problem is also occurring for me in 11.10 using stock packages (only PPAs I have installed have to do with postgresql stuff). I had upgraded kernels to fix issues with my desktop graphics, but the issue persists across 3.0, 3.1 and 3.2RC7. Makes games pretty much unplayable, meaning I have nothing to prevent me from being constructive. =(

If there's any more feedback I can provide from my end, let me know. I'm somewhat new to this launchpad thingy.

Hi, I think there's sufficient info gathered; this bug probably should go upstream. It sounds similar to #899303.

James, the data needed is the /sys/kernel/debug/dri/0/i915_error_state and dmesg, both captured while the system is frozen or after it's recovered.

It might also help to know specific game(s) that reproduce the problem, and any special wine setup needed. The easier we can make it for upstream to reproduce the problem the sooner they'll be able to figure it out.

Pretty much any game that does 3d stuff for me produces it, though at varying frequencies. Both native games and games run in wine. This occurs in both fullscreen and windowed mode for any that I've run and whether or not a flash applet is running somewhere in the background doesn't seem to affect it for me. I have not yet determined what causes it. Load doesn't seem to be the determining factor.

I'm at work at the moment, but when I get a spare bit of time I'll upload the appropriate output.

I'm getting a command not found error for /sys/kernel/debug/dri/0/i915_error_state

Standard Wine from Precise repos, no changes to the config or installations via winetricks.

The game in question is Ski Challenge 2012 (http://www.skichallenge.at/en/download - 80MB download plus 80MB auto-update :-/).
It happens more frequent when I crank up the video settings. Not playing other DirectX games, so I cannot comment on that. I tried to reproduce it with the old 3DMark2001 benchmark but w/o luck, the Unigine benchmarks for Windows wouldn't run in Wine. A smaller program triggering the hangs would be helpful I guess.

The problem affect me when running native games as well, it seems to be a 3d rendering problem, period. My last native game to do it was NightSkyHD from the latest indie bundle, but it was REALLY infrequent there.

Another native game, Saga of Ryzom (nabable free from the software center), causes it to happen reasonably quickly and frequently.

James, I'm not sure if you are supposed to, but do you get the same title (same 0x... address) as this bug report if you try to report the bug with apport?

I successfully reproduced the hangs with the Linux version of the Unigine Heaven benchmark (http://unigine.com/products/heaven/download/ ~233MB, fast torrent download). It immediately threw hangs during the loading phase at the start screen, but I got a different address in the bug report:

[sandybridge-gt2] GPU lockup render.IPEHR: 0x7a000002

Also, dmesg just showed

[83035.298706] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[83035.298766] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 4462766 at 4462765, next 4462767)

in contrast to the messages in my attached "CurrentDmesg.txt".

Attaching the new i915_error_state.

Ok, the above is probably bug 830136.

I do indeed get the same error reported by apport when the problem occurs. In wine and in native games.

What do I need to do to fix my problem with my missing /sys/kernel/debug/dri/0/i915_error_state, so I can appends that and dmesg?

@James, if there is no file /sys/kernel/debug/dri/0/i915_error_state present when your system is frozen, then you likely don't have a GPU lockup bug. Remember, you need to ssh into the box while it's frozen to collect the file (if apport doesn't automatically collect it for you, which it *should* be doing.)

I re-enabled xorg-edgers to see if it no longer broke acceleration in wine and native games (previously there was a long span where neither would work if I was using it) and the bug does not occur. In fact, it runs amazingly well. No screen resets and no lockups. So something in the git repos for mesa, x, the intel driver, or a combo of anything and everything fixes it.

@James, aha, thanks for testing the xorg-edgers.

0x7* gpu lockups are 3d rendering errors (i.e. mesa typically).

Hernando points at bug #830136 which sounds quite similar to this bug. The error codes and symptoms are somewhat different, but both are sandybridge and have been reported as occurring while playing games. This all suggests these two bugs may be dupes (or symptoms of the same underlying bug). #830136 is fixed in the mesa included in xorg-edgers, and since James sees the issue go away when running xorg-edgers, that seems to strengthen this hypothesis.

Hernando, would you mind testing the xorg-edgers PPA as well? If you find the bug can't be reproduced there, that should add proof to this theory.

We will be pulling the 7.11+git mesa into Precise any day now, so we can probably assume this bug will resolve for Precise when that gets merged.

I will also look into SRUing the upstream fix for bug #830136 to Oneiric, so that should resolve that for oneiric users.

I just tried xorg-edgers, with the hopes that it would fix my gpu lockups/screen blackouts. Unfortunately it made the issue worse. In a java-based opengl game (minecraft) I now get screen blackouts like clockwork. Approximately every .5 seconds of playable response for every 3 or 4 seconds of black screen/lock. I had to ppa-purge unfortunately.

I'm afraid I can't test the 0x7b009004 hangs, as I now only seem to be able to reproduce the 0x7a000002 case (I no longer get a crash file when playing the game that originally caused the hang, just the i915_error_state that points to the other code).

Ok, well when xorg-edgers is in a state it can be installed, please install it and verify the 0x7a000002 crashes go away.

As far as I know we haven't introduced anything that would fix the 0x7b009004 crash. However, it's entirely conceivable the 0x7b009004 and 0x7a000002 hangs are just different aspects of the same bug. So, what we need is to verify that with the new mesa neither crash occurs.

Just updated to the xorg-edgers PPA (mesa 8.0.0~git20120110.5a7c3433-0ubuntu0sarvatt), and the situation got a lot worse. The game that originally produced the 7b009004 hangs, then (not sure why) started to only produce 0x7a000002 hangs, now produces 0x7a000003 hangs - one after another. I cannot do anything inside the game, it's black screen → screen recovers → black screen → screen recovers → ... Attaching the error state file.

The native Unigine benchmark linked to in #11 (produced 0x7a000002 hangs) now won't even start:

$ ./x64_1024x768_windowed_tess_disabled.sh Loading "/home/sirius/Desktop/Unigine_Heaven-2.5/bin/../data/heaven_2.5.cfg"...
Engine::init(): clear video settings for "Mesa DRI Intel(R) Sandybridge Desktop 3.0 Mesa 8.0-devel"
Loading "libGL.so.1"...
Loading "libopenal.so.1"...
Set 1024x768 windowed video mode
X Error of failed request: BadRequest (invalid request code or no such operation)
  Major opcode of failed request: 34 (X_UngrabKey)
  Serial number of failed request: 45
  Current serial number in output stream: 45

It started occurring again for me with edgers in the manner that Alex described, every 0.5 to 1 seconds, rendering the computer entirely unusable. However it happened after about 2 hours of having had a game running.

Hrm, pitty.

We will be uploading mesa 8.0rc either today or soon this week. How about we have you guys re-test once that's in, and if it still occurs I'll forward the bug upstream at that point for further analysis.

When you have mesa 8.0rc up, please re-test and report here. Attach a fresh dmesg and i915_error_state.

With the latest updates from edgers and the 3.2rc-2 kernel, I no longer get the issue it seems. Had a marathon gaming session on my laptop when I finally got a day off with no problems whatsoever. There was a recent update to mesa in edgers that I think may have done the trick.

*3.3rc-2 kernel =)

Unfortunately since the push I am now experiencing the same constant lockup that I reported earlier. To be fair, this specific bug may be patched, however I am unable to determine as my system has effectively been rendered unusable. Apport doesn't seem to be picking up the bug. I'll resubmit this new error.

After testing a bit more, I've found that I only experience the issues I reported above when using gnome-shell. Gnome classic seems to run ok. I'll have to do further testing to see if this specific bug is patched on my system under unity/unity 2d or gnome classic.

Ok, after some further testing I'm going to go ahead and say in my experience, this bug appears patched.

My uses with the GPU lock, while similar in symptom, appear to be a secondary unrelated issue. Interestingly when doing a hard reset into gnome-shell, I experience the issues above. When booting into unity and then logging out and logging into gnome-shell, I experience no issue.

I'm now back to 0x7a000002 hangs (mesa 8.0~rc2-0ubuntu4, no relevant PPAs). Unity also died with the first hang, restarting it fails with:

intel_do_flush_locked failed: Input/output error

Attaching error state file.

Thanks everyone for the testing. It appears this is a known mesa bug upstream - https://bugs.freedesktop.org/show_bug.cgi?id=42538

It appears to be particular to sandybridge (and perhaps a specific sandybridge variant).

There are no workarounds we can suggest at this time, aside from not using the affected applications or games.

I don't think you'll find much value in doing further testing of xorg-edgers or other branches of mesa until we get word from upstream about possible patches. We'll try to get patched mesas available as soon as practical once a fix exists.

I believe a sufficient amount of analysis has been done, now it's just a matter of waiting on upstream. Knowing the affected games may well help upstream so feel free to test and comment here with names of other games which produce the bug.

This bug was fixed in the package mesa - 8.0.1-0ubuntu4~lp899159~1

---------------
mesa (8.0.1-0ubuntu4~lp899159~1) precise; urgency=low

  * Add 117_i965_only_set_last_render_target_last.patch: Fix GPU lockups
    on Intel when playing certain games (Ski Challenge 2012, OilRush,
    Trine, and possibly others). These games use MRT (multiple render
    targets), and mesa was not setting the Last Render Target Select
    properly. Cherrypick from upstream, proposed for the stable 8.0
    branch. (LP: #899159)
 -- Bryce Harrington <email address hidden> Tue, 13 Mar 2012 14:26:30 -0700