Hm, the -fixes sha1 you're citing contains pretty much all of -next-queued, safe for a few patches that I've merged in the last few days. But these should not affect snb in any way. Can you please double-check your kernel versions, both the broken commit on -fixes and the working commit in -next-queued?

We used kernel version 3.4.0rc6.
This issue happens on drm-intel-fixes kernel and drm-intel-next-queued kernel.

dmesg on -queued kernel(commit:6f13b7b5be500178d5541b69ab911af2a77ec488):
[   73.313550] [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 16110000, was 16000000
[  101.724586] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[  101.724591] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[  101.728110] [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off
[  107.752785] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[  107.753324] [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off
[  113.772993] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[  113.773508] [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off
[  117.388101] [drm:gen6_sanitize_pm] *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 16000000, was 12000000


Testing on drm-intel-fixes kernel(commit:c6a389f123b9f68d605bb7e0f9b32ec1e3e14132,version:3.1.0rc4), system hangs.
dmesg:
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[drm] capturing error event; look for more information in /debug/dri/0/i915_erro                                                                                                 r_state
[drm:i915_wait_request] *ERROR* i915_wait_request returns -11 (awaiting 252 at 2                                                                                                 50, next 254)

You've mentioned GPU hang a couple of times now... Are you going to share the i915_error_state and full dmesg?

Created attachment 62089 [details]
i915_error_state

Created attachment 62090 [details]
full——dmesg

You're fixes tree is 3.1-rc4-ish. This is known to blow up totally all over the place. You should use -fixes from my drm-intel repository (the same where the -queued branch is). The current tip of that is

commit 89ba829e38bd500f438bc08af4229204c8ed7f35
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue May 22 09:30:33 2012 -0700

    drm/i915: always use RPNSWREQ for turbo change requests

Closing as already fixed (there's really not much difference between -fixes and -queued atm that would even remotely explain this).

Ok, reopening, the 3.1-rc4 was just to hunt for a known-good kernel. And despite what the original report says, it seeems to happen on both -fixes and -queued.

Iirc mesa guys recently merged some fixes and new piglit tests to check whether depth/stencil mimaps work correctly for separate stencil. Have you checked whether this is a mesa problem/regression?

The error-state points towards HiZ as the unit that stalled. I'd focus on the chicken bits patches for a potential fox, but without a known-good kernel I'm probably yapping up the wrong tree.

We're waiting on confirmation that this is a regression in the kernel or, by cross-checking, an issue with mesa/i965.

It is a mesa issue.
It happens on mesa 8.0 branch, It doesn't happen on mesa master branch.

I suspect it's because the 8.0 branch is missing Paul's workarounds.

commit 714b4f6184db84a738cf2d063980f0e19ab03b4b
Author: Paul Berry <stereotype441@gmail.com>
Date:   Thu Apr 26 06:35:56 2012 -0700

    i965/Gen7: Work around GPU hangs due to misaligned depth coordinate offsets.
    
    In i965 Gen7, Mesa has for a long time used the "depth coordinate
    offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to
    render to miplevels other than 0.  Unfortunately, this doesn't work,
    because these offsets must be aligned to multiples of 8, and miplevels
    in the depth buffer are only guaranteed to be aligned to multiples of
    4.  When the offsets aren't aligned to a multiple of 8, the GPU
    sometimes hangs.
    
    As a temporary measure, to avoid GPU hangs, this patch smashes the 3
    LSB's of "depth coordinate offset X/Y" to 0.  This results in
    incorrect rendering to mipmapped depth textures, but that seems like a
    reasonable stopgap while we figure out a better solution.
    
    Avoids GPU hangs in piglit test "depthstencil-render-miplevels" at
    texture sizes that are not powers of 2.
    
    Reviewed-by: Chad Verace <chad.versace@linux.intel.com>

as well as ~1 of that for the equivalent Gen6 fix.  Assigning to Paul to confirm and decide whether to backport the fixes to 8.0.  (I would just do it myself, but I think some infrastructure patches are necessary.)

(In reply to comment #11)
> I suspect it's because the 8.0 branch is missing Paul's workarounds.

(snip)

> Assigning to Paul to
> confirm and decide whether to backport the fixes to 8.0.  (I would just do it
> myself, but I think some infrastructure patches are necessary.)

Ken is correct.  This is a bug which probably has been around since Gen6/Gen7 support was initially added to Mesa.  The patches weren't backported to the 8.0 branch because to apply them without merge conflicts would require an infrastructure patch that probably is too invasive to cherry-pick to 8.0 (3ec0e55: i965: Fix mipmap offsets for HiZ and separate stencil buffers).

Fortunately the merge conflicts aren't very bad--I'll fix them up and send them to the Mesa-dev list for review.

Leaving at "high" priority, since IIRC this GPU hang affects Google Earth.

Patches sent to Mesa-dev list for review ("[PATCH 0/2] i965: Back-port GPU hang workarounds (bug 50271)").

The GPU hang is fixed in the 8.0 branch by the following commits:

commit 889cc4d9225084e15b9e8d010e30b31a87dbfd2d
Author: Paul Berry <stereotype441@gmail.com>
Date:   Thu Apr 26 06:35:56 2012 -0700

    i965/Gen7: Work around GPU hangs due to misaligned depth coordinate offsets.
    
    In i965 Gen7, Mesa has for a long time used the "depth coordinate
    offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to
    render to miplevels other than 0.  Unfortunately, this doesn't work,
    because these offsets must be aligned to multiples of 8, and miplevels
    in the depth buffer are only guaranteed to be aligned to multiples of
    4.  When the offsets aren't aligned to a multiple of 8, the GPU
    sometimes hangs.
    
    As a temporary measure, to avoid GPU hangs, this patch smashes the 3
    LSB's of "depth coordinate offset X/Y" to 0.  This results in
    incorrect rendering to mipmapped depth textures, but that seems like a
    reasonable stopgap while we figure out a better solution.
    
    Avoids GPU hangs in piglit test "depthstencil-render-miplevels" at
    texture sizes that are not powers of 2.
    
    Reviewed-by: Chad Verace <chad.versace@linux.intel.com>
    
    Cherry-picked from 714b4f6184db84a738cf2d063980f0e19ab03b4b
    Conflicts:
    
        src/mesa/drivers/dri/i965/gen7_misc_state.c
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50271

commit 24db6d63dab7cc8d3e5d4482b95d58e46113ba44
Author: Paul Berry <stereotype441@gmail.com>
Date:   Thu Apr 26 06:35:56 2012 -0700

    i965/Gen6: Work around GPU hangs due to misaligned depth coordinate offsets.
    
    In i965 Gen6, Mesa has for a long time used the "depth coordinate
    offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to
    render to miplevels other than 0.  Unfortunately, this doesn't work,
    because these offsets must be aligned to multiples of 8, and miplevels
    in the depth buffer are only guaranteed to be aligned to multiples of
    4.  When the offsets aren't aligned to a multiple of 8, the GPU
    sometimes hangs.
    
    As a temporary measure, to avoid GPU hangs, this patch smashes the 3
    LSB's of "depth coordinate offset X/Y" to 0.  This results in
    incorrect rendering to mipmapped depth textures, but that seems like a
    reasonable stopgap while we figure out a better solution.
    
    (Note that we have only ever observed this GPU hang on Gen6 when HiZ
    is enabled, so another possible stopgap would be to disable HiZ).
    
    Avoids GPU hangs in piglit test "depthstencil-render-miplevels" at
    texture sizes that are not powers of 2.
    
    Reviewed-by: Chad Verace <chad.versace@linux.intel.com>
    
    Cherry-picked from a683012a80a3408b3b71f22b2a97d9eaaac11a46
    Conflicts:
    
        src/mesa/drivers/dri/i965/brw_misc_state.c
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50271


I'm leaving the bug open, since the above commits do not produce correct rendering; they merely avoid a GPU hang.  So all of the hanging Piglit tests should now produce a FAIL result.  I'm changing the bug to low priority, since the incorrect rendering happens in a rare enough corner case that it's unlikely to every be a problem for any real-world apps.  If in the future we discover a real-world app (or a conformance test) that produces incorrect rendering due to this bug, we can always raise the priority again.

As mentioned above, working around the GPU hang results in incorrect rendering.  The following piglit test failures are now expected:

- fbo/fbo-depth-array
- spec/ARB_depth_buffer_float/fbo-clear-formats
- spec/ARB_depth_texture/fbo-clear-formats
- spec/EXT_packed_depth_stencil/fbo-clear-formats
- All texturing/depthstencil-render-miplevels tests

These tests have failed on the master branch for some time.  Now that the fix has been cherry-picked back to the 8.0 branch, they fail on 8.0 as well.

Eric Anholt has started investigating a technique to fix this bug for good, but it is not yet ready for use (branch "depthstencil" of git://people.freedesktop.org/~anholt/mesa).

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

The original hang is fixed, the remaining failure is a non-regression, and it can continue to be tracked by looking at piglit results.

Verified.Fixed.