On 03/06/2019 12:19, Petri Latvala wrote:
On Mon, Jun 03, 2019 at 11:39:25AM +0100, Tvrtko Ursulin wrote:
On 03/06/2019 11:32, Petri Latvala wrote:
On Mon, Jun 03, 2019 at 11:19:48AM +0100, Tvrtko Ursulin wrote:
On 29/05/2019 14:24, Chris Wilson wrote:
If we run out of engines, intel_get_current_physical_engine() degrades
into an infinite loop as although it advanced the iterator, it did not
update its local engine pointer.
We had one infinite loop in there already.. AFAIR it was on one engine
platforms. Does the new incarnation happen actually via the
__for_each_physical_engine iterator or perhaps only when calling
intel_get_current_physical_engine after loop end? Why it wasn't seen in
testing?
The new incarnation happens with a wedged GPU. That's a case that's
hard to come by in testing.
1.
Colour me confused. :) How does a wedged GPU affect this loop?
Wedging could be a red herring, but regardless the GPU was in a funky
state.
An easy reproduction method is just
# ./perf_pmu
(as normal user, not root!)
See it now, so the problem is code is not capable of handling zero
engines (which it happens if no access to drm master like in your example).
As such, Chris' patch looks okay to me.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
