On 01/10/2018 14:26, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-01 14:15:49)
On 01/10/2018 12:06, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-10-01 11:51:23)
Hm hm hm... my initial thought was that interrupts could be more delayed
than breadcrumb writes (more than one context ahead), in which case the
process_csb below could be premature and the assert would trigger. But I
must be forgetting something since that would also mean we would
prematurely unpin the context. So I must be forgetting something..
There will have been at least one CS event written because we have
switched contexts due to the unpin being one seqno behind. I have not
(yet) observed CS events being out of order with breadcrumb writes (and
we have very strict checking) so confident that a single process_csb()
is required rather than a loop.
I did not mean out of order but just delayed.
Say port 0 & 1 are both submitted, we observe seqno 1 & 2 as complete,
but the ctx complete irq/handler has been delayed. We go to unpin ctx0
(port0) but ce->active hasn't been cleared due no ctx complete yet so
the assert triggers. Impossible in your experience?
I have not seen anything to doubt that the CS interrupts, and more
importantly here, the CS events are delayed. It's the CS event itself
that we care about, and I think we are very safe in our assertion that
it is written on the context switch prior to the breadcrumb in the
second context.
Ugh.. yes.. direct call of the tasklet exactly has nothing to do with
irq delivery. My confusion.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
