Bug 25994

Created attachment 32573 [details]
Xorg.0.log

Created attachment 32574 [details]
dmesg

Created attachment 32575 [details]
intel_gpu_dump.gz

Created attachment 32576 [details]
lspci.txt

Created attachment 32577 [details]
stellarium.log

I tried to turn KMS off passing i915.modeset=0 to kernel.
Bug still reproducible. I also tried kernels 2.6.31 and 2.6.30.
With 2.6.31 bug appears as described above. With 2.6.30 behavior
is similar (Stellarium hangs at startup, GPU seems hang leaving
no chances to see working graphics without reboot) but no error messages
in dmesg appears. Downgrading mesa from 7.7 to 7.5.2 make no changes.

I have tried latest 2.6.33-rc4 kernel. Also I have tried to pass pci=nomsi
option to kernel. Bug appears anyway with the same symptoms.

Created attachment 32646 [details]
shader.c

Latest revisions of Stellarium don't cause the bug anymore.
I've found that this happened after modification of the vertex shader
used in Stellarium. I've extracted the idea of that modification into
the attached file.

The attached program uses simple vertex shader.
The same logic is written in two correct equivalent (I believe)
variants. Both works fine on my desktop with NVIDIA GPU.
But only the first works OK on my laptop with GM45 GPU while
the second immediately causes GPU hang.

Chipset: 965GM
System architecture: x86_64
xf86-video-intel 2.9.1
xserver 1.7.4
mesa 7.7
libdrm 2.4.17
kernel 2.6.32-gentoo-r1
Linux distribution: Gentoo
Machine: Dell Vostro A860
Display connector: LVDS

Bug reproduced when running shader.c posted by Constantin Baranov: causes GPU hang (as expected) when running second variant, sometimes causes X server crash.

Bug is alive with the latest git versions of libdrm and mesa (w/o gallium).
I doubt about true location of the bug, so I'm CC'ing mesa developers.

Created attachment 32915 [details]
Mortal fragment shader

A fragment shader with 'discard' statement also kills GPU.
Discarding the 'discard' line in this source will save GPU.

Mortal fragment shader posted by Constantin Baranov reproduces bug on my hardware (see above), causes gpu hung and in most cases X server crash. Without 'discard' line works fine.

Happy to say, someone with nickname pino had looked at this bug report and tested shader.c and Mortal fragment shader on his hardware:

Chipset: GM45
System architecture: x86
xserver-xorg-video-intel 2.6.3
xserver 1.7.4
mesa 7.4
libdrm 2.4.5
kernel 2.6.28-11-generic 
Linux distribution: Ubuntu 9.04
Machine: Lenovo G550 model 20023
Display connector: LVDS

As he said, he haven't encountered any bugs during Mortal fragment shader test. 

shader.c with "#if 0" causes X server crash and GPU hang.

I've added glsl-vs-main-return and glsl-fs-main-return to piglit to test the return from main() behavior.  This is the first time I've seen that used in a shader.  The 965 driver in mesa master now rejects these shaders until we get the codegen fixed up to handle it, so it won't hang.

commit 4de7a3b76add1940f7316253a619c3728025d9db
Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Mon Sep 13 11:05:05 2010 -0700

    i965: Request that returns be lowered in shader main
    
    Fixes piglit tests glsl-vs-main-return and glsl-fs-main-return.

commit 87708e8c90220cc1997cef9de9b394c04d952be9
Author: Luca Barbieri <luca@luca-barbieri.com>
Date:   Tue Sep 7 02:15:26 2010 +0200

    glsl: call ir_lower_jumps according to compiler options

commit 3361cbac2a883818efeb2b3e27405eeefce60f63
Author: Luca Barbieri <luca@luca-barbieri.com>
Date:   Tue Sep 7 00:24:08 2010 +0200

    glsl: add continue/break/return unification/elimination pass (v2)
    
    Changes in v2:
    - Base class renamed to ir_control_flow_visitor
    - Tried to comply with coding style
    
    This is a new pass that supersedes ir_if_return and "lowers" jumps
    to if/else structures.
    
    Currently it causes no regressions on softpipe and nv40, but I'm not sure
    whether the piglit glsl tests are thorough enough, so consider this
    experimental.
    
    It can be asked to:
    1. Pull jumps out of ifs where possible
    2. Remove all "continue"s, replacing them with an "execute flag"
    3. Replace all "break" with a single conditional one at the end of the loop
    4. Replace all "return"s with a single return at the end of the function,
       for the main function and/or other functions
    
    This gives several great benefits:
    1. All functions can be inlined after this pass
    2. nv40 and other pre-DX10 chips without "continue" can be supported
    3. nv30 and other pre-DX10 chips with no control flow at all are better supp
    
    Note that for full effect we should also teach the unroller to unroll
    loops with a fixed maximum number of iterations but with the canonical
    conditional "break" that this pass will insert if asked to.
    
    Continues are lowered by adding a per-loop "execute flag", initialized to
    TRUE, that when cleared inhibits all execution until the end of the loop.
    
    Breaks are lowered to continues, plus setting a "break flag" that is checked
    at the end of the loop, and trigger the unique "break".
    
    Returns are lowered to breaks/continues, plus adding a "return flag" that
    causes loops to break again out of their enclosing loops until all the
    loops are exited: then the "execute flag" logic will ignore everything
    until the end of the function.
    
    Note that "continue" and "return" can also be implemented by adding
    a dummy loop and using break.
    However, this is bad for hardware with limited nesting depth, and
    prevents further optimization, and thus is not currently performed.