Bug 39257 - [bisected SNB]Mesa demos engine causes GPU hang
[bisected SNB]Mesa demos engine causes GPU hang
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
All Linux (All)
: high critical
Assigned To: Dan McCabe
Depends on:
  Show dependency treegraph
Reported: 2011-07-15 06:00 UTC by fangxun
Modified: 2011-07-26 02:36 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

i915_error_state for engine (312.75 KB, text/plain)
2011-07-15 06:00 UTC, fangxun

Note You need to log in before you can comment on or make changes to this bug.
Description fangxun 2011-07-15 06:00:54 UTC
Created attachment 49140 [details]
i915_error_state for engine

System Environment:
Arch:           x86-64
Platform:       Huronriver
Libdrm:         (master)2.4.26-1-g8d055890d90c3d92647e3d8b98d32630ef87c2c8
Mesa:           (master)1cf06218e483c1e673e2f19df9116e60478edf30
Xserver:        (master)xorg-server-
Xf86_video_intel: (master)2.15.0-203-g212fa9868767637e8f430485eeb522c99e63fd16
Kernel: (drm-intel-next)99834ea446d5c0da3f6cfa355fe4670840d45f79

Bug detailed description:
When run Mesa demos engine on huronriver, GPU will hang. It is regression. It works fine on pineview and ironlank. 

Reproduce steps:
1. xinit &
2. ./engine
Comment 1 Eric Anholt 2011-07-16 18:03:00 UTC
If it's a regression, the bug report should include a bisect.
Comment 2 Gordon Jin 2011-07-17 22:47:18 UTC
(In reply to comment #1)
> If it's a regression, the bug report should include a bisect.

Bisect is not a must-to-have info from QA -- I'm not considering lacking of bisect info block bug owner's investigation unless this is only reproducible on QA machine. We can make the effort for bisect, but only when we have free time.

Xun, I'm more eager to now if it impacts 7.11 branch?
Comment 3 fangxun 2011-07-17 23:03:54 UTC
It impacts 7.11 branch. GPU hangs when running engine with mesa 7.11 branch on sandybridge.
Comment 4 fangxun 2011-07-18 00:29:14 UTC
Bisect is blocked by mesa build failure. skipping the four commit, the last good commit is 5c742ea1ee0cea031cb99651155d0c7521f42b4e. the last bad commit is bb7ff01deb5c1eb813b90da6f40d987a67e2793b, so the first bad commit maybe any of the four skipped commit and bb7ff01deb5c1eb813b90da6f40d987a67e2793b.

Comment 5 Eric Anholt 2011-07-20 11:56:53 UTC
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>
Comment 6 fangxun 2011-07-26 02:36:47 UTC
Verified with Mesa master 4c84acc86fce5eda0aabcb8aa362fd6b5e6a28f6 and 7.11 b305c956be3fa27467ecbc379de2352926a554d0.