* Re: [PATCH] drm/i915: Only arm the forcewake release timer on the final put
2016-03-24 13:32 [PATCH] drm/i915: Only arm the forcewake release timer on the final put Chris Wilson
@ 2016-03-24 13:42 ` Chris Wilson
2016-03-24 13:54 ` Tvrtko Ursulin
2016-03-24 14:33 ` Dave Gordon
2016-03-24 13:56 ` [PATCH v2] " Chris Wilson
` (2 subsequent siblings)
3 siblings, 2 replies; 11+ messages in thread
From: Chris Wilson @ 2016-03-24 13:42 UTC (permalink / raw)
To: intel-gfx
On Thu, Mar 24, 2016 at 01:32:53PM +0000, Chris Wilson wrote:
> If we arm the release timer on acquiring the forcewake, we will release
> the forcewake on the jiffie afterwards. If we only arm the release timer
> on the final put, we will release the forcewake slightly later instead.
>
> Much, much worse, we did not acquire a refcount for the armed timing
> during the get(), and so unbalanced our forcewake counting.
>
> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index 96799392c2c7..d857168c6c9b 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
> static inline void
> fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
> {
> + d->wake_count++;
> mod_timer_pinned(&d->timer, jiffies + 1);
Which raise the obvious issue that we double increment the counter if
the timer was pending (where we would only then release it once).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] drm/i915: Only arm the forcewake release timer on the final put
2016-03-24 13:42 ` Chris Wilson
@ 2016-03-24 13:54 ` Tvrtko Ursulin
2016-03-24 14:19 ` Chris Wilson
2016-03-24 14:33 ` Dave Gordon
1 sibling, 1 reply; 11+ messages in thread
From: Tvrtko Ursulin @ 2016-03-24 13:54 UTC (permalink / raw)
To: Chris Wilson, intel-gfx, Mika Kuoppala
On 24/03/16 13:42, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 01:32:53PM +0000, Chris Wilson wrote:
>> If we arm the release timer on acquiring the forcewake, we will release
>> the forcewake on the jiffie afterwards. If we only arm the release timer
>> on the final put, we will release the forcewake slightly later instead.
>>
>> Much, much worse, we did not acquire a refcount for the armed timing
>> during the get(), and so unbalanced our forcewake counting.
>>
>> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_uncore.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
>> index 96799392c2c7..d857168c6c9b 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
>> static inline void
>> fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
>> {
>> + d->wake_count++;
>> mod_timer_pinned(&d->timer, jiffies + 1);
>
> Which raise the obvious issue that we double increment the counter if
> the timer was pending (where we would only then release it once).
I don't see the bug, we got:
1) __intel_uncore_forcewake_put - if refcount reaches zero it will bump
it and arm the timer to decrement and release. This is used from
explicit get/put paths.
2) __force_wake_get - used from register reads only, so no explicit put
will happen. It just bumps the ref count and arms the timer.
I can't spot the bug, if there is one.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] drm/i915: Only arm the forcewake release timer on the final put
2016-03-24 13:54 ` Tvrtko Ursulin
@ 2016-03-24 14:19 ` Chris Wilson
2016-03-24 14:30 ` Chris Wilson
0 siblings, 1 reply; 11+ messages in thread
From: Chris Wilson @ 2016-03-24 14:19 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx
On Thu, Mar 24, 2016 at 01:54:36PM +0000, Tvrtko Ursulin wrote:
>
> On 24/03/16 13:42, Chris Wilson wrote:
> >On Thu, Mar 24, 2016 at 01:32:53PM +0000, Chris Wilson wrote:
> >>If we arm the release timer on acquiring the forcewake, we will release
> >>the forcewake on the jiffie afterwards. If we only arm the release timer
> >>on the final put, we will release the forcewake slightly later instead.
> >>
> >>Much, much worse, we did not acquire a refcount for the armed timing
> >>during the get(), and so unbalanced our forcewake counting.
> >>
> >>Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >>Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> >>Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >>---
> >> drivers/gpu/drm/i915/intel_uncore.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> >>index 96799392c2c7..d857168c6c9b 100644
> >>--- a/drivers/gpu/drm/i915/intel_uncore.c
> >>+++ b/drivers/gpu/drm/i915/intel_uncore.c
> >>@@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
> >> static inline void
> >> fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
> >> {
> >>+ d->wake_count++;
> >> mod_timer_pinned(&d->timer, jiffies + 1);
> >
> >Which raise the obvious issue that we double increment the counter if
> >the timer was pending (where we would only then release it once).
>
> I don't see the bug, we got:
>
> 1) __intel_uncore_forcewake_put - if refcount reaches zero it will
> bump it and arm the timer to decrement and release. This is used
> from explicit get/put paths.
>
> 2) __force_wake_get - used from register reads only, so no explicit
> put will happen. It just bumps the ref count and arms the timer.
>
> I can't spot the bug, if there is one.
I mistook __force_wake_get for __intel_uncore_forcewake_get and jumped.
Having said that we do still have the issue of double-increment if the
timer is already armed. Or do we? I'm pretty sure we do.
So __force_wake_get_autorelease(), __force_wake_auto() ?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] drm/i915: Only arm the forcewake release timer on the final put
2016-03-24 14:19 ` Chris Wilson
@ 2016-03-24 14:30 ` Chris Wilson
0 siblings, 0 replies; 11+ messages in thread
From: Chris Wilson @ 2016-03-24 14:30 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx, Mika Kuoppala
On Thu, Mar 24, 2016 at 02:19:38PM +0000, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 01:54:36PM +0000, Tvrtko Ursulin wrote:
> >
> > On 24/03/16 13:42, Chris Wilson wrote:
> > >On Thu, Mar 24, 2016 at 01:32:53PM +0000, Chris Wilson wrote:
> > >>If we arm the release timer on acquiring the forcewake, we will release
> > >>the forcewake on the jiffie afterwards. If we only arm the release timer
> > >>on the final put, we will release the forcewake slightly later instead.
> > >>
> > >>Much, much worse, we did not acquire a refcount for the armed timing
> > >>during the get(), and so unbalanced our forcewake counting.
> > >>
> > >>Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > >>Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > >>Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> > >>Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > >>---
> > >> drivers/gpu/drm/i915/intel_uncore.c | 3 +--
> > >> 1 file changed, 1 insertion(+), 2 deletions(-)
> > >>
> > >>diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> > >>index 96799392c2c7..d857168c6c9b 100644
> > >>--- a/drivers/gpu/drm/i915/intel_uncore.c
> > >>+++ b/drivers/gpu/drm/i915/intel_uncore.c
> > >>@@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
> > >> static inline void
> > >> fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
> > >> {
> > >>+ d->wake_count++;
> > >> mod_timer_pinned(&d->timer, jiffies + 1);
> > >
> > >Which raise the obvious issue that we double increment the counter if
> > >the timer was pending (where we would only then release it once).
> >
> > I don't see the bug, we got:
> >
> > 1) __intel_uncore_forcewake_put - if refcount reaches zero it will
> > bump it and arm the timer to decrement and release. This is used
> > from explicit get/put paths.
> >
> > 2) __force_wake_get - used from register reads only, so no explicit
> > put will happen. It just bumps the ref count and arms the timer.
> >
> > I can't spot the bug, if there is one.
>
> I mistook __force_wake_get for __intel_uncore_forcewake_get and jumped.
>
> Having said that we do still have the issue of double-increment if the
> timer is already armed. Or do we? I'm pretty sure we do.
I'll answer that. That is also no, because of the spinlock guarding it.
Oh well, I really thought I had an explanation there.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] drm/i915: Only arm the forcewake release timer on the final put
2016-03-24 13:42 ` Chris Wilson
2016-03-24 13:54 ` Tvrtko Ursulin
@ 2016-03-24 14:33 ` Dave Gordon
2016-03-24 14:55 ` Chris Wilson
1 sibling, 1 reply; 11+ messages in thread
From: Dave Gordon @ 2016-03-24 14:33 UTC (permalink / raw)
To: intel-gfx
On 24/03/16 13:42, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 01:32:53PM +0000, Chris Wilson wrote:
>> If we arm the release timer on acquiring the forcewake, we will release
>> the forcewake on the jiffie afterwards. If we only arm the release timer
>> on the final put, we will release the forcewake slightly later instead.
>>
>> Much, much worse, we did not acquire a refcount for the armed timing
>> during the get(), and so unbalanced our forcewake counting.
>>
>> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_uncore.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
>> index 96799392c2c7..d857168c6c9b 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
>> static inline void
>> fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
>> {
>> + d->wake_count++;
>> mod_timer_pinned(&d->timer, jiffies + 1);
>
> Which raise the obvious issue that we double increment the counter if
> the timer was pending (where we would only then release it once).
> -Chris
'jiffies + 1' might be only a nanosecond away; would it be better to use
'jiffies + 2'? OTOH that might be quite a long time and therefore
increase power consumption :( So is there a somewhat higher-resolution
cyclic timer that we could use?
Also, why mod_timer_pinned() ? I'd think that if this actually happens a
whole jiffie later, there'd be little correlation between the current
CPU activity and what's happening when the timer fires, so no real point
in pinning the timer to current CPU.
Using mod_timer() instead would allow it to apply slack and align the
callback to other timer activity, maybe reducing CPU overhead at the
possible cost of a slight increase in GPU power.
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH] drm/i915: Only arm the forcewake release timer on the final put
2016-03-24 14:33 ` Dave Gordon
@ 2016-03-24 14:55 ` Chris Wilson
0 siblings, 0 replies; 11+ messages in thread
From: Chris Wilson @ 2016-03-24 14:55 UTC (permalink / raw)
To: Dave Gordon; +Cc: intel-gfx
On Thu, Mar 24, 2016 at 02:33:32PM +0000, Dave Gordon wrote:
> On 24/03/16 13:42, Chris Wilson wrote:
> >On Thu, Mar 24, 2016 at 01:32:53PM +0000, Chris Wilson wrote:
> >>If we arm the release timer on acquiring the forcewake, we will release
> >>the forcewake on the jiffie afterwards. If we only arm the release timer
> >>on the final put, we will release the forcewake slightly later instead.
> >>
> >>Much, much worse, we did not acquire a refcount for the armed timing
> >>during the get(), and so unbalanced our forcewake counting.
> >>
> >>Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >>Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> >>Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >>---
> >> drivers/gpu/drm/i915/intel_uncore.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> >>index 96799392c2c7..d857168c6c9b 100644
> >>--- a/drivers/gpu/drm/i915/intel_uncore.c
> >>+++ b/drivers/gpu/drm/i915/intel_uncore.c
> >>@@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
> >> static inline void
> >> fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
> >> {
> >>+ d->wake_count++;
> >> mod_timer_pinned(&d->timer, jiffies + 1);
> >
> >Which raise the obvious issue that we double increment the counter if
> >the timer was pending (where we would only then release it once).
> >-Chris
>
> 'jiffies + 1' might be only a nanosecond away; would it be better to
> use 'jiffies + 2'? OTOH that might be quite a long time and
> therefore increase power consumption :( So is there a somewhat
> higher-resolution cyclic timer that we could use?
Right, we could switch to using hrtimers. Or msecs_to_jiffies(). jiffies
+ 1 was a number plucked out of the air. I believe Mika did some
experimentation but never arrived at a conclusion for a better value.
An adaptive algo might look at the running average time between
forcewakes and set the timer for some relative value. That might be an
interesting approach.
> Also, why mod_timer_pinned() ? I'd think that if this actually
> happens a whole jiffie later, there'd be little correlation between
> the current CPU activity and what's happening when the timer fires,
> so no real point in pinning the timer to current CPU.
The idea behind using timer_pinned was to try and keep the activity on
the same cpu, in the vain hope that the timer actually expires
relatively quickly before the CPU went to sleep again.
> Using mod_timer() instead would allow it to apply slack and align
> the callback to other timer activity, maybe reducing CPU overhead at
> the possible cost of a slight increase in GPU power.
We trade off CPU power vs GPU power, and I know how power hungry our GPU
is even at idle frequencies. And we should have system tests that detect
if we hold off rc6 for too long (or rather if we never hit rc6 :().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2] drm/i915: Only arm the forcewake release timer on the final put
2016-03-24 13:32 [PATCH] drm/i915: Only arm the forcewake release timer on the final put Chris Wilson
2016-03-24 13:42 ` Chris Wilson
@ 2016-03-24 13:56 ` Chris Wilson
2016-03-24 14:38 ` [PATCH] " Dave Gordon
2016-03-24 15:03 ` ✗ Fi.CI.BAT: failure for drm/i915: Only arm the forcewake release timer on the final put (rev2) Patchwork
3 siblings, 0 replies; 11+ messages in thread
From: Chris Wilson @ 2016-03-24 13:56 UTC (permalink / raw)
To: intel-gfx
If we arm the release timer on acquiring the forcewake, we will release
the forcewake on the jiffie afterwards. If we only arm the release timer
on the final put, we will release the forcewake slightly later instead.
Much, much worse, we did not acquire a refcount for the armed timing
during the get(), and so unbalanced our forcewake counting.
v2: Only claim the timer refcount if we start the timer.
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
---
drivers/gpu/drm/i915/intel_uncore.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
index 96799392c2c7..b7b373900cb4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,7 +60,8 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
static inline void
fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
{
- mod_timer_pinned(&d->timer, jiffies + 1);
+ if (!mod_timer_pinned(&d->timer, jiffies + 1))
+ d->wake_count++;
}
static inline void
@@ -491,7 +492,6 @@ static void __intel_uncore_forcewake_put(struct drm_i915_private *dev_priv,
if (--domain->wake_count)
continue;
- domain->wake_count++;
fw_domain_arm_timer(domain);
}
}
@@ -733,7 +733,6 @@ static inline void __force_wake_get(struct drm_i915_private *dev_priv,
}
domain->wake_count++;
- fw_domain_arm_timer(domain);
}
if (fw_domains)
--
2.8.0.rc3
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH] drm/i915: Only arm the forcewake release timer on the final put
2016-03-24 13:32 [PATCH] drm/i915: Only arm the forcewake release timer on the final put Chris Wilson
2016-03-24 13:42 ` Chris Wilson
2016-03-24 13:56 ` [PATCH v2] " Chris Wilson
@ 2016-03-24 14:38 ` Dave Gordon
2016-03-24 15:03 ` ✗ Fi.CI.BAT: failure for drm/i915: Only arm the forcewake release timer on the final put (rev2) Patchwork
3 siblings, 0 replies; 11+ messages in thread
From: Dave Gordon @ 2016-03-24 14:38 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
On 24/03/16 13:32, Chris Wilson wrote:
> If we arm the release timer on acquiring the forcewake, we will release
> the forcewake on the jiffie afterwards. If we only arm the release timer
> on the final put, we will release the forcewake slightly later instead.
Yes, I had wondered why we armed to timer on forcewake_get(). So
definitely agree it should be on last put().
> Much, much worse, we did not acquire a refcount for the armed timing
> during the get(), and so unbalanced our forcewake counting.
Hmm ... refcount /looks/ OK to me? But I'd need to check more ...
.Dave.
> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index 96799392c2c7..d857168c6c9b 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
> static inline void
> fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
> {
> + d->wake_count++;
> mod_timer_pinned(&d->timer, jiffies + 1);
> }
>
> @@ -491,7 +492,6 @@ static void __intel_uncore_forcewake_put(struct drm_i915_private *dev_priv,
> if (--domain->wake_count)
> continue;
>
> - domain->wake_count++;
> fw_domain_arm_timer(domain);
> }
> }
> @@ -733,7 +733,6 @@ static inline void __force_wake_get(struct drm_i915_private *dev_priv,
> }
>
> domain->wake_count++;
> - fw_domain_arm_timer(domain);
> }
>
> if (fw_domains)
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread* ✗ Fi.CI.BAT: failure for drm/i915: Only arm the forcewake release timer on the final put (rev2)
2016-03-24 13:32 [PATCH] drm/i915: Only arm the forcewake release timer on the final put Chris Wilson
` (2 preceding siblings ...)
2016-03-24 14:38 ` [PATCH] " Dave Gordon
@ 2016-03-24 15:03 ` Patchwork
2016-03-24 15:51 ` Chris Wilson
3 siblings, 1 reply; 11+ messages in thread
From: Patchwork @ 2016-03-24 15:03 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
== Series Details ==
Series: drm/i915: Only arm the forcewake release timer on the final put (rev2)
URL : https://patchwork.freedesktop.org/series/4859/
State : failure
== Summary ==
Series 4859v2 drm/i915: Only arm the forcewake release timer on the final put
http://patchwork.freedesktop.org/api/1.0/series/4859/revisions/2/mbox/
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass -> DMESG-WARN (skl-i7k-2)
Test drv_module_reload_basic:
pass -> DMESG-WARN (bsw-nuc-2)
pass -> DMESG-WARN (skl-nuci5)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-ultra)
pass -> DMESG-WARN (skl-i7k-2)
pass -> DMESG-WARN (ivb-t430s)
pass -> DMESG-WARN (byt-nuc)
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-WARN (hsw-brixbox)
pass -> DMESG-WARN (bdw-nuci7)
Test gem_cpu_reloc:
Subgroup basic:
pass -> FAIL (skl-nuci5)
pass -> FAIL (skl-i7k-2)
Test gem_cs_tlb:
Subgroup basic-default:
pass -> SKIP (skl-nuci5)
pass -> SKIP (skl-i7k-2)
Test gem_ctx_basic:
pass -> DMESG-WARN (bdw-nuci7)
Test gem_ctx_exec:
Subgroup basic:
pass -> FAIL (skl-nuci5)
Test gem_ctx_param_basic:
Subgroup basic:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup basic-default:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup invalid-ctx-set:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup invalid-param-get:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup invalid-param-set:
pass -> DMESG-WARN (skl-i7k-2)
Subgroup invalid-size-set:
pass -> DMESG-WARN (skl-i7k-2)
Subgroup non-root-set:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup root-set-no-zeromap-enabled:
pass -> DMESG-WARN (bdw-nuci7)
Test gem_exec_basic:
Subgroup basic-blt:
pass -> SKIP (skl-nuci5)
Subgroup basic-bsd:
pass -> DMESG-FAIL (skl-nuci5)
Subgroup basic-bsd2:
pass -> SKIP (bdw-nuci7)
Subgroup basic-default:
pass -> SKIP (skl-nuci5)
Subgroup basic-render:
pass -> SKIP (bdw-nuci7)
Subgroup basic-vebox:
pass -> SKIP (bdw-nuci7)
Subgroup gtt-blt:
pass -> SKIP (skl-nuci5)
pass -> DMESG-FAIL (bdw-nuci7)
pass -> DMESG-FAIL (skl-i7k-2)
Subgroup gtt-bsd:
pass -> DMESG-FAIL (skl-nuci5)
Subgroup gtt-bsd1:
pass -> SKIP (skl-nuci5)
Subgroup gtt-default:
pass -> SKIP (skl-nuci5)
Subgroup gtt-render:
pass -> SKIP (skl-nuci5)
Subgroup gtt-vebox:
pass -> SKIP (skl-nuci5)
pass -> SKIP (skl-i7k-2)
Subgroup readonly-blt:
pass -> SKIP (skl-nuci5)
pass -> DMESG-FAIL (bdw-nuci7)
Subgroup readonly-bsd:
pass -> SKIP (skl-nuci5)
pass -> DMESG-FAIL (skl-i7k-2)
Subgroup readonly-bsd1:
pass -> DMESG-FAIL (bdw-nuci7)
Subgroup readonly-bsd2:
pass -> DMESG-FAIL (skl-nuci5)
pass -> SKIP (bdw-nuci7)
Subgroup readonly-default:
pass -> SKIP (skl-nuci5)
pass -> SKIP (bdw-nuci7)
Subgroup readonly-render:
pass -> SKIP (skl-nuci5)
pass -> SKIP (skl-i7k-2)
Subgroup readonly-vebox:
pass -> DMESG-FAIL (skl-nuci5)
pass -> SKIP (skl-i7k-2)
Test gem_exec_nop:
Subgroup basic:
pass -> DMESG-FAIL (bdw-nuci7)
Test gem_exec_store:
Subgroup basic-blt:
pass -> SKIP (skl-nuci5)
pass -> DMESG-FAIL (bdw-nuci7)
Subgroup basic-bsd:
pass -> DMESG-FAIL (skl-nuci5)
pass -> SKIP (bdw-nuci7)
Subgroup basic-bsd1:
pass -> SKIP (skl-nuci5)
Subgroup basic-bsd2:
pass -> SKIP (skl-nuci5)
Subgroup basic-default:
pass -> SKIP (skl-nuci5)
pass -> SKIP (skl-i7k-2)
Subgroup basic-render:
pass -> SKIP (skl-nuci5)
pass -> SKIP (skl-i7k-2)
Subgroup basic-vebox:
pass -> SKIP (skl-nuci5)
pass -> DMESG-FAIL (bdw-nuci7)
pass -> DMESG-FAIL (skl-i7k-2)
Test gem_exec_suspend:
Subgroup basic-s3:
pass -> DMESG-WARN (bsw-nuc-2)
pass -> SKIP (skl-nuci5)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-ultra)
pass -> DMESG-WARN (skl-i7k-2)
pass -> DMESG-WARN (ivb-t430s)
pass -> DMESG-WARN (byt-nuc)
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-WARN (hsw-brixbox)
pass -> DMESG-WARN (bdw-nuci7)
Test gem_exec_whisper:
Subgroup basic:
pass -> SKIP (skl-nuci5)
pass -> FAIL (ivb-t430s)
Test gem_flink_basic:
Subgroup bad-open:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup flink-lifetime:
pass -> DMESG-WARN (bdw-nuci7)
Test gem_linear_blits:
Subgroup basic:
pass -> DMESG-FAIL (skl-i7k-2)
Test gem_mmap_gtt:
Subgroup basic:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup basic-read-write-distinct:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup basic-small-bo-tiledy:
pass -> DMESG-WARN (skl-nuci5)
Subgroup basic-small-copy-xy:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup basic-write-no-prefault:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup basic-write-read:
pass -> DMESG-WARN (bdw-nuci7)
Test gem_render_linear_blits:
Subgroup basic:
pass -> FAIL (skl-nuci5)
pass -> FAIL (bdw-nuci7)
Test gem_render_tiled_blits:
Subgroup basic:
pass -> FAIL (skl-nuci5)
pass -> FAIL (bdw-nuci7)
Test gem_ringfill:
Subgroup basic-default-forked:
pass -> SKIP (skl-nuci5)
pass -> SKIP (bdw-nuci7)
Subgroup basic-default-hang:
pass -> SKIP (skl-nuci5)
pass -> SKIP (bdw-nuci7)
pass -> SKIP (skl-i7k-2)
Subgroup basic-default-interruptible:
pass -> SKIP (bdw-nuci7)
pass -> SKIP (skl-i7k-2)
Test gem_storedw_loop:
Subgroup basic-blt:
pass -> DMESG-FAIL (skl-nuci5)
pass -> DMESG-FAIL (skl-i7k-2)
Subgroup basic-bsd:
pass -> DMESG-FAIL (skl-nuci5)
Subgroup basic-bsd1:
pass -> DMESG-FAIL (bdw-nuci7)
Subgroup basic-bsd2:
pass -> DMESG-FAIL (bdw-nuci7)
Subgroup basic-render:
pass -> SKIP (skl-nuci5)
pass -> SKIP (skl-i7k-2) UNSTABLE
Subgroup basic-vebox:
pass -> SKIP (skl-nuci5)
pass -> DMESG-FAIL (bdw-nuci7)
Test gem_sync:
Subgroup basic-blt:
pass -> SKIP (bdw-nuci7)
Subgroup basic-bsd:
pass -> SKIP (skl-nuci5)
pass -> DMESG-FAIL (bdw-nuci7)
Subgroup basic-bsd1:
pass -> SKIP (skl-nuci5)
pass -> DMESG-FAIL (bdw-nuci7)
Subgroup basic-bsd2:
pass -> SKIP (skl-nuci5)
pass -> SKIP (bdw-nuci7)
Subgroup basic-default:
pass -> SKIP (bdw-nuci7)
Subgroup basic-render:
pass -> SKIP (skl-nuci5)
pass -> SKIP (bdw-nuci7) UNSTABLE
pass -> SKIP (skl-i7k-2) UNSTABLE
Subgroup basic-vebox:
pass -> SKIP (skl-nuci5)
pass -> DMESG-FAIL (bdw-nuci7)
Test gem_tiled_blits:
Subgroup basic:
pass -> FAIL (skl-nuci5)
pass -> FAIL (bdw-nuci7)
pass -> FAIL (skl-i7k-2)
Test gem_tiled_fence_blits:
Subgroup basic:
pass -> FAIL (skl-nuci5)
Test gem_tiled_pread_basic:
pass -> DMESG-WARN (bdw-nuci7)
Test kms_addfb_basic:
Subgroup addfb25-x-tiled:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup bad-pitch-0:
pass -> DMESG-WARN (skl-nuci5)
Subgroup bad-pitch-1024:
pass -> DMESG-WARN (skl-nuci5)
Subgroup bad-pitch-63:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup bad-pitch-999:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup bo-too-small:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup framebuffer-vs-set-tiling:
pass -> DMESG-WARN (skl-i7k-2)
Subgroup too-high:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup unused-handle:
pass -> DMESG-WARN (bdw-nuci7)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (snb-x220t)
pass -> FAIL (skl-nuci5)
pass -> DMESG-FAIL (bdw-nuci7)
pass -> FAIL (skl-i7k-2)
pass -> DMESG-WARN (bdw-ultra)
Subgroup basic-flip-vs-modeset:
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-ultra)
Subgroup basic-flip-vs-wf_vblank:
pass -> DMESG-FAIL (snb-x220t)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-FAIL (skl-nuci5)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-FAIL (bdw-nuci7)
Subgroup basic-plain-flip:
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-nuci7)
pass -> DMESG-WARN (bdw-ultra)
Test kms_force_connector_basic:
Subgroup force-load-detect:
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-WARN (hsw-gt2)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass -> DMESG-WARN (snb-dellxps)
pass -> FAIL (skl-nuci5)
pass -> DMESG-WARN (bdw-nuci7)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup bad-nb-words-3:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup bad-pipe:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup hang-read-crc-pipe-a:
pass -> SKIP (skl-nuci5)
Subgroup hang-read-crc-pipe-b:
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (bdw-nuci7)
pass -> SKIP (skl-i7k-2)
Subgroup hang-read-crc-pipe-c:
pass -> SKIP (skl-nuci5)
pass -> SKIP (bdw-nuci7)
Subgroup nonblocking-crc-pipe-a:
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (skl-nuci5)
pass -> DMESG-WARN (bdw-nuci7)
pass -> DMESG-WARN (skl-i7k-2)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-b:
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (skl-nuci5)
pass -> DMESG-WARN (bdw-nuci7)
pass -> DMESG-WARN (skl-i7k-2)
pass -> DMESG-WARN (bdw-ultra)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-WARN (skl-nuci5)
Subgroup nonblocking-crc-pipe-c:
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-nuci7)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-nuci7)
pass -> DMESG-WARN (bdw-ultra)
Subgroup read-crc-pipe-a:
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-WARN (hsw-gt2)
Subgroup read-crc-pipe-a-frame-sequence:
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-nuci7)
Subgroup read-crc-pipe-b:
pass -> DMESG-WARN (snb-x220t)
Subgroup read-crc-pipe-b-frame-sequence:
pass -> DMESG-WARN (hsw-gt2)
Subgroup read-crc-pipe-c:
pass -> DMESG-WARN (skl-nuci5)
Subgroup read-crc-pipe-c-frame-sequence:
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (skl-i7k-2)
Subgroup suspend-read-crc-pipe-a:
pass -> DMESG-WARN (skl-nuci5)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-ultra)
pass -> DMESG-WARN (skl-i7k-2)
pass -> DMESG-WARN (ivb-t430s)
pass -> DMESG-WARN (byt-nuc)
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-WARN (hsw-brixbox)
pass -> DMESG-WARN (bdw-nuci7)
Subgroup suspend-read-crc-pipe-b:
pass -> DMESG-WARN (skl-nuci5)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-ultra)
pass -> DMESG-WARN (skl-i7k-2)
pass -> DMESG-WARN (ivb-t430s)
pass -> DMESG-WARN (byt-nuc)
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-WARN (hsw-brixbox)
pass -> DMESG-WARN (bdw-nuci7)
Subgroup suspend-read-crc-pipe-c:
pass -> DMESG-WARN (bsw-nuc-2)
pass -> DMESG-WARN (skl-nuci5)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-ultra)
pass -> DMESG-WARN (skl-i7k-2)
pass -> DMESG-WARN (ivb-t430s)
pass -> DMESG-WARN (hsw-brixbox)
pass -> DMESG-WARN (bdw-nuci7)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass -> DMESG-WARN (bsw-nuc-2)
pass -> DMESG-WARN (skl-nuci5)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-ultra)
pass -> FAIL (skl-i7k-2)
pass -> DMESG-WARN (byt-nuc)
fail -> DMESG-FAIL (snb-x220t)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-WARN (hsw-brixbox)
pass -> DMESG-WARN (bdw-nuci7)
Subgroup basic-rte:
pass -> DMESG-WARN (bsw-nuc-2)
pass -> FAIL (skl-nuci5)
pass -> DMESG-WARN (hsw-gt2)
pass -> DMESG-WARN (bdw-ultra)
pass -> DMESG-WARN (skl-i7k-2)
pass -> DMESG-WARN (snb-x220t)
pass -> DMESG-WARN (snb-dellxps)
pass -> DMESG-WARN (hsw-brixbox)
pass -> FAIL (bdw-nuci7)
Test prime_self_import:
Subgroup basic-with_one_bo:
pass -> DMESG-WARN (bdw-nuci7)
Subgroup basic-with_two_bos:
pass -> DMESG-WARN (bdw-nuci7)
bdw-nuci7 total:192 pass:107 dwarn:40 dfail:14 fail:5 skip:26
bdw-ultra total:192 pass:157 dwarn:13 dfail:0 fail:1 skip:21
bsw-nuc-2 total:192 pass:150 dwarn:5 dfail:0 fail:0 skip:37
byt-nuc total:192 pass:151 dwarn:6 dfail:0 fail:0 skip:35
hsw-brixbox total:192 pass:163 dwarn:7 dfail:0 fail:0 skip:22
hsw-gt2 total:192 pass:155 dwarn:20 dfail:0 fail:0 skip:17
ivb-t430s total:192 pass:161 dwarn:5 dfail:0 fail:1 skip:25
skl-i7k-2 total:192 pass:136 dwarn:13 dfail:5 fail:4 skip:34
skl-nuci5 total:192 pass:121 dwarn:12 dfail:8 fail:9 skip:42
snb-dellxps total:192 pass:147 dwarn:11 dfail:0 fail:0 skip:34
snb-x220t total:192 pass:141 dwarn:16 dfail:2 fail:0 skip:33
Results at /archive/results/CI_IGT_test/Patchwork_1708/
f5d413cccefa1f93d64c34f357151d42add63a84 drm-intel-nightly: 2016y-03m-24d-14h-34m-29s UTC integration manifest
549f59df90766605d872aede19d1539b62b63ad5 drm/i915: Only arm the forcewake release timer on the final put
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread