Created attachment 32462 [details]
Test case which locks up Intel KMS

I originally posted this to the dri-devel mailing list, and it was suggested that I file a bug report here.  The test case attached here is updated slightly from the one posted to the mailing list.

Mesa 7.7 manages to lock up the Intel KMS driver for me in some
circumstances.  After running the test case (attached), the display
locks up and my kernel logs are spammed with

  [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
  render error detected, EIR: 0x00000000
  [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 5628 at 5621)
  [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
  render error detected, EIR: 0x00000000
  [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 5633 at 5621)
  [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
  render error detected, EIR: 0x00000000
  ...

until I reset the box (other tasks continue to run on the machine).  At
least all kernel versions 2.6.32 through to latest Linus git at the time
of posting are affected, but mesa 7.5.2 does not trigger the lockup.
Another interesting bit that appears in my kernel log is

  mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
  [drm] MTRR allocation failed.  Graphics performance may suffer.

The Xorg log reports my graphics card as Intel(R) G45/G43. The lockup
occurs when I try to run the following fragment shader:

  uniform bool useSecondary;
  uniform sampler2D tex0, tex1; /* Assigned values 0 and 1, respectively. */
  void main(void)
  {
  	vec4 primary   = texture2D(tex0, gl_TexCoord[0].st);
  	vec4 secondary = texture2D(tex1, gl_TexCoord[0].st);
  	vec3 colour    = (1-primary.a)*gl_Color.rgb + primary.a*primary.rgb;
  
  	/*
	 * Removing the "if useSecondary" here (but keeping the
	 * multiplication) causes the shader to work.
  	 * The failure does not depend on the value assigned to useSecondary.
	 */
  	if (useSecondary) {
  		colour *= secondary.rgb;
  	}
  
  	gl_FragColor = vec4(colour, 1);
  }

Since textures seem to be required to trigger the issue, I have attached
an archive containing the test case -- glew, glut and libpng are
required.  The test case works correctly with the software rasterizer.

Since posting to the list, I also managed to trigger the same behaviour by a different means (ostensibly by creating very large vertex buffer objects, but I haven't really spent much time investigating).  If desired, I can try to produce another test case for that.