On 7/18/2022 05:15, Tvrtko Ursulin wrote:
On 13/07/2022 00:31, John.C.Harrison@xxxxxxxxx wrote:
From: Matthew Brost <matthew.brost@xxxxxxxxx>
Remove bogus GEM_BUG_ON which compared kernel context timeline seqno to
seqno in memory on engine PM unpark. If a GT reset occurred these values
might not match as a kernel context could be skipped. This bug was
hidden by always switching to a kernel context on park (execlists
requirement).
Reset of the kernel context? Under which circumstances does that happen?
As per description, the issue is with full GT reset.
It is unclear if the claim is this to be a general problem or the
assert is only invalid with the GuC. Lack of a CI reported issue
suggests it is not a generic problem?
Currently it is not an issue because we always switch to the kernel
context because that's how execlists works and the entire driver is
fundamentally based on execlist operation. When we stop using the kernel
context as a (non-functional) barrier when using GuC submission, then
you would see an issue without this fix.
John.
Regards,
Tvrtko
Signed-off-by: Matthew Brost <matthew.brost@xxxxxxxxx>
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index b0a4a2dbe3ee9..fb3e1599d04ec 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -68,8 +68,6 @@ static int __engine_unpark(struct intel_wakeref *wf)
ce->timeline->seqno,
READ_ONCE(*ce->timeline->hwsp_seqno),
ce->ring->emit);
- GEM_BUG_ON(ce->timeline->seqno !=
- READ_ONCE(*ce->timeline->hwsp_seqno));
}
if (engine->unpark)
