All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
@ 2019-02-11 13:50 Chris Wilson
  2019-02-11 13:50 ` [PATCH 2/2] drm/i915: Use synchronize_srcu_expedited() for resets Chris Wilson
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Chris Wilson @ 2019-02-11 13:50 UTC (permalink / raw)
  To: intel-gfx; +Cc: Mika Kuoppala

We need to flush our srcu protecting resources about to be clobbered
by the reset, inside of our timer failsafe but outside of the
error->wedge_mutex, so that the failsafe can run in case the
synchronize_srcu() takes too long (hits a shrinker deadlock?).

Fixes: 72eb16df010a ("drm/i915: Serialise resets with wedging")
References: https://bugs.freedesktop.org/show_bug.cgi?id=109605
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_reset.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c
index 9494b015185a..c2b7570730c2 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -941,9 +941,6 @@ static int do_reset(struct drm_i915_private *i915, unsigned int stalled_mask)
 {
 	int err, i;
 
-	/* Flush everyone currently using a resource about to be clobbered */
-	synchronize_srcu(&i915->gpu_error.reset_backoff_srcu);
-
 	err = intel_gpu_reset(i915, ALL_ENGINES);
 	for (i = 0; err && i < RESET_MAX_RETRIES; i++) {
 		msleep(10 * (i + 1));
@@ -1140,6 +1137,9 @@ static void i915_reset_device(struct drm_i915_private *i915,
 	i915_wedge_on_timeout(&w, i915, 5 * HZ) {
 		intel_prepare_reset(i915);
 
+		/* Flush everyone using a resource about to be clobbered */
+		synchronize_srcu(&error->reset_backoff_srcu);
+
 		mutex_lock(&error->wedge_mutex);
 		i915_reset(i915, engine_mask, reason);
 		mutex_unlock(&error->wedge_mutex);
-- 
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] 9+ messages in thread

* [PATCH 2/2] drm/i915: Use synchronize_srcu_expedited() for resets
  2019-02-11 13:50 [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex Chris Wilson
@ 2019-02-11 13:50 ` Chris Wilson
  2019-02-11 15:13   ` Mika Kuoppala
  2019-02-11 15:09 ` [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex Mika Kuoppala
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 9+ messages in thread
From: Chris Wilson @ 2019-02-11 13:50 UTC (permalink / raw)
  To: intel-gfx; +Cc: Mika Kuoppala

We impose upon ourselves a strict timeout for resets (to ensure forward
progress by use of a failsafe). Prefer to use the expedited
synchronisation function in this case to reduce the likelihood of a
spurious delay being treated as a deadlock.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
---
 drivers/gpu/drm/i915/i915_reset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c
index c2b7570730c2..c1b53533ada6 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -1138,7 +1138,7 @@ static void i915_reset_device(struct drm_i915_private *i915,
 		intel_prepare_reset(i915);
 
 		/* Flush everyone using a resource about to be clobbered */
-		synchronize_srcu(&error->reset_backoff_srcu);
+		synchronize_srcu_expedited(&error->reset_backoff_srcu);
 
 		mutex_lock(&error->wedge_mutex);
 		i915_reset(i915, engine_mask, reason);
-- 
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] 9+ messages in thread

* Re: [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
  2019-02-11 13:50 [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex Chris Wilson
  2019-02-11 13:50 ` [PATCH 2/2] drm/i915: Use synchronize_srcu_expedited() for resets Chris Wilson
@ 2019-02-11 15:09 ` Mika Kuoppala
  2019-02-11 15:14   ` Chris Wilson
  2019-02-11 15:59 ` ✓ Fi.CI.BAT: success for series starting with [1/2] " Patchwork
  2019-02-11 19:38 ` ✓ Fi.CI.IGT: " Patchwork
  3 siblings, 1 reply; 9+ messages in thread
From: Mika Kuoppala @ 2019-02-11 15:09 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

Chris Wilson <chris@chris-wilson.co.uk> writes:

> We need to flush our srcu protecting resources about to be clobbered
> by the reset, inside of our timer failsafe but outside of the
> error->wedge_mutex, so that the failsafe can run in case the
> synchronize_srcu() takes too long (hits a shrinker deadlock?).
>
> Fixes: 72eb16df010a ("drm/i915: Serialise resets with wedging")
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109605
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_reset.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c
> index 9494b015185a..c2b7570730c2 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -941,9 +941,6 @@ static int do_reset(struct drm_i915_private *i915, unsigned int stalled_mask)
>  {
>  	int err, i;
>  
> -	/* Flush everyone currently using a resource about to be clobbered */
> -	synchronize_srcu(&i915->gpu_error.reset_backoff_srcu);
> -
>  	err = intel_gpu_reset(i915, ALL_ENGINES);
>  	for (i = 0; err && i < RESET_MAX_RETRIES; i++) {
>  		msleep(10 * (i + 1));
> @@ -1140,6 +1137,9 @@ static void i915_reset_device(struct drm_i915_private *i915,
>  	i915_wedge_on_timeout(&w, i915, 5 * HZ) {
>  		intel_prepare_reset(i915);
>  
> +		/* Flush everyone using a resource about to be clobbered */
> +		synchronize_srcu(&error->reset_backoff_srcu);
> +

Do we easily see which one it will be? This one or
the block below to timeout on wedge?

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

>  		mutex_lock(&error->wedge_mutex);
>  		i915_reset(i915, engine_mask, reason);
>  		mutex_unlock(&error->wedge_mutex);
> -- 
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] drm/i915: Use synchronize_srcu_expedited() for resets
  2019-02-11 13:50 ` [PATCH 2/2] drm/i915: Use synchronize_srcu_expedited() for resets Chris Wilson
@ 2019-02-11 15:13   ` Mika Kuoppala
  2019-02-11 15:24     ` Chris Wilson
  0 siblings, 1 reply; 9+ messages in thread
From: Mika Kuoppala @ 2019-02-11 15:13 UTC (permalink / raw)
  To: Chris Wilson, intel-gfx

Chris Wilson <chris@chris-wilson.co.uk> writes:

> We impose upon ourselves a strict timeout for resets (to ensure forward
> progress by use of a failsafe). Prefer to use the expedited
> synchronisation function in this case to reduce the likelihood of a
> spurious delay being treated as a deadlock.

5 seconds of spurious delay?

Well, better to rule this one out,

Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>

>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_reset.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c
> index c2b7570730c2..c1b53533ada6 100644
> --- a/drivers/gpu/drm/i915/i915_reset.c
> +++ b/drivers/gpu/drm/i915/i915_reset.c
> @@ -1138,7 +1138,7 @@ static void i915_reset_device(struct drm_i915_private *i915,
>  		intel_prepare_reset(i915);
>  
>  		/* Flush everyone using a resource about to be clobbered */
> -		synchronize_srcu(&error->reset_backoff_srcu);
> +		synchronize_srcu_expedited(&error->reset_backoff_srcu);
>  
>  		mutex_lock(&error->wedge_mutex);
>  		i915_reset(i915, engine_mask, reason);
> -- 
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
  2019-02-11 15:09 ` [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex Mika Kuoppala
@ 2019-02-11 15:14   ` Chris Wilson
  0 siblings, 0 replies; 9+ messages in thread
From: Chris Wilson @ 2019-02-11 15:14 UTC (permalink / raw)
  To: Mika Kuoppala, intel-gfx

Quoting Mika Kuoppala (2019-02-11 15:09:48)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > We need to flush our srcu protecting resources about to be clobbered
> > by the reset, inside of our timer failsafe but outside of the
> > error->wedge_mutex, so that the failsafe can run in case the
> > synchronize_srcu() takes too long (hits a shrinker deadlock?).
> >
> > Fixes: 72eb16df010a ("drm/i915: Serialise resets with wedging")
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=109605
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_reset.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c
> > index 9494b015185a..c2b7570730c2 100644
> > --- a/drivers/gpu/drm/i915/i915_reset.c
> > +++ b/drivers/gpu/drm/i915/i915_reset.c
> > @@ -941,9 +941,6 @@ static int do_reset(struct drm_i915_private *i915, unsigned int stalled_mask)
> >  {
> >       int err, i;
> >  
> > -     /* Flush everyone currently using a resource about to be clobbered */
> > -     synchronize_srcu(&i915->gpu_error.reset_backoff_srcu);
> > -
> >       err = intel_gpu_reset(i915, ALL_ENGINES);
> >       for (i = 0; err && i < RESET_MAX_RETRIES; i++) {
> >               msleep(10 * (i + 1));
> > @@ -1140,6 +1137,9 @@ static void i915_reset_device(struct drm_i915_private *i915,
> >       i915_wedge_on_timeout(&w, i915, 5 * HZ) {
> >               intel_prepare_reset(i915);
> >  
> > +             /* Flush everyone using a resource about to be clobbered */
> > +             synchronize_srcu(&error->reset_backoff_srcu);
> > +
> 
> Do we easily see which one it will be? This one or
> the block below to timeout on wedge?

It would be easy to reconstruct if we have all the stack traces so we
can switch which process is stuck where, but we do not. Failing that my
hunch is that it's sync_srcu taking too long, and by design we know it
can deadlock around an unfortunate shrinker interaction :( But I'm not
entirely convinced we're hitting that.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] drm/i915: Use synchronize_srcu_expedited() for resets
  2019-02-11 15:13   ` Mika Kuoppala
@ 2019-02-11 15:24     ` Chris Wilson
  0 siblings, 0 replies; 9+ messages in thread
From: Chris Wilson @ 2019-02-11 15:24 UTC (permalink / raw)
  To: Mika Kuoppala, intel-gfx

Quoting Mika Kuoppala (2019-02-11 15:13:19)
> Chris Wilson <chris@chris-wilson.co.uk> writes:
> 
> > We impose upon ourselves a strict timeout for resets (to ensure forward
> > progress by use of a failsafe). Prefer to use the expedited
> > synchronisation function in this case to reduce the likelihood of a
> > spurious delay being treated as a deadlock.
> 
> 5 seconds of spurious delay?

Past experience with rcu says over 30s is not unheard of; though it does
start to complain if the system skips over 120s without an rcu grace
period.
 
> Well, better to rule this one out,

Ulterior motive is that we still want fast resets :) We shouldn't upset
the RT crowd too much as we are only using this sparingly.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
  2019-02-11 13:50 [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex Chris Wilson
  2019-02-11 13:50 ` [PATCH 2/2] drm/i915: Use synchronize_srcu_expedited() for resets Chris Wilson
  2019-02-11 15:09 ` [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex Mika Kuoppala
@ 2019-02-11 15:59 ` Patchwork
  2019-02-11 19:38 ` ✓ Fi.CI.IGT: " Patchwork
  3 siblings, 0 replies; 9+ messages in thread
From: Patchwork @ 2019-02-11 15:59 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
URL   : https://patchwork.freedesktop.org/series/56496/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5588 -> Patchwork_12194
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/56496/revisions/1/mbox/

Known issues
------------

  Here are the changes found in Patchwork_12194 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_suspend@basic-s3:
    - fi-blb-e6850:       PASS -> INCOMPLETE [fdo#107718]

  * igt@kms_chamelium@hdmi-hpd-fast:
    - fi-kbl-7500u:       PASS -> FAIL [fdo#109485]

  * igt@kms_flip@basic-flip-vs-modeset:
    - fi-skl-6700hq:      PASS -> DMESG-WARN [fdo#105998]

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
    - fi-byt-clapper:     PASS -> FAIL [fdo#107362]

  * igt@prime_vgem@basic-fence-flip:
    - fi-ilk-650:         PASS -> FAIL [fdo#104008]

  
#### Possible fixes ####

  * igt@i915_selftest@live_execlists:
    - fi-apl-guc:         INCOMPLETE [fdo#103927] -> PASS

  * igt@kms_frontbuffer_tracking@basic:
    - {fi-icl-u3}:        FAIL [fdo#103167] -> PASS

  * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
    - fi-byt-clapper:     FAIL [fdo#103191] / [fdo#107362] -> PASS

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
  [fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
  [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#109567]: https://bugs.freedesktop.org/show_bug.cgi?id=109567


Participating hosts (48 -> 42)
------------------------------

  Additional (1): fi-glk-j4005 
  Missing    (7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus 


Build changes
-------------

    * Linux: CI_DRM_5588 -> Patchwork_12194

  CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12194: 956ea687c738a4d9a9facc967f137a305c41a00f @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

956ea687c738 drm/i915: Use synchronize_srcu_expedited() for resets
f2d7e66b651f drm/i915: Pull sync_scru for device reset outside of wedge_mutex

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12194/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
  2019-02-11 13:50 [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex Chris Wilson
                   ` (2 preceding siblings ...)
  2019-02-11 15:59 ` ✓ Fi.CI.BAT: success for series starting with [1/2] " Patchwork
@ 2019-02-11 19:38 ` Patchwork
  2019-02-11 21:12   ` Chris Wilson
  3 siblings, 1 reply; 9+ messages in thread
From: Patchwork @ 2019-02-11 19:38 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: series starting with [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
URL   : https://patchwork.freedesktop.org/series/56496/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_5588_full -> Patchwork_12194_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Known issues
------------

  Here are the changes found in Patchwork_12194_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
    - shard-hsw:          PASS -> DMESG-WARN [fdo#107956]

  * igt@kms_color@pipe-c-ctm-max:
    - shard-apl:          PASS -> FAIL [fdo#108147]

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
    - shard-apl:          PASS -> FAIL [fdo#103167]

  * igt@kms_plane@plane-position-covered-pipe-a-planes:
    - shard-glk:          PASS -> FAIL [fdo#103166] +1

  * igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
    - shard-apl:          PASS -> FAIL [fdo#103166] +1

  
#### Possible fixes ####

  * igt@gem_eio@unwedge-stress:
    - shard-snb:          FAIL [fdo#107799] -> PASS

  * igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
    - shard-kbl:          DMESG-WARN [fdo#107956] -> PASS

  * igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
    - shard-glk:          FAIL [fdo#108145] -> PASS

  * igt@kms_cursor_crc@cursor-64x21-onscreen:
    - shard-apl:          FAIL [fdo#103232] -> PASS

  * igt@kms_cursor_legacy@all-pipes-torture-move:
    - shard-hsw:          DMESG-WARN [fdo#107122] -> PASS

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
    - shard-glk:          FAIL [fdo#103167] -> PASS +1

  * igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
    - shard-apl:          FAIL [fdo#103166] -> PASS
    - shard-glk:          FAIL [fdo#103166] -> PASS

  * igt@kms_setmode@basic:
    - shard-glk:          FAIL [fdo#99912] -> PASS

  
#### Warnings ####

  * igt@i915_suspend@shrink:
    - shard-glk:          INCOMPLETE [fdo#103359] / [fdo#106886] / [k.org#198133] -> DMESG-WARN [fdo#109244]

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
  [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
  [fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
  [fdo#107122]: https://bugs.freedesktop.org/show_bug.cgi?id=107122
  [fdo#107799]: https://bugs.freedesktop.org/show_bug.cgi?id=107799
  [fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
  [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
  [fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
  [fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
  [fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
  [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133


Participating hosts (7 -> 5)
------------------------------

  Missing    (2): shard-skl shard-iclb 


Build changes
-------------

    * Linux: CI_DRM_5588 -> Patchwork_12194

  CI_DRM_5588: 133ed6b29f62713f2edd95eac6ccc2ae1d6e4d6e @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4816: f62577c85c9ef0539d468d6fad105b706a15139c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_12194: 956ea687c738a4d9a9facc967f137a305c41a00f @ 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_12194/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
  2019-02-11 19:38 ` ✓ Fi.CI.IGT: " Patchwork
@ 2019-02-11 21:12   ` Chris Wilson
  0 siblings, 0 replies; 9+ messages in thread
From: Chris Wilson @ 2019-02-11 21:12 UTC (permalink / raw)
  To: Patchwork; +Cc: intel-gfx

Quoting Patchwork (2019-02-11 19:38:40)
> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex
> URL   : https://patchwork.freedesktop.org/series/56496/
> State : success
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_5588_full -> Patchwork_12194_full
> ====================================================
> 
> Summary
> -------
> 
>   **SUCCESS**
> 
>   No regressions found.

Not mentioned was that this didn't fix the hang. Nevertheless, it should
prevent one corner case from ending up in a deadlock, and it does mean
that the srcu is not responsible for the timeout here. The mystery
remains exactly what is.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-02-11 21:12 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-11 13:50 [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex Chris Wilson
2019-02-11 13:50 ` [PATCH 2/2] drm/i915: Use synchronize_srcu_expedited() for resets Chris Wilson
2019-02-11 15:13   ` Mika Kuoppala
2019-02-11 15:24     ` Chris Wilson
2019-02-11 15:09 ` [PATCH 1/2] drm/i915: Pull sync_scru for device reset outside of wedge_mutex Mika Kuoppala
2019-02-11 15:14   ` Chris Wilson
2019-02-11 15:59 ` ✓ Fi.CI.BAT: success for series starting with [1/2] " Patchwork
2019-02-11 19:38 ` ✓ Fi.CI.IGT: " Patchwork
2019-02-11 21:12   ` Chris Wilson

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.