Quoting Tvrtko Ursulin (2019-11-11 16:31:09) > > On 11/11/2019 13:32, Chris Wilson wrote: > > The gem_ctx_persistence/smoketest was detecting an odd coherency issue > > inside the LRC context image; that the address of the ring buffer did > > not match our associated struct intel_ring. As we set the address into > > the context image when we pin the ring buffer into place before the > > context is active, that leaves the question of where did it get > > overwritten. Either the HW context save occurred after our pin which > > would imply that our idle barriers are broken, or we overwrote the > > context image ourselves. It is only in reset_active() where we dabble > > inside the context image outside of a serialised path from schedule-out; > > but we could equally perform the operation inside schedule-in which is > > then fully serialised with the context pin -- and remains serialised by > > the engine pulse with kill_context(). (The only downside, aside from > > doing more work inside the engine->active.lock, was the plan to merge > > all the reset paths into doing their context scrubbing on schedule-out > > needs more thought.) > > So process_csb is not under the engine lock and hence schedule_out can > race with schedule_in meaning schedule_out should refrain from doing > non-trivial work. I'm stealing that for a comment in schedule_out! Thanks, -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
