* [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno
2021-01-11 10:57 [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Chris Wilson
@ 2021-01-11 10:57 ` Chris Wilson
2021-01-11 16:03 ` Tvrtko Ursulin
2021-01-11 10:57 ` [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting Chris Wilson
` (4 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Chris Wilson @ 2021-01-11 10:57 UTC (permalink / raw)
To: intel-gfx; +Cc: Chris Wilson
On the off chance that we need to arbitrate before launching the
payload, perform the check after we signal the request is ready to
start. Assuming instantaneous processing of the CS event, the request
will then be treated as having started when we make the decisions as to
how to process that CS event.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 2e36e0a9d8a6..9a182652a35e 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -361,19 +361,19 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq)
if (IS_ERR(cs))
return PTR_ERR(cs);
+ *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
+ *cs++ = hwsp_offset(rq);
+ *cs++ = 0;
+ *cs++ = rq->fence.seqno - 1;
+
/*
* Check if we have been preempted before we even get started.
*
* After this point i915_request_started() reports true, even if
* we get preempted and so are no longer running.
*/
- *cs++ = MI_ARB_CHECK;
*cs++ = MI_NOOP;
-
- *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
- *cs++ = hwsp_offset(rq);
- *cs++ = 0;
- *cs++ = rq->fence.seqno - 1;
+ *cs++ = MI_ARB_CHECK;
intel_ring_advance(rq, cs);
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno
2021-01-11 10:57 ` [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno Chris Wilson
@ 2021-01-11 16:03 ` Tvrtko Ursulin
2021-01-11 16:10 ` Chris Wilson
0 siblings, 1 reply; 17+ messages in thread
From: Tvrtko Ursulin @ 2021-01-11 16:03 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On 11/01/2021 10:57, Chris Wilson wrote:
> On the off chance that we need to arbitrate before launching the
> payload, perform the check after we signal the request is ready to
> start. Assuming instantaneous processing of the CS event, the request
> will then be treated as having started when we make the decisions as to
> how to process that CS event.
What is the wider context with this change?
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 2e36e0a9d8a6..9a182652a35e 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -361,19 +361,19 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq)
> if (IS_ERR(cs))
> return PTR_ERR(cs);
>
> + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
> + *cs++ = hwsp_offset(rq);
> + *cs++ = 0;
> + *cs++ = rq->fence.seqno - 1;
> +
Strictly this movement even makes the existing comment (below) more correct.
> /*
> * Check if we have been preempted before we even get started.
> *
> * After this point i915_request_started() reports true, even if
> * we get preempted and so are no longer running.
> */
> - *cs++ = MI_ARB_CHECK;
> *cs++ = MI_NOOP;
> -
> - *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
> - *cs++ = hwsp_offset(rq);
> - *cs++ = 0;
> - *cs++ = rq->fence.seqno - 1;
> + *cs++ = MI_ARB_CHECK;
Special reason to have NOOP before MI_ARB_CHECK or would more common
NOOP padding at the end be suitable?
Regards,
Tvrtko
>
> intel_ring_advance(rq, cs);
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno
2021-01-11 16:03 ` Tvrtko Ursulin
@ 2021-01-11 16:10 ` Chris Wilson
2021-01-12 9:14 ` Tvrtko Ursulin
0 siblings, 1 reply; 17+ messages in thread
From: Chris Wilson @ 2021-01-11 16:10 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx
Quoting Tvrtko Ursulin (2021-01-11 16:03:48)
>
> On 11/01/2021 10:57, Chris Wilson wrote:
> > On the off chance that we need to arbitrate before launching the
> > payload, perform the check after we signal the request is ready to
> > start. Assuming instantaneous processing of the CS event, the request
> > will then be treated as having started when we make the decisions as to
> > how to process that CS event.
>
> What is the wider context with this change?
Just thinking about the impact of MI_ARB_ONOFF. It's the next patch that
sparked the curiosity at that is trying to address a missed arbitration
point on the semaphore-wait miss.
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> > drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > index 2e36e0a9d8a6..9a182652a35e 100644
> > --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> > @@ -361,19 +361,19 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq)
> > if (IS_ERR(cs))
> > return PTR_ERR(cs);
> >
> > + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
> > + *cs++ = hwsp_offset(rq);
> > + *cs++ = 0;
> > + *cs++ = rq->fence.seqno - 1;
> > +
>
> Strictly this movement even makes the existing comment (below) more correct.
>
> > /*
> > * Check if we have been preempted before we even get started.
> > *
> > * After this point i915_request_started() reports true, even if
> > * we get preempted and so are no longer running.
> > */
> > - *cs++ = MI_ARB_CHECK;
> > *cs++ = MI_NOOP;
> > -
> > - *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
> > - *cs++ = hwsp_offset(rq);
> > - *cs++ = 0;
> > - *cs++ = rq->fence.seqno - 1;
> > + *cs++ = MI_ARB_CHECK;
>
> Special reason to have NOOP before MI_ARB_CHECK or would more common
> NOOP padding at the end be suitable?
The so small it's barely a reason was to put as much distance (those
whole 6 cycles) between the store and the arbitration point.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno
2021-01-11 16:10 ` Chris Wilson
@ 2021-01-12 9:14 ` Tvrtko Ursulin
0 siblings, 0 replies; 17+ messages in thread
From: Tvrtko Ursulin @ 2021-01-12 9:14 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On 11/01/2021 16:10, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2021-01-11 16:03:48)
>>
>> On 11/01/2021 10:57, Chris Wilson wrote:
>>> On the off chance that we need to arbitrate before launching the
>>> payload, perform the check after we signal the request is ready to
>>> start. Assuming instantaneous processing of the CS event, the request
>>> will then be treated as having started when we make the decisions as to
>>> how to process that CS event.
>>
>> What is the wider context with this change?
>
> Just thinking about the impact of MI_ARB_ONOFF. It's the next patch that
> sparked the curiosity at that is trying to address a missed arbitration
> point on the semaphore-wait miss.
>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> ---
>>> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 12 ++++++------
>>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
>>> index 2e36e0a9d8a6..9a182652a35e 100644
>>> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
>>> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
>>> @@ -361,19 +361,19 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq)
>>> if (IS_ERR(cs))
>>> return PTR_ERR(cs);
>>>
>>> + *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
>>> + *cs++ = hwsp_offset(rq);
>>> + *cs++ = 0;
>>> + *cs++ = rq->fence.seqno - 1;
>>> +
>>
>> Strictly this movement even makes the existing comment (below) more correct.
>>
>>> /*
>>> * Check if we have been preempted before we even get started.
>>> *
>>> * After this point i915_request_started() reports true, even if
>>> * we get preempted and so are no longer running.
>>> */
>>> - *cs++ = MI_ARB_CHECK;
>>> *cs++ = MI_NOOP;
>>> -
>>> - *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
>>> - *cs++ = hwsp_offset(rq);
>>> - *cs++ = 0;
>>> - *cs++ = rq->fence.seqno - 1;
>>> + *cs++ = MI_ARB_CHECK;
>>
>> Special reason to have NOOP before MI_ARB_CHECK or would more common
>> NOOP padding at the end be suitable?
>
> The so small it's barely a reason was to put as much distance (those
> whole 6 cycles) between the store and the arbitration point.
Overall on the patch, there could be slight difference on how
i915_request_started reports true and would now allow to be preempted
after that point, even if the user payload itself would not be
preemptable. Obviously that applies on Gen8, maybe on later Gens with
like non-preemptible media batches or so. I can't think that it would
(or should) cause a problem though, just thinking out loud. So don't
know really, sounds safe to experiment.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
2021-01-11 10:57 [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Chris Wilson
2021-01-11 10:57 ` [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno Chris Wilson
@ 2021-01-11 10:57 ` Chris Wilson
2021-01-11 16:19 ` Tvrtko Ursulin
2021-01-11 10:57 ` [Intel-gfx] [PATCH 4/4] drm/i915/selftests: Include engine name after reset failure Chris Wilson
` (3 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Chris Wilson @ 2021-01-11 10:57 UTC (permalink / raw)
To: intel-gfx; +Cc: Chris Wilson
During igt_reset_nop_engine, it was observed that an unexpected failed
engine reset lead to us busywaiting on the stop-ring semaphore (set
during the reset preparations) on the first request afterwards. There was
no explicit MI_ARB_CHECK in this sequence as the presumption was that
the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point.
It did not in this circumstance, so force it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 9a182652a35e..e9ac281644cc 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -567,6 +567,7 @@ u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs)
static u32 *gen12_emit_preempt_busywait(struct i915_request *rq, u32 *cs)
{
+ *cs++ = MI_ARB_CHECK;
*cs++ = MI_SEMAPHORE_WAIT_TOKEN |
MI_SEMAPHORE_GLOBAL_GTT |
MI_SEMAPHORE_POLL |
@@ -575,7 +576,6 @@ static u32 *gen12_emit_preempt_busywait(struct i915_request *rq, u32 *cs)
*cs++ = preempt_address(rq->engine);
*cs++ = 0;
*cs++ = 0;
- *cs++ = MI_NOOP;
return cs;
}
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
2021-01-11 10:57 ` [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting Chris Wilson
@ 2021-01-11 16:19 ` Tvrtko Ursulin
2021-01-11 16:27 ` Chris Wilson
0 siblings, 1 reply; 17+ messages in thread
From: Tvrtko Ursulin @ 2021-01-11 16:19 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On 11/01/2021 10:57, Chris Wilson wrote:
> During igt_reset_nop_engine, it was observed that an unexpected failed
> engine reset lead to us busywaiting on the stop-ring semaphore (set
> during the reset preparations) on the first request afterwards. There was
> no explicit MI_ARB_CHECK in this sequence as the presumption was that
> the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point.
> It did not in this circumstance, so force it.
In other words MI_SEMAPHORE_POLL is not a preemption point? Can't
remember if I knew that or not..
1)
Why not the same handling in !gen12 version?
2)
Failed reset leads to busy-hang in following request _tail_? But there
is an arb check at the start of following request as well. Or in cases
where we context switch into the middle of a previously executing request?
But why would that busy hang? Hasn't the failed request unpaused the ring?
Regards,
Tvrtko
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 9a182652a35e..e9ac281644cc 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -567,6 +567,7 @@ u32 *gen11_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs)
>
> static u32 *gen12_emit_preempt_busywait(struct i915_request *rq, u32 *cs)
> {
> + *cs++ = MI_ARB_CHECK;
> *cs++ = MI_SEMAPHORE_WAIT_TOKEN |
> MI_SEMAPHORE_GLOBAL_GTT |
> MI_SEMAPHORE_POLL |
> @@ -575,7 +576,6 @@ static u32 *gen12_emit_preempt_busywait(struct i915_request *rq, u32 *cs)
> *cs++ = preempt_address(rq->engine);
> *cs++ = 0;
> *cs++ = 0;
> - *cs++ = MI_NOOP;
>
> return cs;
> }
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
2021-01-11 16:19 ` Tvrtko Ursulin
@ 2021-01-11 16:27 ` Chris Wilson
2021-01-11 17:12 ` Tvrtko Ursulin
0 siblings, 1 reply; 17+ messages in thread
From: Chris Wilson @ 2021-01-11 16:27 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx
Quoting Tvrtko Ursulin (2021-01-11 16:19:40)
>
> On 11/01/2021 10:57, Chris Wilson wrote:
> > During igt_reset_nop_engine, it was observed that an unexpected failed
> > engine reset lead to us busywaiting on the stop-ring semaphore (set
> > during the reset preparations) on the first request afterwards. There was
> > no explicit MI_ARB_CHECK in this sequence as the presumption was that
> > the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point.
> > It did not in this circumstance, so force it.
>
> In other words MI_SEMAPHORE_POLL is not a preemption point? Can't
> remember if I knew that or not..
MI_SEMAPHORE_WAIT | POLL is most definitely a preemption point on a
miss.
> 1)
> Why not the same handling in !gen12 version?
Because I think it's a bug in tgl [a0 at least]. I think I've seen the
same symptoms on tgl before, but not earlier. This is the first time the
sequence clicked as to why it was busy spinning. Random engine reset
failures are rare enough -- I was meant to also write a test case to
inject failure.
> 2)
> Failed reset leads to busy-hang in following request _tail_? But there
> is an arb check at the start of following request as well. Or in cases
> where we context switch into the middle of a previously executing request?
It was the first request submitted after the failed reset. We expect to
clear the ring-stop flag on the CS IDLE->ACTIVE event.
> But why would that busy hang? Hasn't the failed request unpaused the ring?
The engine was idle at the time of the failed reset. We left the
ring-stop set, and submitted the next batch of requests. We hit the
MI_SEMAPHORE_WAIT(ring-stop) at the end of the first request, but
without hitting an arbitration point (first request, no init-breadcrumb
in this case), the semaphore was stuck.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
2021-01-11 16:27 ` Chris Wilson
@ 2021-01-11 17:12 ` Tvrtko Ursulin
2021-01-11 21:54 ` Chris Wilson
0 siblings, 1 reply; 17+ messages in thread
From: Tvrtko Ursulin @ 2021-01-11 17:12 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On 11/01/2021 16:27, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2021-01-11 16:19:40)
>>
>> On 11/01/2021 10:57, Chris Wilson wrote:
>>> During igt_reset_nop_engine, it was observed that an unexpected failed
>>> engine reset lead to us busywaiting on the stop-ring semaphore (set
>>> during the reset preparations) on the first request afterwards. There was
>>> no explicit MI_ARB_CHECK in this sequence as the presumption was that
>>> the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point.
>>> It did not in this circumstance, so force it.
>>
>> In other words MI_SEMAPHORE_POLL is not a preemption point? Can't
>> remember if I knew that or not..
>
> MI_SEMAPHORE_WAIT | POLL is most definitely a preemption point on a
> miss.
>
>> 1)
>> Why not the same handling in !gen12 version?
>
> Because I think it's a bug in tgl [a0 at least]. I think I've seen the
> same symptoms on tgl before, but not earlier. This is the first time the
> sequence clicked as to why it was busy spinning. Random engine reset
> failures are rare enough -- I was meant to also write a test case to
> inject failure.
Random engine reset failure you think is a TGL issue?
>
>> 2)
>> Failed reset leads to busy-hang in following request _tail_? But there
>> is an arb check at the start of following request as well. Or in cases
>> where we context switch into the middle of a previously executing request?
>
> It was the first request submitted after the failed reset. We expect to
> clear the ring-stop flag on the CS IDLE->ACTIVE event.
>
>> But why would that busy hang? Hasn't the failed request unpaused the ring?
>
> The engine was idle at the time of the failed reset. We left the
> ring-stop set, and submitted the next batch of requests. We hit the
> MI_SEMAPHORE_WAIT(ring-stop) at the end of the first request, but
> without hitting an arbitration point (first request, no init-breadcrumb
> in this case), the semaphore was stuck.
So a kernel context request? Why hasn't IDLE->ACTIVE cleared ring stop?
Presumably this CSB must come after the first request has been submitted
so apparently I am still not getting how it hangs.
Just because igt_reset_nop_engine does things "quickly"? It prevents the
CSB from arriving? So ARB_CHECK pickups up on the fact ELSP has been
rewritten before the IDLE->ACTIVE even received and/or engine reset
prevented it from arriving?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
2021-01-11 17:12 ` Tvrtko Ursulin
@ 2021-01-11 21:54 ` Chris Wilson
2021-01-12 9:21 ` Tvrtko Ursulin
0 siblings, 1 reply; 17+ messages in thread
From: Chris Wilson @ 2021-01-11 21:54 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx
Quoting Tvrtko Ursulin (2021-01-11 17:12:57)
>
> On 11/01/2021 16:27, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2021-01-11 16:19:40)
> >>
> >> On 11/01/2021 10:57, Chris Wilson wrote:
> >>> During igt_reset_nop_engine, it was observed that an unexpected failed
> >>> engine reset lead to us busywaiting on the stop-ring semaphore (set
> >>> during the reset preparations) on the first request afterwards. There was
> >>> no explicit MI_ARB_CHECK in this sequence as the presumption was that
> >>> the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point.
> >>> It did not in this circumstance, so force it.
> >>
> >> In other words MI_SEMAPHORE_POLL is not a preemption point? Can't
> >> remember if I knew that or not..
> >
> > MI_SEMAPHORE_WAIT | POLL is most definitely a preemption point on a
> > miss.
> >
> >> 1)
> >> Why not the same handling in !gen12 version?
> >
> > Because I think it's a bug in tgl [a0 at least]. I think I've seen the
> > same symptoms on tgl before, but not earlier. This is the first time the
> > sequence clicked as to why it was busy spinning. Random engine reset
> > failures are rare enough -- I was meant to also write a test case to
> > inject failure.
>
> Random engine reset failure you think is a TGL issue?
The MI_SEMAPHORE_WAIT | POLL miss not generating an arbitration point.
We have quite a few selftests and IGT that use this feature.
So I was wondering if this was similar to one of those tgl issues with
semaphores and CS events.
The random engine reset failure here is also decidedly odd. The engine
was idle!
> >> 2)
> >> Failed reset leads to busy-hang in following request _tail_? But there
> >> is an arb check at the start of following request as well. Or in cases
> >> where we context switch into the middle of a previously executing request?
> >
> > It was the first request submitted after the failed reset. We expect to
> > clear the ring-stop flag on the CS IDLE->ACTIVE event.
> >
> >> But why would that busy hang? Hasn't the failed request unpaused the ring?
> >
> > The engine was idle at the time of the failed reset. We left the
> > ring-stop set, and submitted the next batch of requests. We hit the
> > MI_SEMAPHORE_WAIT(ring-stop) at the end of the first request, but
> > without hitting an arbitration point (first request, no init-breadcrumb
> > in this case), the semaphore was stuck.
>
> So a kernel context request?
Ish. The selftest is using empty requests, and not emitting the
initial breadcrumb. (So acting like a kernel context.)
> Why hasn't IDLE->ACTIVE cleared ring stop?
There hasn't been an idle->active event, not a single CS event after
writing to ELSP and timing out while still spinning on the semaphore.
> Presumably this CSB must come after the first request has been submitted
> so apparently I am still not getting how it hangs.
It was never sent. The context is still in pending[0] (not active[0])
and there's no sign in the trace of any interrupts/tasklet handing other
than the semaphore-wait interrupt.
> Just because igt_reset_nop_engine does things "quickly"? It prevents the
> CSB from arriving?
More that the since we do very little we hit the semaphore before the CS
has recovered from the shock of being asked to do something.
> So ARB_CHECK pickups up on the fact ELSP has been
> rewritten before the IDLE->ACTIVE even received and/or engine reset
> prevented it from arriving?
The ARB_CHECK should trigger the CS to generate the IDLE->ACTIVE event.
(Of course assuming that the bug is in the semaphore not triggering the
event due to strange circumstances and not a bug in the event generator
itself.) I'm suspicious of the semaphore due to the earlier CS bugs with
lite-restores + semaphores, and am expecting that since the MI_ARB_CHECK
is explicit, it actually works.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting
2021-01-11 21:54 ` Chris Wilson
@ 2021-01-12 9:21 ` Tvrtko Ursulin
0 siblings, 0 replies; 17+ messages in thread
From: Tvrtko Ursulin @ 2021-01-12 9:21 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On 11/01/2021 21:54, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2021-01-11 17:12:57)
>>
>> On 11/01/2021 16:27, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2021-01-11 16:19:40)
>>>>
>>>> On 11/01/2021 10:57, Chris Wilson wrote:
>>>>> During igt_reset_nop_engine, it was observed that an unexpected failed
>>>>> engine reset lead to us busywaiting on the stop-ring semaphore (set
>>>>> during the reset preparations) on the first request afterwards. There was
>>>>> no explicit MI_ARB_CHECK in this sequence as the presumption was that
>>>>> the failed MI_SEMAPHORE_WAIT would itself act as an arbitration point.
>>>>> It did not in this circumstance, so force it.
>>>>
>>>> In other words MI_SEMAPHORE_POLL is not a preemption point? Can't
>>>> remember if I knew that or not..
>>>
>>> MI_SEMAPHORE_WAIT | POLL is most definitely a preemption point on a
>>> miss.
>>>
>>>> 1)
>>>> Why not the same handling in !gen12 version?
>>>
>>> Because I think it's a bug in tgl [a0 at least]. I think I've seen the
>>> same symptoms on tgl before, but not earlier. This is the first time the
>>> sequence clicked as to why it was busy spinning. Random engine reset
>>> failures are rare enough -- I was meant to also write a test case to
>>> inject failure.
>>
>> Random engine reset failure you think is a TGL issue?
>
> The MI_SEMAPHORE_WAIT | POLL miss not generating an arbitration point.
> We have quite a few selftests and IGT that use this feature.
>
> So I was wondering if this was similar to one of those tgl issues with
> semaphores and CS events.
>
> The random engine reset failure here is also decidedly odd. The engine
> was idle!
>
>>>> 2)
>>>> Failed reset leads to busy-hang in following request _tail_? But there
>>>> is an arb check at the start of following request as well. Or in cases
>>>> where we context switch into the middle of a previously executing request?
>>>
>>> It was the first request submitted after the failed reset. We expect to
>>> clear the ring-stop flag on the CS IDLE->ACTIVE event.
>>>
>>>> But why would that busy hang? Hasn't the failed request unpaused the ring?
>>>
>>> The engine was idle at the time of the failed reset. We left the
>>> ring-stop set, and submitted the next batch of requests. We hit the
>>> MI_SEMAPHORE_WAIT(ring-stop) at the end of the first request, but
>>> without hitting an arbitration point (first request, no init-breadcrumb
>>> in this case), the semaphore was stuck.
>>
>> So a kernel context request?
>
> Ish. The selftest is using empty requests, and not emitting the
> initial breadcrumb. (So acting like a kernel context.)
>
>> Why hasn't IDLE->ACTIVE cleared ring stop?
>
> There hasn't been an idle->active event, not a single CS event after
> writing to ELSP and timing out while still spinning on the semaphore.
>
>> Presumably this CSB must come after the first request has been submitted
>> so apparently I am still not getting how it hangs.
>
> It was never sent. The context is still in pending[0] (not active[0])
> and there's no sign in the trace of any interrupts/tasklet handing other
> than the semaphore-wait interrupt.
>
>> Just because igt_reset_nop_engine does things "quickly"? It prevents the
>> CSB from arriving?
>
> More that the since we do very little we hit the semaphore before the CS
> has recovered from the shock of being asked to do something.
>
>> So ARB_CHECK pickups up on the fact ELSP has been
>> rewritten before the IDLE->ACTIVE even received and/or engine reset
>> prevented it from arriving?
>
> The ARB_CHECK should trigger the CS to generate the IDLE->ACTIVE event.
> (Of course assuming that the bug is in the semaphore not triggering the
> event due to strange circumstances and not a bug in the event generator
> itself.) I'm suspicious of the semaphore due to the earlier CS bugs with
> lite-restores + semaphores, and am expecting that since the MI_ARB_CHECK
> is explicit, it actually works.
Okay got it, thanks. I suggest it would be good to slightly improve the
commit message so it is clear what are the suspected TGL quirks. But in
general:
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Intel-gfx] [PATCH 4/4] drm/i915/selftests: Include engine name after reset failure
2021-01-11 10:57 [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Chris Wilson
2021-01-11 10:57 ` [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno Chris Wilson
2021-01-11 10:57 ` [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting Chris Wilson
@ 2021-01-11 10:57 ` Chris Wilson
2021-01-11 16:20 ` Tvrtko Ursulin
2021-01-11 12:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Patchwork
` (2 subsequent siblings)
5 siblings, 1 reply; 17+ messages in thread
From: Chris Wilson @ 2021-01-11 10:57 UTC (permalink / raw)
To: intel-gfx; +Cc: Chris Wilson
During igt_reset_nop_engine, an engine reset unexpectedly failed. For the
next time this happens, mention which engine that was.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 28f71cc2004d..09301e8b92c7 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -506,7 +506,8 @@ static int igt_reset_nop_engine(void *arg)
}
err = intel_engine_reset(engine, NULL);
if (err) {
- pr_err("i915_reset_engine failed\n");
+ pr_err("intel_engine_reset(%s) failed, err:%d\n",
+ engine->name, err);
break;
}
@@ -610,7 +611,8 @@ static int __igt_reset_engine(struct intel_gt *gt, bool active)
err = intel_engine_reset(engine, NULL);
if (err) {
- pr_err("i915_reset_engine failed\n");
+ pr_err("intel_engine_reset(%s) failed, err:%d\n",
+ engine->name, err);
break;
}
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [Intel-gfx] [PATCH 4/4] drm/i915/selftests: Include engine name after reset failure
2021-01-11 10:57 ` [Intel-gfx] [PATCH 4/4] drm/i915/selftests: Include engine name after reset failure Chris Wilson
@ 2021-01-11 16:20 ` Tvrtko Ursulin
0 siblings, 0 replies; 17+ messages in thread
From: Tvrtko Ursulin @ 2021-01-11 16:20 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On 11/01/2021 10:57, Chris Wilson wrote:
> During igt_reset_nop_engine, an engine reset unexpectedly failed. For the
> next time this happens, mention which engine that was.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> index 28f71cc2004d..09301e8b92c7 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> @@ -506,7 +506,8 @@ static int igt_reset_nop_engine(void *arg)
> }
> err = intel_engine_reset(engine, NULL);
> if (err) {
> - pr_err("i915_reset_engine failed\n");
> + pr_err("intel_engine_reset(%s) failed, err:%d\n",
> + engine->name, err);
> break;
> }
>
> @@ -610,7 +611,8 @@ static int __igt_reset_engine(struct intel_gt *gt, bool active)
>
> err = intel_engine_reset(engine, NULL);
> if (err) {
> - pr_err("i915_reset_engine failed\n");
> + pr_err("intel_engine_reset(%s) failed, err:%d\n",
> + engine->name, err);
> break;
> }
>
>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates
2021-01-11 10:57 [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Chris Wilson
` (2 preceding siblings ...)
2021-01-11 10:57 ` [Intel-gfx] [PATCH 4/4] drm/i915/selftests: Include engine name after reset failure Chris Wilson
@ 2021-01-11 12:30 ` Patchwork
2021-01-11 14:19 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-01-11 15:53 ` [Intel-gfx] [PATCH 1/4] " Tvrtko Ursulin
5 siblings, 0 replies; 17+ messages in thread
From: Patchwork @ 2021-01-11 12:30 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 3293 bytes --]
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates
URL : https://patchwork.freedesktop.org/series/85698/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9577 -> Patchwork_19313
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/index.html
Known issues
------------
Here are the changes found in Patchwork_19313 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_basic@semaphore:
- fi-bsw-nick: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/fi-bsw-nick/igt@amdgpu/amd_basic@semaphore.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [PASS][2] -> [INCOMPLETE][3] ([i915#142] / [i915#2405])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/fi-byt-j1900/igt@i915_pm_rpm@module-reload.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/fi-byt-j1900/igt@i915_pm_rpm@module-reload.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][4] ([i915#2029])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/fi-bdw-5557u/igt@runner@aborted.html
- fi-byt-j1900: NOTRUN -> [FAIL][5] ([i915#1814] / [i915#2505])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/fi-byt-j1900/igt@runner@aborted.html
#### Possible fixes ####
* igt@i915_selftest@live@execlists:
- fi-bsw-nick: [INCOMPLETE][6] -> [PASS][7]
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/fi-bsw-nick/igt@i915_selftest@live@execlists.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/fi-bsw-nick/igt@i915_selftest@live@execlists.html
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
[i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
[i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
Participating hosts (43 -> 37)
------------------------------
Missing (6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-tgl-y fi-bdw-samus
Build changes
-------------
* Linux: CI_DRM_9577 -> Patchwork_19313
CI-20190529: 20190529
CI_DRM_9577: 27f91f8b83589837494f100212ad62a124633ff7 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5953: 65c5eea699141e6f942ce0a8fc85db76ce53cd19 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19313: ee733a2e21daf6d7c93954cf24da986f557b84ce @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ee733a2e21da drm/i915/selftests: Include engine name after reset failure
46bca7571d57 drm/i915/gt: Perform an arbitration check before busywaiting
63a7d61fbfea drm/i915/gt: Check for arbitration after writing start seqno
7905e92b2a33 drm/i915/gt: Disable arbitration around Braswell's pdp updates
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/index.html
[-- Attachment #1.2: Type: text/html, Size: 4017 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates
2021-01-11 10:57 [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Chris Wilson
` (3 preceding siblings ...)
2021-01-11 12:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Patchwork
@ 2021-01-11 14:19 ` Patchwork
2021-01-11 15:53 ` [Intel-gfx] [PATCH 1/4] " Tvrtko Ursulin
5 siblings, 0 replies; 17+ messages in thread
From: Patchwork @ 2021-01-11 14:19 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 23516 bytes --]
== Series Details ==
Series: series starting with [1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates
URL : https://patchwork.freedesktop.org/series/85698/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9577_full -> Patchwork_19313_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_19313_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19313_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_19313_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_ctx_persistence@close-replace-race:
- shard-kbl: [PASS][1] -> [TIMEOUT][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-kbl3/igt@gem_ctx_persistence@close-replace-race.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-kbl4/igt@gem_ctx_persistence@close-replace-race.html
#### Warnings ####
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-kbl: [INCOMPLETE][3] ([i915#155]) -> [INCOMPLETE][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-kbl4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-kbl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_spin_batch@engines@vecs0}:
- shard-apl: [PASS][5] -> [FAIL][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-apl4/igt@gem_spin_batch@engines@vecs0.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-apl3/igt@gem_spin_batch@engines@vecs0.html
Known issues
------------
Here are the changes found in Patchwork_19313_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_persistence@close-replace-race:
- shard-glk: [PASS][7] -> [TIMEOUT][8] ([i915#2918])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-glk1/igt@gem_ctx_persistence@close-replace-race.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-glk2/igt@gem_ctx_persistence@close-replace-race.html
* igt@gem_ctx_persistence@engines-mixed:
- shard-hsw: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1099]) +1 similar issue
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-hsw2/igt@gem_ctx_persistence@engines-mixed.html
* igt@gem_ctx_persistence@replace-hostile:
- shard-hsw: NOTRUN -> [SKIP][10] ([fdo#109271]) +224 similar issues
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-hsw6/igt@gem_ctx_persistence@replace-hostile.html
* igt@gem_ctx_sseu@engines:
- shard-tglb: NOTRUN -> [SKIP][11] ([i915#280])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb6/igt@gem_ctx_sseu@engines.html
* igt@gem_exec_reloc@basic-many-active@vcs0:
- shard-hsw: NOTRUN -> [FAIL][12] ([i915#2389]) +3 similar issues
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-hsw2/igt@gem_exec_reloc@basic-many-active@vcs0.html
* igt@gem_exec_reloc@basic-many-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][13] ([i915#2389])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-iclb4/igt@gem_exec_reloc@basic-many-active@vcs1.html
* igt@gem_exec_whisper@basic-fds-forked-all:
- shard-glk: [PASS][14] -> [DMESG-WARN][15] ([i915#118] / [i915#95])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-glk7/igt@gem_exec_whisper@basic-fds-forked-all.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-glk2/igt@gem_exec_whisper@basic-fds-forked-all.html
* igt@gem_pwrite@basic-exhaustion:
- shard-hsw: NOTRUN -> [WARN][16] ([i915#2658])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-hsw2/igt@gem_pwrite@basic-exhaustion.html
* igt@gem_userptr_blits@readonly-pwrite-unsync:
- shard-tglb: NOTRUN -> [SKIP][17] ([fdo#110426] / [i915#1704])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb6/igt@gem_userptr_blits@readonly-pwrite-unsync.html
* igt@gen3_render_linear_blits:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109289])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb6/igt@gen3_render_linear_blits.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1436] / [i915#716])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl6/igt@gen9_exec_parse@allowed-single.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl3/igt@gen9_exec_parse@allowed-single.html
* igt@kms_atomic_interruptible@legacy-pageflip:
- shard-snb: NOTRUN -> [SKIP][21] ([fdo#109271])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-snb6/igt@kms_atomic_interruptible@legacy-pageflip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- shard-hsw: NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111827]) +15 similar issues
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-hsw2/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_color_chamelium@pipe-a-gamma:
- shard-tglb: NOTRUN -> [SKIP][23] ([fdo#109284] / [fdo#111827])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb6/igt@kms_color_chamelium@pipe-a-gamma.html
* igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen:
- shard-skl: [PASS][24] -> [FAIL][25] ([i915#54]) +9 similar issues
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl1/igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl10/igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic:
- shard-tglb: NOTRUN -> [FAIL][26] ([i915#2346])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb6/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html
* igt@kms_flip@flip-vs-absolute-wf_vblank@a-edp1:
- shard-tglb: NOTRUN -> [FAIL][27] ([i915#2122])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb6/igt@kms_flip@flip-vs-absolute-wf_vblank@a-edp1.html
* igt@kms_flip@flip-vs-suspend@b-edp1:
- shard-skl: [PASS][28] -> [INCOMPLETE][29] ([i915#198])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl9/igt@kms_flip@flip-vs-suspend@b-edp1.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl7/igt@kms_flip@flip-vs-suspend@b-edp1.html
* igt@kms_flip@plain-flip-ts-check@b-edp1:
- shard-skl: [PASS][30] -> [FAIL][31] ([i915#2122]) +1 similar issue
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl4/igt@kms_flip@plain-flip-ts-check@b-edp1.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl3/igt@kms_flip@plain-flip-ts-check@b-edp1.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite:
- shard-snb: [PASS][32] -> [SKIP][33] ([fdo#109271])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-snb2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-snb6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-pwrite:
- shard-tglb: NOTRUN -> [SKIP][34] ([fdo#111825]) +6 similar issues
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb6/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-pwrite.html
* igt@kms_plane_alpha_blend@pipe-d-alpha-transparent-fb:
- shard-skl: NOTRUN -> [SKIP][35] ([fdo#109271]) +1 similar issue
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl1/igt@kms_plane_alpha_blend@pipe-d-alpha-transparent-fb.html
* igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-iclb: [PASS][36] -> [DMESG-WARN][37] ([i915#1226])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-iclb6/igt@kms_plane_lowres@pipe-a-tiling-x.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-x.html
* igt@kms_psr@psr2_sprite_blt:
- shard-iclb: [PASS][38] -> [SKIP][39] ([fdo#109441]) +1 similar issue
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-iclb6/igt@kms_psr@psr2_sprite_blt.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [PASS][40] -> [DMESG-WARN][41] ([i915#180] / [i915#295])
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-kbl4/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-kbl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@sysfs_preempt_timeout@timeout@vecs0:
- shard-skl: [PASS][42] -> [FAIL][43] ([i915#2821])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl8/igt@sysfs_preempt_timeout@timeout@vecs0.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl4/igt@sysfs_preempt_timeout@timeout@vecs0.html
#### Possible fixes ####
* igt@drm_mm@all@color_evict:
- shard-skl: [INCOMPLETE][44] ([i915#2485]) -> [PASS][45]
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl2/igt@drm_mm@all@color_evict.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl1/igt@drm_mm@all@color_evict.html
* {igt@gem_exec_fair@basic-flow@rcs0}:
- shard-tglb: [FAIL][46] ([i915#2842]) -> [PASS][47]
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-tglb2/igt@gem_exec_fair@basic-flow@rcs0.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb1/igt@gem_exec_fair@basic-flow@rcs0.html
* {igt@gem_exec_fair@basic-none-solo@rcs0}:
- shard-glk: [FAIL][48] ([i915#2842]) -> [PASS][49] +1 similar issue
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-glk1/igt@gem_exec_fair@basic-none-solo@rcs0.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-glk5/igt@gem_exec_fair@basic-none-solo@rcs0.html
* {igt@gem_exec_fair@basic-none@vecs0}:
- shard-kbl: [FAIL][50] ([i915#2842]) -> [PASS][51]
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-kbl4/igt@gem_exec_fair@basic-none@vecs0.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-kbl3/igt@gem_exec_fair@basic-none@vecs0.html
- shard-apl: [FAIL][52] ([i915#2842]) -> [PASS][53]
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-apl6/igt@gem_exec_fair@basic-none@vecs0.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-apl4/igt@gem_exec_fair@basic-none@vecs0.html
* {igt@gem_exec_schedule@u-fairslice@rcs0}:
- shard-tglb: [DMESG-WARN][54] ([i915#2803]) -> [PASS][55]
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-tglb5/igt@gem_exec_schedule@u-fairslice@rcs0.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb6/igt@gem_exec_schedule@u-fairslice@rcs0.html
* igt@i915_module_load@reload-with-fault-injection:
- shard-hsw: [INCOMPLETE][56] ([i915#2880]) -> [PASS][57]
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-hsw4/igt@i915_module_load@reload-with-fault-injection.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-hsw8/igt@i915_module_load@reload-with-fault-injection.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [FAIL][58] ([i915#454]) -> [PASS][59]
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-iclb4/igt@i915_pm_dc@dc6-psr.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-iclb8/igt@i915_pm_dc@dc6-psr.html
* igt@kms_cursor_crc@pipe-b-cursor-128x128-random:
- shard-skl: [FAIL][60] ([i915#54]) -> [PASS][61] +5 similar issues
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl5/igt@kms_cursor_crc@pipe-b-cursor-128x128-random.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl9/igt@kms_cursor_crc@pipe-b-cursor-128x128-random.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [FAIL][62] ([i915#96]) -> [PASS][63]
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-hsw6/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-hsw8/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-tglb: [FAIL][64] ([i915#2598]) -> [PASS][65]
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-tglb6/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb3/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_flip@flip-vs-expired-vblank@b-dp1:
- shard-apl: [FAIL][66] ([i915#79]) -> [PASS][67]
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-apl2/igt@kms_flip@flip-vs-expired-vblank@b-dp1.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-apl7/igt@kms_flip@flip-vs-expired-vblank@b-dp1.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [FAIL][68] ([i915#1188]) -> [PASS][69]
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl6/igt@kms_hdr@bpc-switch.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl1/igt@kms_hdr@bpc-switch.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [FAIL][70] ([fdo#108145] / [i915#265]) -> [PASS][71]
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl1/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl3/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_plane_lowres@pipe-c-tiling-none:
- shard-kbl: [DMESG-WARN][72] ([i915#165] / [i915#180] / [i915#78]) -> [PASS][73]
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-kbl2/igt@kms_plane_lowres@pipe-c-tiling-none.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-kbl6/igt@kms_plane_lowres@pipe-c-tiling-none.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [SKIP][74] ([fdo#109441]) -> [PASS][75] +1 similar issue
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-iclb7/igt@kms_psr@psr2_primary_mmap_cpu.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@sysfs_heartbeat_interval@mixed@bcs0:
- shard-skl: [FAIL][76] ([i915#1731]) -> [PASS][77]
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl8/igt@sysfs_heartbeat_interval@mixed@bcs0.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl2/igt@sysfs_heartbeat_interval@mixed@bcs0.html
#### Warnings ####
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: [WARN][78] ([i915#2684]) -> [WARN][79] ([i915#1804] / [i915#2684])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-iclb5/igt@i915_pm_rc6_residency@rc6-fence.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-iclb4/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-iclb: [WARN][80] ([i915#2681] / [i915#2684]) -> [WARN][81] ([i915#1804] / [i915#2684])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-iclb8/igt@i915_pm_rc6_residency@rc6-idle.html
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-iclb6/igt@i915_pm_rc6_residency@rc6-idle.html
* igt@runner@aborted:
- shard-hsw: ([FAIL][82], [FAIL][83]) ([i915#142] / [i915#2292] / [i915#2295] / [i915#2505]) -> [FAIL][84] ([i915#2295] / [i915#2505])
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-hsw4/igt@runner@aborted.html
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-hsw4/igt@runner@aborted.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-hsw4/igt@runner@aborted.html
- shard-kbl: [FAIL][85] ([i915#2295]) -> ([FAIL][86], [FAIL][87]) ([i915#1814] / [i915#2295] / [i915#602])
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-kbl1/igt@runner@aborted.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-kbl3/igt@runner@aborted.html
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-kbl7/igt@runner@aborted.html
- shard-tglb: ([FAIL][88], [FAIL][89], [FAIL][90]) ([i915#1814] / [i915#2295] / [i915#2426] / [i915#2667] / [i915#2803]) -> ([FAIL][91], [FAIL][92]) ([i915#1814] / [i915#2295] / [i915#2667])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-tglb5/igt@runner@aborted.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-tglb1/igt@runner@aborted.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-tglb1/igt@runner@aborted.html
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb5/igt@runner@aborted.html
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-tglb7/igt@runner@aborted.html
- shard-skl: ([FAIL][93], [FAIL][94]) ([i915#2295] / [i915#2426]) -> ([FAIL][95], [FAIL][96], [FAIL][97]) ([i915#1436] / [i915#2295] / [i915#2426])
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl8/igt@runner@aborted.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9577/shard-skl2/igt@runner@aborted.html
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl3/igt@runner@aborted.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl1/igt@runner@aborted.html
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/shard-skl8/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#110426]: https://bugs.freedesktop.org/show_bug.cgi?id=110426
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1099]: https://gitlab.freedesktop.org/drm/intel/issues/1099
[i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
[i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#1704]: https://gitlab.freedesktop.org/drm/intel/issues/1704
[i915#1731]: https://gitlab.freedesktop.org/drm/intel/issues/1731
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1804]: https://gitlab.freedesktop.org/drm/intel/issues/1804
[i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814
[i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2292]: https://gitlab.freedesktop.org/drm/intel/issues/2292
[i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2389]: https://gitlab.freedesktop.org/drm/intel/issues/2389
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2485]: https://gitlab.freedesktop.org/drm/intel/issues/2485
[i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505
[i915#2598]: https://gitlab.freedesktop.org/drm/intel/issues/2598
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
[i915#2667]: https://gitlab.freedesktop.org/drm/intel/issues/2667
[i915#2681]: https://gitlab.freedesktop.org/drm/intel/issues/2681
[i915#2684]: https://gitlab.freedesktop.org/drm/intel/issues/2684
[i915#280]: https://gitlab.freedesktop.org/drm/intel/issues/280
[i915#2803]: https://gitlab.freedesktop.org/drm/intel/issues/2803
[i915#2821]: https://gitlab.freedesktop.org/drm/intel/issues/2821
[i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
[i915#2849]: https://gitlab.freedesktop.org/drm/intel/issues/2849
[i915#2880]: https://gitlab.freedesktop.org/drm/intel/issues/2880
[i915#2918]: https://gitlab.freedesktop.org/drm/intel/issues/2918
[i915#2920]: https://gitlab.freedesktop.org/drm/intel/issues/2920
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#602]: https://gitlab.freedesktop.org/drm/intel/issues/602
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#716]: https://gitlab.freedesktop.org/drm/intel/issues/716
[i915#78]: https://gitlab.freedesktop.org/drm/intel/issues/78
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
[i915#96]: https://gitlab.freedesktop.org/drm/intel/issues/96
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* Linux: CI_DRM_9577 -> Patchwork_19313
CI-20190529: 20190529
CI_DRM_9577: 27f91f8b83589837494f100212ad62a124633ff7 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5953: 65c5eea699141e6f942ce0a8fc85db76ce53cd19 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19313: ee733a2e21daf6d7c93954cf24da986f557b84ce @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19313/index.html
[-- Attachment #1.2: Type: text/html, Size: 27719 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates
2021-01-11 10:57 [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates Chris Wilson
` (4 preceding siblings ...)
2021-01-11 14:19 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2021-01-11 15:53 ` Tvrtko Ursulin
2021-01-11 16:00 ` Chris Wilson
5 siblings, 1 reply; 17+ messages in thread
From: Tvrtko Ursulin @ 2021-01-11 15:53 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On 11/01/2021 10:57, Chris Wilson wrote:
> Braswell's pdp workaround is full of dragons, that may be being angered
> when they are interrupted. Let's not take that risk and disable
> arbitrartion during the update.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 52c1fe62bdfe..10e9940cf3f5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -2539,6 +2539,14 @@ static int emit_pdps(struct i915_request *rq)
> * GPU hangs to forcewake errors and machine lockups!
> */
>
> + cs = intel_ring_begin(rq, 2);
> + if (IS_ERR(cs))
> + return PTR_ERR(cs);
> +
> + *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
> + *cs++ = MI_NOOP;
> + intel_ring_advance(rq, cs);
> +
> /* Flush any residual operations from the context load */
> err = engine->emit_flush(rq, EMIT_FLUSH);
> if (err)
> @@ -2564,7 +2572,8 @@ static int emit_pdps(struct i915_request *rq)
> *cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_LDW(base, i));
> *cs++ = lower_32_bits(pd_daddr);
> }
> - *cs++ = MI_NOOP;
> + *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> + intel_ring_advance(rq, cs);
>
> intel_ring_advance(rq, cs);
>
>
I had to remind myself that Gen8LP is indeed the only platform with
32-bit ppgtt.
I presume you are fixing some sporadic CI failures here, anyway:
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates
2021-01-11 15:53 ` [Intel-gfx] [PATCH 1/4] " Tvrtko Ursulin
@ 2021-01-11 16:00 ` Chris Wilson
0 siblings, 0 replies; 17+ messages in thread
From: Chris Wilson @ 2021-01-11 16:00 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx
Quoting Tvrtko Ursulin (2021-01-11 15:53:47)
>
> On 11/01/2021 10:57, Chris Wilson wrote:
> > Braswell's pdp workaround is full of dragons, that may be being angered
> > when they are interrupted. Let's not take that risk and disable
> > arbitrartion during the update.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> > drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 11 ++++++++++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 52c1fe62bdfe..10e9940cf3f5 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -2539,6 +2539,14 @@ static int emit_pdps(struct i915_request *rq)
> > * GPU hangs to forcewake errors and machine lockups!
> > */
> >
> > + cs = intel_ring_begin(rq, 2);
> > + if (IS_ERR(cs))
> > + return PTR_ERR(cs);
> > +
> > + *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
> > + *cs++ = MI_NOOP;
> > + intel_ring_advance(rq, cs);
> > +
> > /* Flush any residual operations from the context load */
> > err = engine->emit_flush(rq, EMIT_FLUSH);
> > if (err)
> > @@ -2564,7 +2572,8 @@ static int emit_pdps(struct i915_request *rq)
> > *cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_LDW(base, i));
> > *cs++ = lower_32_bits(pd_daddr);
> > }
> > - *cs++ = MI_NOOP;
> > + *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
> > + intel_ring_advance(rq, cs);
> >
> > intel_ring_advance(rq, cs);
> >
> >
>
> I had to remind myself that Gen8LP is indeed the only platform with
> 32-bit ppgtt.
>
> I presume you are fixing some sporadic CI failures here, anyway:
There's an odd one showing up in Braswell CI, but didn't occur locally
in several hours of running the selftest. Given the history of how
sensitive Braswell is to these PDP updates, I think this wild stab in
the dark is likely to hit something.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 17+ messages in thread