Bug 36821

Something fishy is happening with the bisect.  For example, commit 04e3f1d3 adds some comments and moves a structure field.  There is no way that commit broke the build.  I recommend doing 'git clean -fxd' at each bisect step.  Mesa's build system is notoriously bad, so there could be garbage left over from previous builds that cause later builds to fail.

Please retest with the kernel updated to keithp's drm-intel-next with the forcewake patches.  Incorrect forcewake handling could add up to intermittent GPU hangs.

Created attachment 47180 [details]
oglc api-mtexcoord output

Tested with keithp's drm-intel-next kernel 9e3c25, System doesn't hang but GPU hangs when case running, and the case still fails. 
dmesg shows:
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung

Created attachment 47182 [details]
i915_error_state

(In reply to comment #1)
> Something fishy is happening with the bisect.  For example, commit 04e3f1d3
> adds some comments and moves a structure field.  There is no way that commit
> broke the build.  I recommend doing 'git clean -fxd' at each bisect step. 
> Mesa's build system is notoriously bad, so there could be garbage left over
> from previous builds that cause later builds to fail.

I do 'git clean -fxd' at each bisect step, but the four mesa commit build still fail.

Reproduced the failure (./oglconform -D 33 -s -v 3 -1 api-texcoord.c), and a workaround (always_flush_batch=true in environment).

I did the bisect by rebasing the change sequence with the build failure so that the build never failed (squash last commit into first build-failing commit).  That leads the bisect to:

commit a82a43e8d99e1715dd11c9c091b5ab734079b6a6
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Apr 22 16:00:14 2011 -0700

    i965/gen6: Use the dynamic state base address to reduce relocations.

The specific hunk that triggers the failure is moving brw_state_base_address, and bisecting *that* shows that it's when brw_state_base_address moves above gen6_vs_state.

commit 3e5d36267d8c9536490c902f785137a7fa0637fc
Author: Eric Anholt <eric@anholt.net>
Date:   Tue Jul 19 15:06:15 2011 -0700

    i965: Apply a homebrew workaround for GPU hang in OGLC api-texcoord.
    
    The behavior of flushes in the hardware is a maze of twisty passages,
    and strangely the VS constants appear to be loaded during a pipeline
    flush instead of at the time of the packet emit according to the
    simulator.  On moving the STATE_BASE_ADDRESS packet to where it really
    needed to live (in order for data loads by other packets to be
    correct), we sometimes no longer got a flush between those packets
    where we apparently needed it.  This replicates the flushes implied by
    a STATE_BASE_ADDRESS update, fixing the GPU hangs in OGLC and the
    "engine" demo.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36821
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39257
    Tested-by: Keith Packard <keithp@keithp.com> (bzflag and etracer fixed)
    Acked-by: Kenneth Graunke <kenneth@whitecape.org>

Verified with master commit 1284d5b25507a56634519ac385cbc00a00b94417.