(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?

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.
bb7ff01deb5c1eb813b90da6f40d987a67e2793b(bad)
588cebce2d5b6afd24b72603d744d390481310dd(skip)
04e3f1d3c29c68343e709d566b7fe13d617f8d13(skip)
a82a43e8d99e1715dd11c9c091b5ab734079b6a6(skip)
855f56ca13c1003396a81da1a110357d624a2101(skip)
5c742ea1ee0cea031cb99651155d0c7521f42b4e(good)

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>