[Bug 68718] [snb] vsync hang

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=68718

--- Comment #29 from Chris Wilson <chris at chris-wilson.co.uk> ---
(In reply to comment #28)
> (In reply to comment #27)
> Oh, because it does it in a circular fashion, so 1 less than 0 is back to
> the bottom?

Right.

> One last question... what makes you think it's this code that's causing
> issues? i.e. what do I look at in the hang to work that out (so that I can
> go and try 100 diff things and make sure that this is the place where things
> are hanging).

In the GPU dump, ACTHD points to the address that the command streamer is at -
usually the dword after what is being executed. IPEHR holds the command
currently being executed. They both indicate that is the wait-for-event command
that is waiting indefinitely, along with the ring-wait flag inside the RING_CTL
register. As this is the only piece of code that tries to program vsync waits,
we can be reasonably sure that it is the culprit. Then it is a guessing game as
to what hardware state is incorrect, or what programming went wrong. To aide
those guesses, we dump a number of other, hopefully relevant, registers.


> Also -- I don't know what kind of resources you have available, but I don't
> exactly have a "rare" hardware setup. Lenovo T420s laptop, internal LVDS
> panel, and either a VGA or HDMI-connected 1920x1200 screen depending on
> where I am (and I'm pretty sure the second screen doesn't actually play a
> part here). 
> 
> Load up chrome and go to google maps (I think the reason I was having
> trouble getting it to hang earlier was that they had for some reason
> temporarily turned off Earth mode... now that it's back, it hangs on load
> again) or that webgl demo.
> 
> Is the suggestion that this is hard to reproduce and I'm in a (relatively)
> unique configuration/setup/etc? Or are lots of people seeing this, which
> makes it no easier to figure out what's going on?

The number of people who use vsync waits is in the minority as anybody with a
compositor will hit a different path. Even then of those, I have seen more
reports of complete system lockups that seem to be rc6 in conjunction with
vsync than reports of this GPU hang. So it may be just that the hang is rare,
or that it requires a particular display/window configuration, or that it
requires particular hardware. (As an anecdote, I have been using vsync on SNB
with a single eDP panel for a couple of years without a single hang - since
adding vsync support for Xv. And one of the tests for the ddx now include
testing vsync on each pipe. Which is more likely to mean that display
configuration plays a role, or just that the sample size is too small.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20140211/e9d4c944/attachment.html>