* [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
@ 2016-01-27 15:43 daniele.ceraolospurio
2016-01-27 16:39 ` Ville Syrjälä
` (3 more replies)
0 siblings, 4 replies; 10+ messages in thread
From: daniele.ceraolospurio @ 2016-01-27 15:43 UTC (permalink / raw)
To: intel-gfx
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
While running some tests on the scheduler patches with rpm enabled I
came across a corruption in the ringbuffer, which was root-caused to
the GPU being suspended while commands were being emitted to the
ringbuffer. The access to memory was failing because the GPU needs to
be awake when accessing stolen memory (where my ringbuffer was located).
Since we have this constraint it looks like a sensible idea to check
that we hold a refcount when we access the rungbuffer.
v2: move the check from ring_begin to ringbuffer iomap time (Chris)
v3: update comment (Chris)
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 6f5b511..133321a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2119,6 +2119,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
return ret;
}
+ /* Access through the GTT requires the device to be awake. */
+ assert_rpm_wakelock_held(dev_priv);
+
ringbuf->virtual_start = ioremap_wc(dev_priv->gtt.mappable_base +
i915_gem_obj_ggtt_offset(obj), ringbuf->size);
if (ringbuf->virtual_start == NULL) {
--
1.9.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
2016-01-27 15:43 [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem daniele.ceraolospurio
@ 2016-01-27 16:39 ` Ville Syrjälä
2016-01-28 10:55 ` Daniele Ceraolo Spurio
2016-01-27 16:44 ` Chris Wilson
` (2 subsequent siblings)
3 siblings, 1 reply; 10+ messages in thread
From: Ville Syrjälä @ 2016-01-27 16:39 UTC (permalink / raw)
To: daniele.ceraolospurio; +Cc: intel-gfx
On Wed, Jan 27, 2016 at 03:43:49PM +0000, daniele.ceraolospurio@intel.com wrote:
> From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>
> While running some tests on the scheduler patches with rpm enabled I
> came across a corruption in the ringbuffer, which was root-caused to
> the GPU being suspended while commands were being emitted to the
> ringbuffer. The access to memory was failing because the GPU needs to
> be awake when accessing stolen memory (where my ringbuffer was located).
> Since we have this constraint it looks like a sensible idea to check
> that we hold a refcount when we access the rungbuffer.
>
> v2: move the check from ring_begin to ringbuffer iomap time (Chris)
> v3: update comment (Chris)
>
> Cc: John Harrison <John.C.Harrison@Intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 6f5b511..133321a 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2119,6 +2119,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
> return ret;
> }
>
> + /* Access through the GTT requires the device to be awake. */
> + assert_rpm_wakelock_held(dev_priv);
> +
Hmm. This function doesn't actually acces the ring buffer, so it's a bit
odd to see this here.
> ringbuf->virtual_start = ioremap_wc(dev_priv->gtt.mappable_base +
> i915_gem_obj_ggtt_offset(obj), ringbuf->size);
> if (ringbuf->virtual_start == NULL) {
> --
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
2016-01-27 15:43 [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem daniele.ceraolospurio
2016-01-27 16:39 ` Ville Syrjälä
@ 2016-01-27 16:44 ` Chris Wilson
2016-02-10 7:56 ` Daniel Vetter
2016-01-28 9:58 ` ✓ Fi.CI.BAT: success for drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem (rev2) Patchwork
2016-01-28 16:23 ` Patchwork
3 siblings, 1 reply; 10+ messages in thread
From: Chris Wilson @ 2016-01-27 16:44 UTC (permalink / raw)
To: daniele.ceraolospurio; +Cc: intel-gfx
On Wed, Jan 27, 2016 at 03:43:49PM +0000, daniele.ceraolospurio@intel.com wrote:
> From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>
> While running some tests on the scheduler patches with rpm enabled I
> came across a corruption in the ringbuffer, which was root-caused to
> the GPU being suspended while commands were being emitted to the
> ringbuffer. The access to memory was failing because the GPU needs to
> be awake when accessing stolen memory (where my ringbuffer was located).
> Since we have this constraint it looks like a sensible idea to check
> that we hold a refcount when we access the rungbuffer.
>
> v2: move the check from ring_begin to ringbuffer iomap time (Chris)
> v3: update comment (Chris)
>
> Cc: John Harrison <John.C.Harrison@Intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
That explains itself nicely, thanks.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
It also rings alarms bells for intel_fbdev.c
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem (rev2)
2016-01-27 15:43 [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem daniele.ceraolospurio
2016-01-27 16:39 ` Ville Syrjälä
2016-01-27 16:44 ` Chris Wilson
@ 2016-01-28 9:58 ` Patchwork
2016-01-28 16:23 ` Patchwork
3 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2016-01-28 9:58 UTC (permalink / raw)
To: daniele.ceraolospurio; +Cc: intel-gfx
== Summary ==
Built on 430706bace599ea1a908b9a7c6b7ea17535fe17f drm-intel-nightly: 2016y-01m-27d-16h-33m-06s UTC integration manifest
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b:
dmesg-warn -> PASS (ilk-hp8440p)
bdw-nuci7 total:141 pass:132 dwarn:0 dfail:0 fail:0 skip:9
bsw-nuc-2 total:144 pass:120 dwarn:0 dfail:0 fail:0 skip:24
byt-nuc total:144 pass:129 dwarn:0 dfail:0 fail:0 skip:15
hsw-brixbox total:144 pass:137 dwarn:0 dfail:0 fail:0 skip:7
hsw-gt2 total:144 pass:140 dwarn:0 dfail:0 fail:0 skip:4
ilk-hp8440p total:144 pass:105 dwarn:0 dfail:0 fail:1 skip:38
ivb-t430s total:144 pass:138 dwarn:0 dfail:0 fail:0 skip:6
skl-i5k-2 total:144 pass:135 dwarn:1 dfail:0 fail:0 skip:8
snb-dellxps total:144 pass:130 dwarn:0 dfail:0 fail:0 skip:14
snb-x220t total:144 pass:130 dwarn:0 dfail:0 fail:1 skip:13
Results at /archive/results/CI_IGT_test/Patchwork_1277/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
2016-01-27 16:39 ` Ville Syrjälä
@ 2016-01-28 10:55 ` Daniele Ceraolo Spurio
2016-01-28 11:45 ` Chris Wilson
0 siblings, 1 reply; 10+ messages in thread
From: Daniele Ceraolo Spurio @ 2016-01-28 10:55 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On 27/01/16 16:39, Ville Syrjälä wrote:
> On Wed, Jan 27, 2016 at 03:43:49PM +0000,daniele.ceraolospurio@intel.com wrote:
>> From: Daniele Ceraolo Spurio<daniele.ceraolospurio@intel.com>
>>
>> While running some tests on the scheduler patches with rpm enabled I
>> came across a corruption in the ringbuffer, which was root-caused to
>> the GPU being suspended while commands were being emitted to the
>> ringbuffer. The access to memory was failing because the GPU needs to
>> be awake when accessing stolen memory (where my ringbuffer was located).
>> Since we have this constraint it looks like a sensible idea to check
>> that we hold a refcount when we access the rungbuffer.
>>
>> v2: move the check from ring_begin to ringbuffer iomap time (Chris)
>> v3: update comment (Chris)
>>
>> Cc: John Harrison<John.C.Harrison@Intel.com>
>> Cc: Chris Wilson<chris@chris-wilson.co.uk>
>> Signed-off-by: Daniele Ceraolo Spurio<daniele.ceraolospurio@intel.com>
>> ---
>> drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 6f5b511..133321a 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -2119,6 +2119,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
>> return ret;
>> }
>>
>> + /* Access through the GTT requires the device to be awake. */
>> + assert_rpm_wakelock_held(dev_priv);
>> +
> Hmm. This function doesn't actually acces the ring buffer, so it's a bit
> odd to see this here.
I had it inring_begin initially, but Chris suggested moving it here
because we pin the ringbuffer before accessing it. Do you have a
different place in mind for where this should be added or would you be
happy with a simple comment update?
Thanks,
Daniele
>> ringbuf->virtual_start = ioremap_wc(dev_priv->gtt.mappable_base +
>> i915_gem_obj_ggtt_offset(obj), ringbuf->size);
>> if (ringbuf->virtual_start == NULL) {
>> --
>> 1.9.1
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
2016-01-28 10:55 ` Daniele Ceraolo Spurio
@ 2016-01-28 11:45 ` Chris Wilson
2016-01-28 12:09 ` Ville Syrjälä
0 siblings, 1 reply; 10+ messages in thread
From: Chris Wilson @ 2016-01-28 11:45 UTC (permalink / raw)
To: Daniele Ceraolo Spurio; +Cc: intel-gfx
On Thu, Jan 28, 2016 at 10:55:16AM +0000, Daniele Ceraolo Spurio wrote:
>
>
> On 27/01/16 16:39, Ville Syrjälä wrote:
> >On Wed, Jan 27, 2016 at 03:43:49PM +0000,daniele.ceraolospurio@intel.com wrote:
> >>From: Daniele Ceraolo Spurio<daniele.ceraolospurio@intel.com>
> >>
> >>While running some tests on the scheduler patches with rpm enabled I
> >>came across a corruption in the ringbuffer, which was root-caused to
> >>the GPU being suspended while commands were being emitted to the
> >>ringbuffer. The access to memory was failing because the GPU needs to
> >>be awake when accessing stolen memory (where my ringbuffer was located).
> >>Since we have this constraint it looks like a sensible idea to check
> >>that we hold a refcount when we access the rungbuffer.
> >>
> >>v2: move the check from ring_begin to ringbuffer iomap time (Chris)
> >>v3: update comment (Chris)
> >>
> >>Cc: John Harrison<John.C.Harrison@Intel.com>
> >>Cc: Chris Wilson<chris@chris-wilson.co.uk>
> >>Signed-off-by: Daniele Ceraolo Spurio<daniele.ceraolospurio@intel.com>
> >>---
> >> drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >>index 6f5b511..133321a 100644
> >>--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >>+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >>@@ -2119,6 +2119,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
> >> return ret;
> >> }
> >>+ /* Access through the GTT requires the device to be awake. */
> >>+ assert_rpm_wakelock_held(dev_priv);
> >>+
> >Hmm. This function doesn't actually acces the ring buffer, so it's a bit
> >odd to see this here.
>
> I had it inring_begin initially, but Chris suggested moving it here
> because we pin the ringbuffer before accessing it. Do you have a
> different place in mind for where this should be added or would you
> be happy with a simple comment update?
This function we call in order to acquire access to the ring iomap for
the request. At the beginning of the request, we should be pinning
everything we need to build the request. If writing through the GTT we
should be ensuring that the device is also awake. The oddity is that
this is not yet explicit and the asymmetry still exists between
legacy/execlists.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
2016-01-28 11:45 ` Chris Wilson
@ 2016-01-28 12:09 ` Ville Syrjälä
2016-01-28 12:30 ` Chris Wilson
0 siblings, 1 reply; 10+ messages in thread
From: Ville Syrjälä @ 2016-01-28 12:09 UTC (permalink / raw)
To: Chris Wilson, Daniele Ceraolo Spurio, intel-gfx
On Thu, Jan 28, 2016 at 11:45:24AM +0000, Chris Wilson wrote:
> On Thu, Jan 28, 2016 at 10:55:16AM +0000, Daniele Ceraolo Spurio wrote:
> >
> >
> > On 27/01/16 16:39, Ville Syrjälä wrote:
> > >On Wed, Jan 27, 2016 at 03:43:49PM +0000,daniele.ceraolospurio@intel.com wrote:
> > >>From: Daniele Ceraolo Spurio<daniele.ceraolospurio@intel.com>
> > >>
> > >>While running some tests on the scheduler patches with rpm enabled I
> > >>came across a corruption in the ringbuffer, which was root-caused to
> > >>the GPU being suspended while commands were being emitted to the
> > >>ringbuffer. The access to memory was failing because the GPU needs to
> > >>be awake when accessing stolen memory (where my ringbuffer was located).
> > >>Since we have this constraint it looks like a sensible idea to check
> > >>that we hold a refcount when we access the rungbuffer.
> > >>
> > >>v2: move the check from ring_begin to ringbuffer iomap time (Chris)
> > >>v3: update comment (Chris)
> > >>
> > >>Cc: John Harrison<John.C.Harrison@Intel.com>
> > >>Cc: Chris Wilson<chris@chris-wilson.co.uk>
> > >>Signed-off-by: Daniele Ceraolo Spurio<daniele.ceraolospurio@intel.com>
> > >>---
> > >> drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> > >> 1 file changed, 3 insertions(+)
> > >>
> > >>diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > >>index 6f5b511..133321a 100644
> > >>--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > >>+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > >>@@ -2119,6 +2119,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
> > >> return ret;
> > >> }
> > >>+ /* Access through the GTT requires the device to be awake. */
> > >>+ assert_rpm_wakelock_held(dev_priv);
> > >>+
> > >Hmm. This function doesn't actually acces the ring buffer, so it's a bit
> > >odd to see this here.
> >
> > I had it inring_begin initially, but Chris suggested moving it here
> > because we pin the ringbuffer before accessing it. Do you have a
> > different place in mind for where this should be added or would you
> > be happy with a simple comment update?
>
> This function we call in order to acquire access to the ring iomap for
> the request. At the beginning of the request, we should be pinning
> everything we need to build the request. If writing through the GTT we
> should be ensuring that the device is also awake. The oddity is that
> this is not yet explicit and the asymmetry still exists between
> legacy/execlists.
Yeah, with ringbuffer mode this gets executed exactly once, so more or
less useless at the moment. With execlists I suppose it might catch
something on CHV/BXT.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
2016-01-28 12:09 ` Ville Syrjälä
@ 2016-01-28 12:30 ` Chris Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Chris Wilson @ 2016-01-28 12:30 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Thu, Jan 28, 2016 at 02:09:37PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 28, 2016 at 11:45:24AM +0000, Chris Wilson wrote:
> > On Thu, Jan 28, 2016 at 10:55:16AM +0000, Daniele Ceraolo Spurio wrote:
> > >
> > >
> > > On 27/01/16 16:39, Ville Syrjälä wrote:
> > > >On Wed, Jan 27, 2016 at 03:43:49PM +0000,daniele.ceraolospurio@intel.com wrote:
> > > >>From: Daniele Ceraolo Spurio<daniele.ceraolospurio@intel.com>
> > > >>
> > > >>While running some tests on the scheduler patches with rpm enabled I
> > > >>came across a corruption in the ringbuffer, which was root-caused to
> > > >>the GPU being suspended while commands were being emitted to the
> > > >>ringbuffer. The access to memory was failing because the GPU needs to
> > > >>be awake when accessing stolen memory (where my ringbuffer was located).
> > > >>Since we have this constraint it looks like a sensible idea to check
> > > >>that we hold a refcount when we access the rungbuffer.
> > > >>
> > > >>v2: move the check from ring_begin to ringbuffer iomap time (Chris)
> > > >>v3: update comment (Chris)
> > > >>
> > > >>Cc: John Harrison<John.C.Harrison@Intel.com>
> > > >>Cc: Chris Wilson<chris@chris-wilson.co.uk>
> > > >>Signed-off-by: Daniele Ceraolo Spurio<daniele.ceraolospurio@intel.com>
> > > >>---
> > > >> drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
> > > >> 1 file changed, 3 insertions(+)
> > > >>
> > > >>diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > >>index 6f5b511..133321a 100644
> > > >>--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > >>+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > > >>@@ -2119,6 +2119,9 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device *dev,
> > > >> return ret;
> > > >> }
> > > >>+ /* Access through the GTT requires the device to be awake. */
> > > >>+ assert_rpm_wakelock_held(dev_priv);
> > > >>+
> > > >Hmm. This function doesn't actually acces the ring buffer, so it's a bit
> > > >odd to see this here.
> > >
> > > I had it inring_begin initially, but Chris suggested moving it here
> > > because we pin the ringbuffer before accessing it. Do you have a
> > > different place in mind for where this should be added or would you
> > > be happy with a simple comment update?
> >
> > This function we call in order to acquire access to the ring iomap for
> > the request. At the beginning of the request, we should be pinning
> > everything we need to build the request. If writing through the GTT we
> > should be ensuring that the device is also awake. The oddity is that
> > this is not yet explicit and the asymmetry still exists between
> > legacy/execlists.
>
> Yeah, with ringbuffer mode this gets executed exactly once, so more or
> less useless at the moment. With execlists I suppose it might catch
> something on CHV/BXT.
It shouldn't. We hold the wakeref for execbuf request construction, and
that is more or less the only time we create a request in execlists.
(Although it doesn't have to be that way!)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem (rev2)
2016-01-27 15:43 [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem daniele.ceraolospurio
` (2 preceding siblings ...)
2016-01-28 9:58 ` ✓ Fi.CI.BAT: success for drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem (rev2) Patchwork
@ 2016-01-28 16:23 ` Patchwork
3 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2016-01-28 16:23 UTC (permalink / raw)
To: daniele.ceraolospurio; +Cc: intel-gfx
== Summary ==
Series 2878v2 drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
http://patchwork.freedesktop.org/api/1.0/series/2878/revisions/2/mbox/
Test gem_exec_basic:
Subgroup basic-bsd1:
pass -> SKIP (bsw-nuc-2)
pass -> SKIP (hsw-gt2)
pass -> SKIP (skl-i5k-2)
pass -> SKIP (ivb-t430s)
pass -> SKIP (bdw-ultra)
pass -> SKIP (byt-nuc)
pass -> SKIP (snb-x220t)
pass -> SKIP (snb-dellxps)
pass -> SKIP (hsw-brixbox)
pass -> SKIP (ilk-hp8440p)
Subgroup basic-bsd2:
pass -> SKIP (bsw-nuc-2)
pass -> SKIP (hsw-gt2)
pass -> SKIP (skl-i5k-2)
pass -> SKIP (ivb-t430s)
pass -> SKIP (bdw-ultra)
pass -> SKIP (byt-nuc)
pass -> SKIP (snb-x220t)
pass -> SKIP (snb-dellxps)
pass -> SKIP (hsw-brixbox)
pass -> SKIP (ilk-hp8440p)
Test gem_ringfill:
Subgroup basic-default:
fail -> PASS (ilk-hp8440p)
Test gem_storedw_loop:
Subgroup basic-bsd1:
pass -> SKIP (bsw-nuc-2)
pass -> SKIP (skl-i5k-2)
pass -> SKIP (hsw-gt2)
pass -> SKIP (bdw-ultra)
pass -> SKIP (ivb-t430s)
pass -> SKIP (byt-nuc)
pass -> SKIP (hsw-brixbox)
Subgroup basic-bsd2:
pass -> SKIP (bsw-nuc-2)
pass -> SKIP (skl-i5k-2)
pass -> SKIP (hsw-gt2)
pass -> SKIP (bdw-ultra)
pass -> SKIP (ivb-t430s)
pass -> SKIP (byt-nuc)
pass -> SKIP (hsw-brixbox)
Test gem_sync:
Subgroup basic-bsd1:
pass -> SKIP (bsw-nuc-2)
pass -> SKIP (hsw-gt2)
pass -> SKIP (skl-i5k-2)
pass -> SKIP (ivb-t430s)
pass -> SKIP (bdw-ultra)
pass -> SKIP (byt-nuc)
pass -> SKIP (snb-x220t)
pass -> SKIP (snb-dellxps)
pass -> SKIP (hsw-brixbox)
pass -> SKIP (ilk-hp8440p)
Subgroup basic-bsd2:
pass -> SKIP (bsw-nuc-2)
pass -> SKIP (hsw-gt2)
pass -> SKIP (skl-i5k-2)
pass -> SKIP (ivb-t430s)
pass -> SKIP (bdw-ultra)
pass -> SKIP (byt-nuc)
pass -> SKIP (snb-x220t)
pass -> SKIP (snb-dellxps)
pass -> SKIP (hsw-brixbox)
pass -> SKIP (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE
bdw-nuci7 total:156 pass:147 dwarn:0 dfail:0 fail:0 skip:9
bdw-ultra total:159 pass:147 dwarn:0 dfail:0 fail:0 skip:12
bsw-nuc-2 total:159 pass:129 dwarn:0 dfail:0 fail:0 skip:30
byt-nuc total:159 pass:136 dwarn:0 dfail:0 fail:0 skip:23
hsw-brixbox total:159 pass:146 dwarn:0 dfail:0 fail:0 skip:13
hsw-gt2 total:159 pass:149 dwarn:0 dfail:0 fail:0 skip:10
ilk-hp8440p total:159 pass:110 dwarn:1 dfail:0 fail:0 skip:48
ivb-t430s total:159 pass:145 dwarn:0 dfail:0 fail:0 skip:14
skl-i5k-2 total:159 pass:144 dwarn:1 dfail:0 fail:0 skip:14
snb-dellxps total:159 pass:137 dwarn:0 dfail:0 fail:0 skip:22
snb-x220t total:159 pass:137 dwarn:0 dfail:0 fail:1 skip:21
Results at /archive/results/CI_IGT_test/Patchwork_1305/
b3f8ad64bc71f6236f05c2e9f4ad49a61745869a drm-intel-nightly: 2016y-01m-28d-10h-26m-23s UTC integration manifest
394a37654e14e8c2e309c26fb852fb8613c61050 drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem
2016-01-27 16:44 ` Chris Wilson
@ 2016-02-10 7:56 ` Daniel Vetter
0 siblings, 0 replies; 10+ messages in thread
From: Daniel Vetter @ 2016-02-10 7:56 UTC (permalink / raw)
To: Chris Wilson, daniele.ceraolospurio, intel-gfx, John Harrison
On Wed, Jan 27, 2016 at 04:44:37PM +0000, Chris Wilson wrote:
> On Wed, Jan 27, 2016 at 03:43:49PM +0000, daniele.ceraolospurio@intel.com wrote:
> > From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> >
> > While running some tests on the scheduler patches with rpm enabled I
> > came across a corruption in the ringbuffer, which was root-caused to
> > the GPU being suspended while commands were being emitted to the
> > ringbuffer. The access to memory was failing because the GPU needs to
> > be awake when accessing stolen memory (where my ringbuffer was located).
> > Since we have this constraint it looks like a sensible idea to check
> > that we hold a refcount when we access the rungbuffer.
> >
> > v2: move the check from ring_begin to ringbuffer iomap time (Chris)
> > v3: update comment (Chris)
> >
> > Cc: John Harrison <John.C.Harrison@Intel.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>
> That explains itself nicely, thanks.
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Queued for -next, thanks for the patch.
> It also rings alarms bells for intel_fbdev.c
Oops, indeed. Might explain why we sometimes just die? And fundamentally
it's unfixable (without a shadow fb) since we can't intercept mmaps on
fbdev. But maybe we need to do that (and use the damage tracking that's
already there in 3 copies in various drivers for uploading).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-02-10 7:56 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-27 15:43 [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem daniele.ceraolospurio
2016-01-27 16:39 ` Ville Syrjälä
2016-01-28 10:55 ` Daniele Ceraolo Spurio
2016-01-28 11:45 ` Chris Wilson
2016-01-28 12:09 ` Ville Syrjälä
2016-01-28 12:30 ` Chris Wilson
2016-01-27 16:44 ` Chris Wilson
2016-02-10 7:56 ` Daniel Vetter
2016-01-28 9:58 ` ✓ Fi.CI.BAT: success for drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem (rev2) Patchwork
2016-01-28 16:23 ` Patchwork
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.