Bug 62141

cc'ing the crap out of this.

I can confirm that commit triggers a hard lockup on the first glxgears frame after booting on this i5-2500 (snb gt1).

Just to check, have you tested this with v3.8 kernels already? Specifically

commit 6547fbdbfff62c99e4f7b4f985ff8b3454f33b0f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Dec 14 23:38:29 2012 +0100

    drm/i915: Implement WaSetupGtModeTdRowDispatch
 

That's the only gt1 snb thing I remember off-hand which might help.

Iirc there's more snb gt1 stuff for the userspace part of the driver in the w/a db, but would need to check (travelling atm).

Presuming ofc that it's a hw fail we now trigger thanks to slightly different code.

whats a 3.8 kernel? there is only one kernel to test things with Linus :-)

and yes it hangs with every kernel I threw at it, 3.8.x and 3.9-*

http://git.chromium.org/gitweb/?p=chromiumos/overlays/chromiumos-overlay.git;a=blob;f=media-libs/mesa/files/9.0-i965-Make-sure-we-do-render-bet
ween-two-hiz-flushes.patch;h=590b13b4c3da13be6ad8a8115576e6320cef7825;hb=HEAD

this marcheu hack also works around the issue for me here.

(In reply to comment #5)
> http://git.chromium.org/gitweb/?p=chromiumos/overlays/chromiumos-overlay.git;
> a=blob;f=media-libs/mesa/files/9.0-i965-Make-sure-we-do-render-bet
> ween-two-hiz-flushes.patch;h=590b13b4c3da13be6ad8a8115576e6320cef7825;hb=HEAD
> 
> this marcheu hack also works around the issue for me here.

Adding my own +1 to the above patch fixing the problem for me as well.

I've no clue what it DOES, as this is will outside my domain of expertise, but I can tell you that when I build mesa 9.1.1 with the above referenced patch applied, nothing added to the boot options for disabling RC6, I no longer see this bug.

Been testing and using the setup for more than a week.

Here are the gross specs for my setup:

Kernel: 3.8.2
GPU:    8086:0106
Rev:    09
Driver: i915
Boot:   root=/dev/sda2 ro vga=current  splash quiet BOOT_IMAGE=../vmlinuz
Mesa:   9.1.1

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

Arch Linux: Our users report that activating SNA seems to be a workaround as well.

I can also confirm that bug goes away when SNA is enabled. On my driver it was enabled by default (using configure switch) up to some point, but after I rebuilt driver without default-accel switch, GDM hung the system on boot - I had to hard reset the machine.

I'm not 100% sure this is the same issue, but it might be as I have the exact same symptoms and pci id.

I opened Bug 63899 not know about this report.

I managed to get the i915_error_state and some kernel trace by limiting myself to just X and glxgears and waiting for a watchdog to unhang my system.  That output is attached to the other bug report, not sure if it is of any assistance.

So... Daniel seems to think this is caused by blorp not setting something up quite correctly.

Daniel: Can you give Paul some details about this.

Paul: Can you look into this more?

This seems to be causing quite a lot of pain for anyone trying to update gnome shell, so this should be considered pretty high priority.

After all the debug I've done, we're pretty sure this is the same as 56416.  There's no clear fix yet.  The next step in userland is to try forcing a non-blorp blit as the first op on context creation (a color blorp blit was insufficient).  But we're concerned that this problem might show up on resume/thaw, in which case an in-userland solution isn't good enough since we don't know when resume/thaw are.

*** This bug has been marked as a duplicate of bug 56416 ***