Skip to contentSkip to conversation

drm/i915/gvt: Fix crash after request->hw_context change

PATCH Superseded Zhenyu Wang 3 participants 13 messages May 18, 2018 – May 21, 2018

Subsystems (3)
DRM drivers Intel i915 Intel GVT-g drivers (Intel GPU Virtualization)
lore
Share & tools
lore

Zhenyu Wang

author
#0 lore raw

PATCH 1/1 drm/i915/gvt: Fix crash after request->hw_context change

When we do shadowing, workload's request might not be allocated yet, so we still require shadow context's object. And when complete workload, delay to zero workload's request pointer after used for update guest context.

Fixes 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in i915_request")
Cc Chris Wilson <[email protected]>
Cc Tvrtko Ursulin <[email protected]>
Signed-off-by Zhenyu Wang <[email protected]>
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/gvt/scheduler.c +6 -6
index 2efb723b90cb..00f79fc940da 100644
@@ -125,8 +125,9 @@ static int populate_shadow_context(struct intel_vgpu_workload *workload)
 	struct intel_vgpu *vgpu = workload->vgpu;
 	struct intel_gvt *gvt = vgpu->gvt;
 	int ring_id = workload->ring_id;
+	struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
 	struct drm_i915_gem_object *ctx_obj =
-		workload->req->hw_context->state->obj;
+		shadow_ctx->__engine[ring_id].state->obj;
 	struct execlist_ring_context *shadow_ring_context;
 	struct page *page;
 	void *dst;

@@ -595,8 +596,6 @@ static int prepare_workload(struct intel_vgpu_workload *workload)
 		return ret;
 	}
 
-	update_shadow_pdps(workload);
-
 	ret = intel_vgpu_sync_oos_pages(workload->vgpu);
 	if (ret) {
 		gvt_vgpu_err("fail to vgpu sync oos pages\n");

@@ -615,6 +614,8 @@ static int prepare_workload(struct intel_vgpu_workload *workload)
 		goto err_unpin_mm;
 	}
 
+	update_shadow_pdps(workload);
+
 	ret = prepare_shadow_batch_buffer(workload);
 	if (ret) {
 		gvt_vgpu_err("fail to prepare_shadow_batch_buffer\n");

@@ -825,7 +826,7 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 		scheduler->current_workload[ring_id];
 	struct intel_vgpu *vgpu = workload->vgpu;
 	struct intel_vgpu_submission *s = &vgpu->submission;
-	struct i915_request *rq;
+	struct i915_request *rq = workload->req;
 	int event;
 
 	mutex_lock(&vgpu->vgpu_lock);

@@ -835,7 +836,6 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 	 * switch to make sure request is completed.
 	 * For the workload w/o request, directly complete the workload.
 	 */
-	rq = fetch_and_zero(&workload->req);
 	if (rq) {
 		wait_event(workload->shadow_ctx_status_wq,
 			   !atomic_read(&workload->shadow_ctx_active));

@@ -866,7 +866,7 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 		intel_context_unpin(rq->hw_context);
 		mutex_unlock(&rq->i915->drm.struct_mutex);
 
-		i915_request_put(rq);
+		i915_request_put(fetch_and_zero(&workload->req));
 	}
 
 	gvt_dbg_sched("ring id %d complete workload %p status %d\n",
Signature · 6 lines
2.17.0

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
#1 lore raw

Quoting Zhenyu Wang (2018-05-18 11:13:05)

Quoted 3 lines

When we do shadowing, workload's request might not be allocated yet, so we still require shadow context's object. And when complete workload, delay to zero workload's request pointer after used for update guest context.

Please allocate the context earlier then. The point is that until you do, shadow_ctx->__engine[ring_id]->state is *undefined* and this code is still illegal. :-p

The intent is that you start tracking the lifetime of the state you are using because the assumptions made here will not hold for much longer. -Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#2 lore raw
Quoted 11 lines · Chris Wilson

Quoting Zhenyu Wang (2018-05-18 11:13:05)

Quoted 3 lines

When we do shadowing, workload's request might not be allocated yet, so we still require shadow context's object. And when complete workload, delay to zero workload's request pointer after used for update guest context.

Please allocate the context earlier then. The point is that until you do, shadow_ctx->__engine[ring_id]->state is *undefined* and this code is still illegal. :-p

The intent is that you start tracking the lifetime of the state you are using because the assumptions made here will not hold for much longer.

Chris, after double check, for shadowing we do assure to pin our context earlier for target engine context, so shadow_ctx->__engine[ring_id]->state is always valid. We just don't require the real request be generated earlier during scan/shadow, so use pinned context state pointer directly. Will that be a problem in future?

Signature · 3 lines
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#3 lore raw

Quoting Zhenyu Wang (2018-05-21 04:44:34)

Quoted 10 lines · Chris Wilson
Quoted 9 lines

Quoting Zhenyu Wang (2018-05-18 11:13:05)

Quoted 3 lines

When we do shadowing, workload's request might not be allocated yet, so we still require shadow context's object. And when complete workload, delay to zero workload's request pointer after used for update guest context.

Please allocate the context earlier then. The point is that until you do, shadow_ctx->__engine[ring_id]->state is *undefined* and this code is still illegal. :-p

Quoted 8 lines
Quoted 2 lines

The intent is that you start tracking the lifetime of the state you are using because the assumptions made here will not hold for much longer.

Chris, after double check, for shadowing we do assure to pin our context earlier for target engine context, so shadow_ctx->__engine[ring_id]->state is always valid. We just don't require the real request be generated earlier during scan/shadow, so use pinned context state pointer directly. Will that be a problem in future?

It's just a matter of how you get it. The only reason I was using the request was that had an explicit pointer to the pinned context; it looked easier to keep using that rather than add a separate context member. If you would rather do that, do so -- please don't keep tacitly using the gem_context to derive the intel_context without any obvious sign of protection. (It's just that the link between gem_context and intel_context is going to become more tenuous, so it is important we make the ownership and lifecycle of intel_context more explicit.) -Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

CI
#4 lore raw

✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix crash after request->hw_context change

In reply to Zhenyu Wang
== Series Details ==

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change
URL : https://patchwork.freedesktop.org/series/43406/
State : failure

== Summary ==

Applying: drm/i915/gvt: Fix crash after request->hw_context change
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gvt/scheduler.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/gvt: Fix crash after request->hw_context change The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#5 lore raw

Re: ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix crash after request->hw_context change

Quoting Patchwork (2018-05-18 11:55:01)

Quoted 6 lines

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change
URL : https://patchwork.freedesktop.org/series/43406/
State : failure

Quoted 6 lines

== Summary ==

Applying: drm/i915/gvt: Fix crash after request->hw_context change
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gvt/scheduler.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/gvt: Fix crash after request->hw_context change

Wrong tree used as teh baseline, could you resend? Or an alternative to avoid dereferencing state outside of being pinned?
-Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#6 lore raw

Re: ??? Fi.CI.BAT: failure for drm/i915/gvt: Fix crash after request->hw_context change

Quoted 9 lines · Chris Wilson

Quoting Patchwork (2018-05-18 11:55:01)

Quoted 8 lines

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change
URL : https://patchwork.freedesktop.org/series/43406/
State : failure

== Summary ==

Quoted 7 lines
Quoted 4 lines

Applying: drm/i915/gvt: Fix crash after request->hw_context change
error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gvt/scheduler.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/gvt: Fix crash after request->hw_context change

Wrong tree used as teh baseline, could you resend? Or an alternative to avoid dereferencing state outside of being pinned?

Sorry, applied against gvt dev tree which has unmerged ones against dinq. Current code is to try to do possible shadowing earlier even not requiring real request be allocated, need to relook for proper lifetime to sort this out.

Signature · 3 lines
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#7 lore raw

PATCH v2 1/1 drm/i915/gvt: Fix crash after request->hw_context change

In reply to Zhenyu Wang

When we do shadowing, workload's request might not be allocated yet, so we still require shadow context's object. And when complete workload, delay to zero workload's request pointer after used for update guest context.

v2: Move request alloc earlier as already try to track shadow status depending on request state, which also facilitate to use request->hw_context for target engine context reference.

Fixes 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in i915_request")
Cc Chris Wilson <[email protected]>
Cc Tvrtko Ursulin <[email protected]>
Cc Zhi Wang <[email protected]>
Cc Weinan Li <[email protected]>
Signed-off-by Zhenyu Wang <[email protected]>
---
 drivers/gpu/drm/i915/gvt/scheduler.c | 52 +++++++++-------------------
 1 file changed, 16 insertions(+), 36 deletions(-)
drivers/gpu/drm/i915/gvt/scheduler.c +16 -36
index e1760030dda1..7f5e01df95ee 100644
@@ -348,6 +348,7 @@ int intel_gvt_scan_and_shadow_workload(struct intel_vgpu_workload *workload)
 	struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
 	struct intel_engine_cs *engine = dev_priv->engine[workload->ring_id];
 	struct intel_context *ce;
+	struct i915_request *rq;
 	int ret;
 
 	lockdep_assert_held(&dev_priv->drm.struct_mutex);

@@ -386,46 +387,26 @@ int intel_gvt_scan_and_shadow_workload(struct intel_vgpu_workload *workload)
 			goto err_shadow;
 	}
 
-	ret = populate_shadow_context(workload);
-	if (ret)
-		goto err_shadow;
-
-	return 0;
-
-err_shadow:
-	release_shadow_wa_ctx(&workload->wa_ctx);
-err_unpin:
-	intel_context_unpin(ce);
-	return ret;
-}
-
-static int intel_gvt_generate_request(struct intel_vgpu_workload *workload)
-{
-	int ring_id = workload->ring_id;
-	struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
-	struct i915_request *rq;
-	struct intel_vgpu *vgpu = workload->vgpu;
-	struct intel_vgpu_submission *s = &vgpu->submission;
-	struct i915_gem_context *shadow_ctx = s->shadow_ctx;
-	int ret;
-
-	rq = i915_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
+	rq = i915_request_alloc(engine, shadow_ctx);
 	if (IS_ERR(rq)) {
 		gvt_vgpu_err("fail to allocate gem request\n");
 		ret = PTR_ERR(rq);
-		goto err_unpin;
+		goto err_shadow;
 	}
-
-	gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
-
 	workload->req = i915_request_get(rq);
-	ret = copy_workload_to_ring_buffer(workload);
+
+	ret = populate_shadow_context(workload);
 	if (ret)
-		goto err_unpin;
-	return 0;
+		goto err_req;
 
-err_unpin:
+	return 0;
+err_req:
+	rq = fetch_and_zero(&workload->req);
+	i915_request_put(rq);
+err_shadow:
 	release_shadow_wa_ctx(&workload->wa_ctx);
+err_unpin:
+	intel_context_unpin(ce);
 	return ret;
 }
 

@@ -609,7 +590,7 @@ static int prepare_workload(struct intel_vgpu_workload *workload)
 		goto err_unpin_mm;
 	}
 
-	ret = intel_gvt_generate_request(workload);
+	ret = copy_workload_to_ring_buffer(workload);
 	if (ret) {
 		gvt_vgpu_err("fail to generate request\n");
 		goto err_unpin_mm;

@@ -823,7 +804,7 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 		scheduler->current_workload[ring_id];
 	struct intel_vgpu *vgpu = workload->vgpu;
 	struct intel_vgpu_submission *s = &vgpu->submission;
-	struct i915_request *rq;
+	struct i915_request *rq = workload->req;
 	int event;
 
 	mutex_lock(&gvt->lock);

@@ -832,7 +813,6 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 	 * switch to make sure request is completed.
 	 * For the workload w/o request, directly complete the workload.
 	 */
-	rq = fetch_and_zero(&workload->req);
 	if (rq) {
 		wait_event(workload->shadow_ctx_status_wq,
 			   !atomic_read(&workload->shadow_ctx_active));

@@ -863,7 +843,7 @@ static void complete_current_workload(struct intel_gvt *gvt, int ring_id)
 		intel_context_unpin(rq->hw_context);
 		mutex_unlock(&rq->i915->drm.struct_mutex);
 
-		i915_request_put(rq);
+		i915_request_put(fetch_and_zero(&workload->req));
 	}
 
 	gvt_dbg_sched("ring id %d complete workload %p status %d\n",
Signature · 6 lines
2.17.0

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by on v2 1/1
#8 lore raw

Quoting Zhenyu Wang (2018-05-21 09:17:52)

Quoted 8 lines

When we do shadowing, workload's request might not be allocated yet, so we still require shadow context's object. And when complete workload, delay to zero workload's request pointer after used for update guest context.

v2: Move request alloc earlier as already try to track shadow status depending on request state, which also facilitate to use request->hw_context for target engine context reference.

Quoted 6 lines
Fixes 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in i915_request")
Cc Chris Wilson <[email protected]>
Cc Tvrtko Ursulin <[email protected]>
Cc Zhi Wang <[email protected]>
Cc Weinan Li <[email protected]>
Signed-off-by Zhenyu Wang <[email protected]>

Looks like it's applying the principles we discussed to avoid chasing gem_context to get at the pinned intel_context,

Reviewed-by Chris Wilson <[email protected]>

Thanks for the fixup!
-Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#9 lore raw

Quoting Chris Wilson (2018-05-21 10:54:57)

Quoted 16 lines

Quoting Zhenyu Wang (2018-05-21 09:17:52)

Quoted 8 lines

When we do shadowing, workload's request might not be allocated yet, so we still require shadow context's object. And when complete workload, delay to zero workload's request pointer after used for update guest context.

v2: Move request alloc earlier as already try to track shadow status depending on request state, which also facilitate to use request->hw_context for target engine context reference.

Quoted 6 lines
Fixes 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in i915_request")
Cc Chris Wilson <[email protected]>
Cc Tvrtko Ursulin <[email protected]>
Cc Zhi Wang <[email protected]>
Cc Weinan Li <[email protected]>
Signed-off-by Zhenyu Wang <[email protected]>
Quoted 5 lines

Looks like it's applying the principles we discussed to avoid chasing gem_context to get at the pinned intel_context,

Reviewed-by Chris Wilson <[email protected]>

Thanks for the fixup!

And pushed, many thanks again.
-Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

CI
#10 lore raw

✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt: Fix crash after request->hw_context change (rev2)

In reply to Zhenyu Wang
== Series Details ==

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change (rev2)
URL : https://patchwork.freedesktop.org/series/43406/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
4eec44c20bac drm/i915/gvt: Fix crash after request->hw_context change
-:8: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#8: 
delay to zero workload's request pointer after used for update guest context.

total: 0 errors, 1 warnings, 0 checks, 96 lines checked

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

CI
#11 lore raw

✓ Fi.CI.BAT: success for drm/i915/gvt: Fix crash after request->hw_context change (rev2)

In reply to Zhenyu Wang
== Series Details ==

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change (rev2)
URL : https://patchwork.freedesktop.org/series/43406/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4211 -> Patchwork_9062 =

== Summary - SUCCESS ==

No regressions found.

External URL: https://patchwork.freedesktop.org/api/1.0/series/43406/revisions/2/mbox/

== Known issues ==

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

=== IGT changes ===

    ==== Issues hit ====

    igt@kms_chamelium@hdmi-hpd-fast:
      fi-kbl-7500u:       SKIP -> FAIL (fdo#103841, fdo#102672)

    igt@kms_frontbuffer_tracking@basic:
      fi-hsw-4200u:       PASS -> DMESG-FAIL (fdo#102614, fdo#106103)

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
      fi-cnl-psr:         PASS -> DMESG-WARN (fdo#104951)

    
    ==== Possible fixes ====

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
      fi-cnl-y3:          DMESG-WARN (fdo#104951) -> PASS

fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951
fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103

== Participating hosts (42 -> 38) ==

Missing (4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq

== Build changes ==

* Linux: CI_DRM_4211 -> Patchwork_9062

CI_DRM_4211: 1427d7c0760072ddcb2060fce079cc5c70fec914 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9062: 4eec44c20bac95e27cf69a4fdfa811ecf6f7a81a @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit

== Linux commits ==

4eec44c20bac drm/i915/gvt: Fix crash after request->hw_context change

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9062/issues.html
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

CI
#12 lore raw

✓ Fi.CI.IGT: success for drm/i915/gvt: Fix crash after request->hw_context change (rev2)

In reply to Zhenyu Wang
== Series Details ==

== Series Details ==

Series: drm/i915/gvt: Fix crash after request->hw_context change (rev2)
URL : https://patchwork.freedesktop.org/series/43406/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4211_full -> Patchwork_9062_full =

== Summary - WARNING ==

Minor unknown changes coming with Patchwork_9062_full need to be verified manually.

If you think the reported changes have nothing to do with the changes introduced in Patchwork_9062_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI.

External URL: https://patchwork.freedesktop.org/api/1.0/series/43406/revisions/2/mbox/

== Possible new issues ==

Here are the unknown changes that may have been introduced in Patchwork_9062_full:

=== IGT changes ===

    ==== Warnings ====

    igt@gem_exec_schedule@deep-bsd2:
      shard-kbl:          PASS -> SKIP

    igt@gem_exec_schedule@deep-render:
      shard-kbl:          SKIP -> PASS

== Known issues ==

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

=== IGT changes ===

    ==== Issues hit ====

    igt@kms_cursor_legacy@flip-vs-cursor-legacy:
      shard-hsw:          PASS -> FAIL (fdo#102670)

    igt@kms_flip@2x-flip-vs-expired-vblank:
      shard-glk:          PASS -> FAIL (fdo#105363)

    igt@kms_flip@2x-wf_vblank-ts-check-interruptible:
      shard-hsw:          PASS -> FAIL (fdo#103928)

    igt@kms_flip@plain-flip-ts-check:
      shard-glk:          PASS -> FAIL (fdo#100368)

    igt@kms_flip_tiling@flip-to-x-tiled:
      shard-glk:          PASS -> FAIL (fdo#104724)

    igt@kms_flip_tiling@flip-y-tiled:
      shard-glk:          PASS -> FAIL (fdo#103822, fdo#104724)

    igt@kms_setmode@basic:
      shard-apl:          PASS -> FAIL (fdo#99912)

    igt@perf@polling:
      shard-hsw:          PASS -> FAIL (fdo#102252)

    
    ==== Possible fixes ====

    igt@gem_exec_schedule@deep-bsd1:
      shard-kbl:          DMESG-WARN (fdo#103558, fdo#105602) -> PASS +1

    igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
      shard-glk:          FAIL (fdo#105703) -> PASS

    igt@kms_flip_tiling@flip-to-y-tiled:
      shard-glk:          FAIL (fdo#104724) -> PASS

    igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc:
      shard-glk:          FAIL (fdo#103167, fdo#104724) -> PASS

    igt@kms_setmode@basic:
      shard-kbl:          FAIL (fdo#99912) -> PASS

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558
fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602
fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

== Participating hosts (9 -> 9) ==

No changes in participating hosts

== Build changes ==

* Linux: CI_DRM_4211 -> Patchwork_9062

CI_DRM_4211: 1427d7c0760072ddcb2060fce079cc5c70fec914 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9062: 4eec44c20bac95e27cf69a4fdfa811ecf6f7a81a @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9062/shards.html
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx