* [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
@ 2021-03-05 17:05 ` Jason Ekstrand
0 siblings, 0 replies; 18+ messages in thread
From: Jason Ekstrand @ 2021-03-05 17:05 UTC (permalink / raw)
To: dri-devel, intel-gfx; +Cc: Jason Ekstrand, Marcin Slusarz
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
since that commit, we've been having issues where a hang in one client
can propagate to another. In particular, a hang in an app can propagate
to the X server which causes the whole desktop to lock up.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
---
drivers/gpu/drm/i915/i915_request.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index e7b4c4bc41a64..870d6083bb57e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1232,10 +1232,8 @@ i915_request_await_execution(struct i915_request *rq,
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- i915_sw_fence_set_error_once(&rq->submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
- }
if (fence->context == rq->fence.context)
continue;
@@ -1333,10 +1331,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- i915_sw_fence_set_error_once(&rq->submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
- }
/*
* Requests on the same timeline are explicitly ordered, along
--
2.29.2
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
@ 2021-03-05 17:05 ` Jason Ekstrand
0 siblings, 0 replies; 18+ messages in thread
From: Jason Ekstrand @ 2021-03-05 17:05 UTC (permalink / raw)
To: dri-devel, intel-gfx; +Cc: Jason Ekstrand
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
since that commit, we've been having issues where a hang in one client
can propagate to another. In particular, a hang in an app can propagate
to the X server which causes the whole desktop to lock up.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
---
drivers/gpu/drm/i915/i915_request.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index e7b4c4bc41a64..870d6083bb57e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1232,10 +1232,8 @@ i915_request_await_execution(struct i915_request *rq,
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- i915_sw_fence_set_error_once(&rq->submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
- }
if (fence->context == rq->fence.context)
continue;
@@ -1333,10 +1331,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- i915_sw_fence_set_error_once(&rq->submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
- }
/*
* Requests on the same timeline are explicitly ordered, along
--
2.29.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-03-05 17:05 ` [Intel-gfx] " Jason Ekstrand
(?)
@ 2021-03-05 17:21 ` Patchwork
-1 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2021-03-05 17:21 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: intel-gfx
== Series Details ==
Series: Revert "drm/i915: Propagate errors on awaiting already signaled fences"
URL : https://patchwork.freedesktop.org/series/87704/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d9e330a82c56 Revert "drm/i915: Propagate errors on awaiting already signaled fences"
-:44: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Jason Ekstrand <jason@jlekstrand.net>' != 'Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 22 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-03-05 17:05 ` [Intel-gfx] " Jason Ekstrand
@ 2021-03-05 17:49 ` Chris Wilson
-1 siblings, 0 replies; 18+ messages in thread
From: Chris Wilson @ 2021-03-05 17:49 UTC (permalink / raw)
To: Jason Ekstrand, dri-devel, intel-gfx; +Cc: Jason Ekstrand, Marcin Slusarz
Quoting Jason Ekstrand (2021-03-05 17:05:46)
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> since that commit, we've been having issues where a hang in one client
> can propagate to another. In particular, a hang in an app can propagate
> to the X server which causes the whole desktop to lock up.
The fence error handling is required to prevent user's circumventing
incomplete work, such as security validation or escaping isolation.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
@ 2021-03-05 17:49 ` Chris Wilson
0 siblings, 0 replies; 18+ messages in thread
From: Chris Wilson @ 2021-03-05 17:49 UTC (permalink / raw)
To: Jason Ekstrand, dri-devel, intel-gfx; +Cc: Jason Ekstrand
Quoting Jason Ekstrand (2021-03-05 17:05:46)
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> since that commit, we've been having issues where a hang in one client
> can propagate to another. In particular, a hang in an app can propagate
> to the X server which causes the whole desktop to lock up.
The fence error handling is required to prevent user's circumventing
incomplete work, such as security validation or escaping isolation.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-03-05 17:05 ` [Intel-gfx] " Jason Ekstrand
` (2 preceding siblings ...)
(?)
@ 2021-03-05 17:51 ` Patchwork
-1 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2021-03-05 17:51 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 6519 bytes --]
== Series Details ==
Series: Revert "drm/i915: Propagate errors on awaiting already signaled fences"
URL : https://patchwork.freedesktop.org/series/87704/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9836 -> Patchwork_19761
====================================================
Summary
-------
**WARNING**
Minor unknown changes coming with Patchwork_19761 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19761, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_19761:
### IGT changes ###
#### Warnings ####
* igt@gem_linear_blits@basic:
- fi-kbl-8809g: [TIMEOUT][1] ([i915#2502]) -> [TIMEOUT][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/fi-kbl-8809g/igt@gem_linear_blits@basic.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-kbl-8809g/igt@gem_linear_blits@basic.html
Known issues
------------
Here are the changes found in Patchwork_19761 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +23 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-kbl-soraka/igt@gem_exec_fence@basic-busy@bcs0.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html
* igt@gem_tiled_fence_blits@basic:
- fi-kbl-8809g: [PASS][5] -> [TIMEOUT][6] ([i915#3145])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/fi-kbl-8809g/igt@gem_tiled_fence_blits@basic.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-kbl-8809g/igt@gem_tiled_fence_blits@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [PASS][7] -> [DMESG-FAIL][8] ([i915#2291] / [i915#541])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886] / [i915#2291])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@late_gt_pm:
- fi-bsw-nick: [PASS][10] -> [DMESG-FAIL][11] ([i915#2927])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-kbl-soraka/igt@kms_chamelium@common-hpd-after-suspend.html
* igt@kms_frontbuffer_tracking@basic:
- fi-kbl-soraka: NOTRUN -> [FAIL][13] ([i915#49])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-kbl-soraka/igt@kms_frontbuffer_tracking@basic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-kbl-soraka/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@runner@aborted:
- fi-bsw-nick: NOTRUN -> [FAIL][15] ([i915#1436])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-bsw-nick/igt@runner@aborted.html
#### Warnings ####
* igt@gem_tiled_blits@basic:
- fi-kbl-8809g: [TIMEOUT][16] ([i915#3145]) -> [TIMEOUT][17] ([i915#2502] / [i915#3145])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/fi-kbl-8809g/igt@gem_tiled_blits@basic.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-kbl-8809g/igt@gem_tiled_blits@basic.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [DMESG-WARN][18] ([i915#1982] / [i915#3143]) -> [DMESG-WARN][19] ([i915#3143])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/fi-glk-dsi/igt@i915_pm_rpm@module-reload.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/fi-glk-dsi/igt@i915_pm_rpm@module-reload.html
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
[i915#2927]: https://gitlab.freedesktop.org/drm/intel/issues/2927
[i915#3143]: https://gitlab.freedesktop.org/drm/intel/issues/3143
[i915#3145]: https://gitlab.freedesktop.org/drm/intel/issues/3145
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
Participating hosts (43 -> 38)
------------------------------
Additional (1): fi-kbl-soraka
Missing (6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-icl-y fi-bdw-samus fi-snb-2600
Build changes
-------------
* Linux: CI_DRM_9836 -> Patchwork_19761
CI-20190529: 20190529
CI_DRM_9836: 8449e42c5aab6666ce79a2c9f5e75ddd31b9b50e @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6024: d8e03fe437f0c328c96717a92ad97719c02ba2cd @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19761: d9e330a82c566e490c963ebfe6459d91b0a6a9fe @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d9e330a82c56 Revert "drm/i915: Propagate errors on awaiting already signaled fences"
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/index.html
[-- Attachment #1.2: Type: text/html, Size: 7988 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-03-05 17:05 ` [Intel-gfx] " Jason Ekstrand
` (3 preceding siblings ...)
(?)
@ 2021-03-05 21:53 ` Patchwork
-1 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2021-03-05 21:53 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 30294 bytes --]
== Series Details ==
Series: Revert "drm/i915: Propagate errors on awaiting already signaled fences"
URL : https://patchwork.freedesktop.org/series/87704/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9836_full -> Patchwork_19761_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_19761_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19761_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_19761_full:
### IGT changes ###
#### Possible regressions ####
* igt@gen9_exec_parse@basic-rejected:
- shard-skl: NOTRUN -> [FAIL][1] +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl1/igt@gen9_exec_parse@basic-rejected.html
* igt@gen9_exec_parse@batch-without-end:
- shard-apl: [PASS][2] -> [FAIL][3] +3 similar issues
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-apl1/igt@gen9_exec_parse@batch-without-end.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl1/igt@gen9_exec_parse@batch-without-end.html
* igt@gen9_exec_parse@batch-zero-length:
- shard-kbl: [PASS][4] -> [FAIL][5] +6 similar issues
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-kbl3/igt@gen9_exec_parse@batch-zero-length.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl2/igt@gen9_exec_parse@batch-zero-length.html
- shard-glk: [PASS][6] -> [INCOMPLETE][7]
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk9/igt@gen9_exec_parse@batch-zero-length.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk2/igt@gen9_exec_parse@batch-zero-length.html
* igt@gen9_exec_parse@bb-chained:
- shard-glk: [PASS][8] -> [FAIL][9] +7 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk2/igt@gen9_exec_parse@bb-chained.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk9/igt@gen9_exec_parse@bb-chained.html
* igt@gen9_exec_parse@bb-start-out:
- shard-apl: NOTRUN -> [FAIL][10] +1 similar issue
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl1/igt@gen9_exec_parse@bb-start-out.html
* igt@gen9_exec_parse@bb-start-param:
- shard-skl: [PASS][11] -> [TIMEOUT][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl1/igt@gen9_exec_parse@bb-start-param.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl9/igt@gen9_exec_parse@bb-start-param.html
- shard-kbl: [PASS][13] -> [TIMEOUT][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-kbl6/igt@gen9_exec_parse@bb-start-param.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl7/igt@gen9_exec_parse@bb-start-param.html
- shard-glk: [PASS][15] -> [TIMEOUT][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk5/igt@gen9_exec_parse@bb-start-param.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk6/igt@gen9_exec_parse@bb-start-param.html
- shard-apl: [PASS][17] -> [TIMEOUT][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-apl7/igt@gen9_exec_parse@bb-start-param.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl8/igt@gen9_exec_parse@bb-start-param.html
* igt@gen9_exec_parse@valid-registers:
- shard-skl: [PASS][19] -> [FAIL][20] +3 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl6/igt@gen9_exec_parse@valid-registers.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl7/igt@gen9_exec_parse@valid-registers.html
* igt@i915_selftest@live@client:
- shard-skl: [PASS][21] -> [DMESG-FAIL][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl9/igt@i915_selftest@live@client.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl2/igt@i915_selftest@live@client.html
* igt@kms_atomic_transition@plane-all-transition-nonblocking@edp-1-pipe-b:
- shard-iclb: [PASS][23] -> [FAIL][24] +1 similar issue
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb7/igt@kms_atomic_transition@plane-all-transition-nonblocking@edp-1-pipe-b.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb6/igt@kms_atomic_transition@plane-all-transition-nonblocking@edp-1-pipe-b.html
Known issues
------------
Here are the changes found in Patchwork_19761_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_create@create-massive:
- shard-kbl: NOTRUN -> [DMESG-WARN][25] ([i915#3002])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl1/igt@gem_create@create-massive.html
* igt@gem_ctx_persistence@clone:
- shard-snb: NOTRUN -> [SKIP][26] ([fdo#109271] / [i915#1099]) +5 similar issues
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb5/igt@gem_ctx_persistence@clone.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][27] -> [FAIL][28] ([i915#2842]) +2 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-tglb3/igt@gem_exec_fair@basic-flow@rcs0.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-tglb2/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl: [PASS][29] -> [FAIL][30] ([i915#2842])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-kbl4/igt@gem_exec_fair@basic-none-solo@rcs0.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl4/igt@gem_exec_fair@basic-none-solo@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [PASS][31] -> [FAIL][32] ([i915#2842]) +2 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk7/igt@gem_exec_fair@basic-throttle@rcs0.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk9/igt@gem_exec_fair@basic-throttle@rcs0.html
* igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb: NOTRUN -> [FAIL][33] ([i915#2389]) +2 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb5/igt@gem_exec_reloc@basic-wide-active@rcs0.html
* igt@gem_exec_whisper@basic-queues-priority-all:
- shard-glk: [PASS][34] -> [DMESG-WARN][35] ([i915#118] / [i915#95])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk9/igt@gem_exec_whisper@basic-queues-priority-all.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk2/igt@gem_exec_whisper@basic-queues-priority-all.html
* igt@gem_huc_copy@huc-copy:
- shard-kbl: NOTRUN -> [SKIP][36] ([fdo#109271] / [i915#2190])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl1/igt@gem_huc_copy@huc-copy.html
* igt@gem_mmap_gtt@big-copy-xy:
- shard-skl: [PASS][37] -> [FAIL][38] ([i915#307])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl10/igt@gem_mmap_gtt@big-copy-xy.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl6/igt@gem_mmap_gtt@big-copy-xy.html
* igt@gem_mmap_gtt@cpuset-big-copy-odd:
- shard-iclb: [PASS][39] -> [FAIL][40] ([i915#2428])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb3/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb8/igt@gem_mmap_gtt@cpuset-big-copy-odd.html
* igt@gem_mmap_gtt@cpuset-medium-copy-odd:
- shard-iclb: [PASS][41] -> [FAIL][42] ([i915#307])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb4/igt@gem_mmap_gtt@cpuset-medium-copy-odd.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb2/igt@gem_mmap_gtt@cpuset-medium-copy-odd.html
* igt@gem_mmap_offset@clear:
- shard-iclb: [PASS][43] -> [FAIL][44] ([i915#3160])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb4/igt@gem_mmap_offset@clear.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb6/igt@gem_mmap_offset@clear.html
* igt@gem_pread@exhaustion:
- shard-snb: NOTRUN -> [WARN][45] ([i915#2658])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb5/igt@gem_pread@exhaustion.html
* igt@gem_userptr_blits@input-checking:
- shard-snb: NOTRUN -> [DMESG-WARN][46] ([i915#3002])
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb2/igt@gem_userptr_blits@input-checking.html
* igt@gem_userptr_blits@mmap-offset-invalidate-active@wb:
- shard-snb: NOTRUN -> [SKIP][47] ([fdo#109271]) +302 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb5/igt@gem_userptr_blits@mmap-offset-invalidate-active@wb.html
* igt@gem_userptr_blits@process-exit-mmap-busy@wc:
- shard-apl: NOTRUN -> [SKIP][48] ([fdo#109271] / [i915#1699]) +3 similar issues
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl3/igt@gem_userptr_blits@process-exit-mmap-busy@wc.html
* igt@gem_userptr_blits@vma-merge:
- shard-snb: NOTRUN -> [FAIL][49] ([i915#2724])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb5/igt@gem_userptr_blits@vma-merge.html
* igt@gen7_exec_parse@basic-offset:
- shard-skl: NOTRUN -> [SKIP][50] ([fdo#109271]) +86 similar issues
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl4/igt@gen7_exec_parse@basic-offset.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][51] -> [FAIL][52] ([i915#454])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb5/igt@i915_pm_dc@dc6-psr.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb6/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_rpm@modeset-pc8-residency-stress:
- shard-iclb: NOTRUN -> [SKIP][53] ([fdo#109293] / [fdo#109506])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@i915_pm_rpm@modeset-pc8-residency-stress.html
* igt@kms_big_fb@yf-tiled-8bpp-rotate-0:
- shard-iclb: NOTRUN -> [SKIP][54] ([fdo#110723])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_big_fb@yf-tiled-8bpp-rotate-0.html
* igt@kms_big_joiner@invalid-modeset:
- shard-apl: NOTRUN -> [SKIP][55] ([fdo#109271] / [i915#2705])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl6/igt@kms_big_joiner@invalid-modeset.html
* igt@kms_ccs@pipe-c-bad-rotation-90:
- shard-skl: NOTRUN -> [SKIP][56] ([fdo#109271] / [fdo#111304])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl4/igt@kms_ccs@pipe-c-bad-rotation-90.html
* igt@kms_chamelium@hdmi-hpd-storm:
- shard-kbl: NOTRUN -> [SKIP][57] ([fdo#109271] / [fdo#111827]) +11 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl3/igt@kms_chamelium@hdmi-hpd-storm.html
* igt@kms_chamelium@hdmi-hpd-storm-disable:
- shard-skl: NOTRUN -> [SKIP][58] ([fdo#109271] / [fdo#111827]) +9 similar issues
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl4/igt@kms_chamelium@hdmi-hpd-storm-disable.html
- shard-iclb: NOTRUN -> [SKIP][59] ([fdo#109284] / [fdo#111827]) +1 similar issue
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_chamelium@hdmi-hpd-storm-disable.html
* igt@kms_color@pipe-a-ctm-0-75:
- shard-iclb: NOTRUN -> [FAIL][60] ([i915#1149] / [i915#315])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_color@pipe-a-ctm-0-75.html
* igt@kms_color@pipe-a-ctm-max:
- shard-skl: [PASS][61] -> [DMESG-WARN][62] ([i915#1982])
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl8/igt@kms_color@pipe-a-ctm-max.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl9/igt@kms_color@pipe-a-ctm-max.html
* igt@kms_color_chamelium@pipe-a-ctm-limited-range:
- shard-apl: NOTRUN -> [SKIP][63] ([fdo#109271] / [fdo#111827]) +16 similar issues
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl3/igt@kms_color_chamelium@pipe-a-ctm-limited-range.html
* igt@kms_color_chamelium@pipe-invalid-ctm-matrix-sizes:
- shard-snb: NOTRUN -> [SKIP][64] ([fdo#109271] / [fdo#111827]) +20 similar issues
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb5/igt@kms_color_chamelium@pipe-invalid-ctm-matrix-sizes.html
* igt@kms_content_protection@lic:
- shard-apl: NOTRUN -> [TIMEOUT][65] ([i915#1319])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl3/igt@kms_content_protection@lic.html
* igt@kms_cursor_crc@pipe-b-cursor-512x170-offscreen:
- shard-iclb: NOTRUN -> [SKIP][66] ([fdo#109278] / [fdo#109279])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_cursor_crc@pipe-b-cursor-512x170-offscreen.html
* igt@kms_cursor_crc@pipe-d-cursor-64x21-sliding:
- shard-iclb: NOTRUN -> [SKIP][67] ([fdo#109278]) +2 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_cursor_crc@pipe-d-cursor-64x21-sliding.html
* igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic:
- shard-skl: NOTRUN -> [DMESG-FAIL][68] ([IGT#6])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl1/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
- shard-kbl: NOTRUN -> [DMESG-FAIL][69] ([IGT#6])
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl3/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-atomic.html
* igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy:
- shard-apl: NOTRUN -> [DMESG-FAIL][70] ([IGT#6])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl3/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy.html
* igt@kms_cursor_legacy@pipe-d-torture-bo:
- shard-kbl: NOTRUN -> [SKIP][71] ([fdo#109271] / [i915#533])
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl3/igt@kms_cursor_legacy@pipe-d-torture-bo.html
- shard-skl: NOTRUN -> [SKIP][72] ([fdo#109271] / [i915#533])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl1/igt@kms_cursor_legacy@pipe-d-torture-bo.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [PASS][73] -> [INCOMPLETE][74] ([i915#155] / [i915#180] / [i915#636])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-kbl7/igt@kms_fbcon_fbt@fbc-suspend.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl4/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@2x-plain-flip-fb-recreate@ab-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][75] -> [FAIL][76] ([i915#2122])
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk1/igt@kms_flip@2x-plain-flip-fb-recreate@ab-hdmi-a1-hdmi-a2.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk8/igt@kms_flip@2x-plain-flip-fb-recreate@ab-hdmi-a1-hdmi-a2.html
* igt@kms_flip@2x-wf_vblank-ts-check:
- shard-iclb: NOTRUN -> [SKIP][77] ([fdo#109274])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_flip@2x-wf_vblank-ts-check.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-tglb: [PASS][78] -> [FAIL][79] ([i915#2598])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-tglb1/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-tglb6/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
* igt@kms_flip@flip-vs-suspend@b-dp1:
- shard-apl: [PASS][80] -> [DMESG-WARN][81] ([i915#180])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-apl7/igt@kms_flip@flip-vs-suspend@b-dp1.html
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl8/igt@kms_flip@flip-vs-suspend@b-dp1.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile:
- shard-apl: NOTRUN -> [FAIL][82] ([i915#2641])
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl1/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile.html
- shard-skl: NOTRUN -> [FAIL][83] ([i915#2628])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl1/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-pgflip-blt:
- shard-skl: [PASS][84] -> [FAIL][85] ([i915#49])
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl4/igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-pgflip-blt.html
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl5/igt@kms_frontbuffer_tracking@psr-1p-primscrn-shrfb-pgflip-blt.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-shrfb-draw-mmap-wc:
- shard-iclb: NOTRUN -> [SKIP][86] ([fdo#109280]) +4 similar issues
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-shrfb-draw-mmap-wc.html
* igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence:
- shard-apl: NOTRUN -> [SKIP][87] ([fdo#109271] / [i915#533]) +1 similar issue
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl7/igt@kms_pipe_crc_basic@read-crc-pipe-d-frame-sequence.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-kbl: [PASS][88] -> [DMESG-WARN][89] ([i915#180])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-kbl3/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-apl: NOTRUN -> [FAIL][90] ([fdo#108145] / [i915#265]) +1 similar issue
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl6/igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb.html
* igt@kms_plane_alpha_blend@pipe-c-alpha-7efc:
- shard-kbl: NOTRUN -> [FAIL][91] ([fdo#108145] / [i915#265]) +2 similar issues
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl3/igt@kms_plane_alpha_blend@pipe-c-alpha-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: NOTRUN -> [FAIL][92] ([fdo#108145] / [i915#265]) +2 similar issues
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl4/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-3:
- shard-skl: NOTRUN -> [SKIP][93] ([fdo#109271] / [i915#658]) +1 similar issue
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl1/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-3.html
* igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4:
- shard-apl: NOTRUN -> [SKIP][94] ([fdo#109271] / [i915#658]) +7 similar issues
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl3/igt@kms_psr2_sf@overlay-plane-update-sf-dmg-area-4.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-3:
- shard-iclb: NOTRUN -> [SKIP][95] ([i915#658])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-3.html
- shard-kbl: NOTRUN -> [SKIP][96] ([fdo#109271] / [i915#658]) +1 similar issue
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl3/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area-3.html
* igt@kms_psr@psr2_dpms:
- shard-iclb: [PASS][97] -> [SKIP][98] ([fdo#109441])
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb2/igt@kms_psr@psr2_dpms.html
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb3/igt@kms_psr@psr2_dpms.html
* igt@kms_sysfs_edid_timing:
- shard-apl: NOTRUN -> [FAIL][99] ([IGT#2])
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl6/igt@kms_sysfs_edid_timing.html
* igt@kms_universal_plane@disable-primary-vs-flip-pipe-d:
- shard-kbl: NOTRUN -> [SKIP][100] ([fdo#109271]) +80 similar issues
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl1/igt@kms_universal_plane@disable-primary-vs-flip-pipe-d.html
* igt@kms_vblank@pipe-d-ts-continuation-idle:
- shard-apl: NOTRUN -> [SKIP][101] ([fdo#109271]) +163 similar issues
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl7/igt@kms_vblank@pipe-d-ts-continuation-idle.html
* igt@kms_writeback@writeback-check-output:
- shard-apl: NOTRUN -> [SKIP][102] ([fdo#109271] / [i915#2437])
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl3/igt@kms_writeback@writeback-check-output.html
* igt@nouveau_crc@pipe-a-ctx-flip-detection:
- shard-iclb: NOTRUN -> [SKIP][103] ([i915#2530])
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@nouveau_crc@pipe-a-ctx-flip-detection.html
* igt@perf@per-context-mode-unprivileged:
- shard-iclb: NOTRUN -> [SKIP][104] ([fdo#109289]) +1 similar issue
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@perf@per-context-mode-unprivileged.html
* igt@perf@stress-open-close:
- shard-apl: NOTRUN -> [INCOMPLETE][105] ([i915#2369])
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl6/igt@perf@stress-open-close.html
* igt@runner@aborted:
- shard-snb: NOTRUN -> [FAIL][106] ([i915#3002] / [i915#698])
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb2/igt@runner@aborted.html
* igt@sysfs_clients@recycle-many:
- shard-snb: NOTRUN -> [FAIL][107] ([i915#3028])
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb2/igt@sysfs_clients@recycle-many.html
* igt@sysfs_clients@split-10@bcs0:
- shard-kbl: NOTRUN -> [SKIP][108] ([fdo#109271] / [i915#3026])
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl3/igt@sysfs_clients@split-10@bcs0.html
* igt@sysfs_clients@split-10@vcs0:
- shard-skl: NOTRUN -> [SKIP][109] ([fdo#109271] / [i915#3026]) +3 similar issues
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl1/igt@sysfs_clients@split-10@vcs0.html
#### Possible fixes ####
* igt@gem_ctx_persistence@close-replace-race:
- shard-glk: [TIMEOUT][110] ([i915#2918]) -> [PASS][111]
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk7/igt@gem_ctx_persistence@close-replace-race.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk9/igt@gem_ctx_persistence@close-replace-race.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [TIMEOUT][112] ([i915#2369] / [i915#3063]) -> [PASS][113]
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-tglb3/igt@gem_eio@unwedge-stress.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-tglb7/igt@gem_eio@unwedge-stress.html
- shard-skl: [TIMEOUT][114] ([i915#2369] / [i915#2771]) -> [PASS][115]
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl1/igt@gem_eio@unwedge-stress.html
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl2/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: [FAIL][116] ([i915#2846]) -> [PASS][117]
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-kbl6/igt@gem_exec_fair@basic-deadline.html
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl7/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][118] ([i915#2842]) -> [PASS][119]
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk8/igt@gem_exec_fair@basic-pace-share@rcs0.html
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk1/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [FAIL][120] ([i915#2842]) -> [PASS][121]
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-kbl1/igt@gem_exec_fair@basic-pace@vecs0.html
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl4/igt@gem_exec_fair@basic-pace@vecs0.html
* igt@gem_exec_schedule@u-fairslice@rcs0:
- shard-iclb: [DMESG-WARN][122] ([i915#2803]) -> [PASS][123]
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb8/igt@gem_exec_schedule@u-fairslice@rcs0.html
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@gem_exec_schedule@u-fairslice@rcs0.html
* igt@gem_exec_whisper@basic-queues-forked-all:
- shard-glk: [DMESG-WARN][124] ([i915#118] / [i915#95]) -> [PASS][125]
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk7/igt@gem_exec_whisper@basic-queues-forked-all.html
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk5/igt@gem_exec_whisper@basic-queues-forked-all.html
* igt@i915_module_load@reload:
- shard-apl: [DMESG-WARN][126] ([i915#1982]) -> [PASS][127]
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-apl3/igt@i915_module_load@reload.html
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-apl7/igt@i915_module_load@reload.html
* igt@i915_selftest@live@hangcheck:
- shard-snb: [INCOMPLETE][128] ([i915#2782]) -> [PASS][129]
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-snb7/igt@i915_selftest@live@hangcheck.html
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-snb7/igt@i915_selftest@live@hangcheck.html
* igt@kms_async_flips@test-time-stamp:
- shard-tglb: [FAIL][130] ([i915#2597]) -> [PASS][131]
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-tglb8/igt@kms_async_flips@test-time-stamp.html
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-tglb8/igt@kms_async_flips@test-time-stamp.html
* {igt@kms_ccs@pipe-a-random-ccs-data}:
- shard-iclb: [DMESG-WARN][132] -> [PASS][133]
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb1/igt@kms_ccs@pipe-a-random-ccs-data.html
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_ccs@pipe-a-random-ccs-data.html
* igt@kms_cursor_crc@pipe-c-cursor-64x21-random:
- shard-skl: [FAIL][134] ([i915#54]) -> [PASS][135]
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl10/igt@kms_cursor_crc@pipe-c-cursor-64x21-random.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl3/igt@kms_cursor_crc@pipe-c-cursor-64x21-random.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a2:
- shard-glk: [FAIL][136] ([i915#79]) -> [PASS][137]
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-glk9/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a2.html
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a2.html
* igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-kbl: [DMESG-WARN][138] ([i915#180]) -> [PASS][139] +6 similar issues
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-kbl2/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-kbl3/igt@kms_flip@flip-vs-suspend-interruptible@a-dp1.html
* igt@kms_flip@wf_vblank-ts-check@b-edp1:
- shard-skl: [FAIL][140] ([i915#2122]) -> [PASS][141] +1 similar issue
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl10/igt@kms_flip@wf_vblank-ts-check@b-edp1.html
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl6/igt@kms_flip@wf_vblank-ts-check@b-edp1.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-blt:
- shard-iclb: [SKIP][142] ([i915#668]) -> [PASS][143]
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-blt.html
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-iclb4/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-blt.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [FAIL][144] ([i915#1188]) -> [PASS][145]
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-skl7/igt@kms_hdr@bpc-switch-suspend.html
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/shard-skl4/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_psr2_su@page_flip:
- shard-iclb: [SKIP][146] ([fdo#109642] / [fdo#111068] / [i915#658]) -> [PASS][147]
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9836/shard-iclb4/igt@kms_psr
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19761/index.html
[-- Attachment #1.2: Type: text/html, Size: 33569 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-03-05 17:05 ` [Intel-gfx] " Jason Ekstrand
@ 2021-03-11 16:01 ` Daniel Vetter
-1 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-03-11 16:01 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: Jason Ekstrand, intel-gfx, dri-devel
On Fri, Mar 05, 2021 at 11:05:46AM -0600, Jason Ekstrand wrote:
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> since that commit, we've been having issues where a hang in one client
> can propagate to another. In particular, a hang in an app can propagate
> to the X server which causes the whole desktop to lock up.
>
> Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
> Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
Yeah I suggested to just go with the revert, so I guess on my to give you
the explainer to be added to the commit message.
Error propagation along fences sound like a good idea, but as your bug
shows, surprising consequences, since propagating errors across security
boundaries is not a good thing.
What we do have is track the hangs on the ctx, and report information to
userspace using RESET_STATS. That's how arb_robustness works. Also, if my
understanding is still correct, the EIO from execbuf is when your context
is banned (because not recoverable or too many hangs). And in all these
cases it's up to userspace to figure out what is all impacted and should
be reported to the application, that's not on the kernel to guess and
automatically propagate.
What's more, we're also building more features on top of ctx error
reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
userspace fence wait also relies on that mechanism. So it is the path
going forward for reporting gpu hangs and resets to userspace.
So all together that's why I think we should just bury this idea again as
not quite the direction we want to go to, hence why I think the revert is
the right option here.
Maybe quote the entire above thing in the commit message, if it makes some
sense?
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/i915_request.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index e7b4c4bc41a64..870d6083bb57e 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1232,10 +1232,8 @@ i915_request_await_execution(struct i915_request *rq,
>
> do {
> fence = *child++;
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> continue;
> - }
>
> if (fence->context == rq->fence.context)
> continue;
> @@ -1333,10 +1331,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
>
> do {
> fence = *child++;
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> continue;
> - }
>
> /*
> * Requests on the same timeline are explicitly ordered, along
> --
> 2.29.2
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
@ 2021-03-11 16:01 ` Daniel Vetter
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-03-11 16:01 UTC (permalink / raw)
To: Jason Ekstrand; +Cc: Jason Ekstrand, intel-gfx, dri-devel
On Fri, Mar 05, 2021 at 11:05:46AM -0600, Jason Ekstrand wrote:
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> since that commit, we've been having issues where a hang in one client
> can propagate to another. In particular, a hang in an app can propagate
> to the X server which causes the whole desktop to lock up.
>
> Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
> Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
Yeah I suggested to just go with the revert, so I guess on my to give you
the explainer to be added to the commit message.
Error propagation along fences sound like a good idea, but as your bug
shows, surprising consequences, since propagating errors across security
boundaries is not a good thing.
What we do have is track the hangs on the ctx, and report information to
userspace using RESET_STATS. That's how arb_robustness works. Also, if my
understanding is still correct, the EIO from execbuf is when your context
is banned (because not recoverable or too many hangs). And in all these
cases it's up to userspace to figure out what is all impacted and should
be reported to the application, that's not on the kernel to guess and
automatically propagate.
What's more, we're also building more features on top of ctx error
reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
userspace fence wait also relies on that mechanism. So it is the path
going forward for reporting gpu hangs and resets to userspace.
So all together that's why I think we should just bury this idea again as
not quite the direction we want to go to, hence why I think the revert is
the right option here.
Maybe quote the entire above thing in the commit message, if it makes some
sense?
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/i915_request.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index e7b4c4bc41a64..870d6083bb57e 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1232,10 +1232,8 @@ i915_request_await_execution(struct i915_request *rq,
>
> do {
> fence = *child++;
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> continue;
> - }
>
> if (fence->context == rq->fence.context)
> continue;
> @@ -1333,10 +1331,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
>
> do {
> fence = *child++;
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> continue;
> - }
>
> /*
> * Requests on the same timeline are explicitly ordered, along
> --
> 2.29.2
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-03-11 16:01 ` Daniel Vetter
@ 2021-03-11 16:17 ` Chris Wilson
-1 siblings, 0 replies; 18+ messages in thread
From: Chris Wilson @ 2021-03-11 16:17 UTC (permalink / raw)
To: Daniel Vetter, Jason Ekstrand; +Cc: Jason Ekstrand, intel-gfx, dri-devel
Quoting Daniel Vetter (2021-03-11 16:01:46)
> On Fri, Mar 05, 2021 at 11:05:46AM -0600, Jason Ekstrand wrote:
> > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> > since that commit, we've been having issues where a hang in one client
> > can propagate to another. In particular, a hang in an app can propagate
> > to the X server which causes the whole desktop to lock up.
> >
> > Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
> > Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
>
> Yeah I suggested to just go with the revert, so I guess on my to give you
> the explainer to be added to the commit message.
If you took the patch this was copied from and only revert on the
dma-resv, things do not break horribly.
> Error propagation along fences sound like a good idea, but as your bug
> shows, surprising consequences, since propagating errors across security
> boundaries is not a good thing.
>
> What we do have is track the hangs on the ctx, and report information to
> userspace using RESET_STATS.
And by the fence, which is far more precise.
> That's how arb_robustness works. Also, if my
> understanding is still correct, the EIO from execbuf is when your context
> is banned (because not recoverable or too many hangs). And in all these
> cases it's up to userspace to figure out what is all impacted and should
> be reported to the application, that's not on the kernel to guess and
> automatically propagate.
>
> What's more, we're also building more features on top of ctx error
> reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
> userspace fence wait also relies on that mechanism. So it is the path
> going forward for reporting gpu hangs and resets to userspace.
That ioctl is not a solid basis, it never did quite work as expected and
we kept realising the limitations of the information and the accuracy
that it could report.
> So all together that's why I think we should just bury this idea again as
> not quite the direction we want to go to, hence why I think the revert is
> the right option here.
No, as shown by igt it's a critical issue that we have to judicially
chose which errors to ignore. And it's not just the ability to subvert
gen7 and gen9, it's the error tracking employed for preempting contexts
among others. Hence go with the original patch to undo the propagation
along dma-resv.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
@ 2021-03-11 16:17 ` Chris Wilson
0 siblings, 0 replies; 18+ messages in thread
From: Chris Wilson @ 2021-03-11 16:17 UTC (permalink / raw)
To: Daniel Vetter, Jason Ekstrand; +Cc: Jason Ekstrand, intel-gfx, dri-devel
Quoting Daniel Vetter (2021-03-11 16:01:46)
> On Fri, Mar 05, 2021 at 11:05:46AM -0600, Jason Ekstrand wrote:
> > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> > since that commit, we've been having issues where a hang in one client
> > can propagate to another. In particular, a hang in an app can propagate
> > to the X server which causes the whole desktop to lock up.
> >
> > Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
> > Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
>
> Yeah I suggested to just go with the revert, so I guess on my to give you
> the explainer to be added to the commit message.
If you took the patch this was copied from and only revert on the
dma-resv, things do not break horribly.
> Error propagation along fences sound like a good idea, but as your bug
> shows, surprising consequences, since propagating errors across security
> boundaries is not a good thing.
>
> What we do have is track the hangs on the ctx, and report information to
> userspace using RESET_STATS.
And by the fence, which is far more precise.
> That's how arb_robustness works. Also, if my
> understanding is still correct, the EIO from execbuf is when your context
> is banned (because not recoverable or too many hangs). And in all these
> cases it's up to userspace to figure out what is all impacted and should
> be reported to the application, that's not on the kernel to guess and
> automatically propagate.
>
> What's more, we're also building more features on top of ctx error
> reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
> userspace fence wait also relies on that mechanism. So it is the path
> going forward for reporting gpu hangs and resets to userspace.
That ioctl is not a solid basis, it never did quite work as expected and
we kept realising the limitations of the information and the accuracy
that it could report.
> So all together that's why I think we should just bury this idea again as
> not quite the direction we want to go to, hence why I think the revert is
> the right option here.
No, as shown by igt it's a critical issue that we have to judicially
chose which errors to ignore. And it's not just the ability to subvert
gen7 and gen9, it's the error tracking employed for preempting contexts
among others. Hence go with the original patch to undo the propagation
along dma-resv.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-05-19 17:16 ` Daniel Vetter
(?)
@ 2021-05-19 19:01 ` Jason Ekstrand
-1 siblings, 0 replies; 18+ messages in thread
From: Jason Ekstrand @ 2021-05-19 19:01 UTC (permalink / raw)
To: Daniel Vetter
Cc: Intel Graphics Development, stable, Jason Ekstrand,
Jon Bloomfield, DRI Development, Marcin Slusarz
[-- Attachment #1: Type: text/plain, Size: 4342 bytes --]
On May 19, 2021 12:16:15 Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Wed, May 19, 2021 at 5:06 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>>
>> Once we no longer rely on error propagation, I think there's a lot we
>> can rip out.
>
> I honestly did not find that much ... what did you uncover?
When I was digging through this earlier today, I think I convinced myself
that the cmdparser is the only user of the entire fence error architecture.
I may have missed something, though.
--Jason
>
> -Daniel
>
>>
>> --Jason
>>
>> On Wed, May 19, 2021 at 5:15 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>>>
>>> From: Jason Ekstrand <jason@jlekstrand.net>
>>>
>>> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
>>> since that commit, we've been having issues where a hang in one client
>>> can propagate to another. In particular, a hang in an app can propagate
>>> to the X server which causes the whole desktop to lock up.
>>>
>>> Error propagation along fences sound like a good idea, but as your bug
>>> shows, surprising consequences, since propagating errors across security
>>> boundaries is not a good thing.
>>>
>>> What we do have is track the hangs on the ctx, and report information to
>>> userspace using RESET_STATS. That's how arb_robustness works. Also, if my
>>> understanding is still correct, the EIO from execbuf is when your context
>>> is banned (because not recoverable or too many hangs). And in all these
>>> cases it's up to userspace to figure out what is all impacted and should
>>> be reported to the application, that's not on the kernel to guess and
>>> automatically propagate.
>>>
>>> What's more, we're also building more features on top of ctx error
>>> reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
>>> userspace fence wait also relies on that mechanism. So it is the path
>>> going forward for reporting gpu hangs and resets to userspace.
>>>
>>> So all together that's why I think we should just bury this idea again as
>>> not quite the direction we want to go to, hence why I think the revert is
>>> the right option here.Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
>>>
>>> v2: Augment commit message. Also restore Jason's sob that I
>>> accidentally lost.
>>>
>>> Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> (v1)
>>> Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
>>> Cc: <stable@vger.kernel.org> # v5.6+
>>> Cc: Jason Ekstrand <jason.ekstrand@intel.com>
>>> Cc: Marcin Slusarz <marcin.slusarz@intel.com>
>>> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
>>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
>>> Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already
>>> signaled fences")
>>> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>> ---
>>> drivers/gpu/drm/i915/i915_request.c | 8 ++------
>>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_request.c
>>> b/drivers/gpu/drm/i915/i915_request.c
>>> index 970d8f4986bb..b796197c0772 100644
>>> --- a/drivers/gpu/drm/i915/i915_request.c
>>> +++ b/drivers/gpu/drm/i915/i915_request.c
>>> @@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq,
>>>
>>> do {
>>> fence = *child++;
>>> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
>>> - i915_sw_fence_set_error_once(&rq->submit,
>>> fence->error);
>>> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
>>> continue;
>>> - }
>>>
>>> if (fence->context == rq->fence.context)
>>> continue;
>>> @@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request
>>> *rq, struct dma_fence *fence)
>>>
>>> do {
>>> fence = *child++;
>>> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
>>> - i915_sw_fence_set_error_once(&rq->submit,
>>> fence->error);
>>> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
>>> continue;
>>> - }
>>>
>>> /*
>>> * Requests on the same timeline are explicitly ordered, along
>>> --
>>> 2.31.0
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
[-- Attachment #2: Type: text/html, Size: 8249 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-05-19 15:06 ` Jason Ekstrand
@ 2021-05-19 17:16 ` Daniel Vetter
-1 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-05-19 17:16 UTC (permalink / raw)
To: Jason Ekstrand
Cc: Intel Graphics Development, DRI Development, Jason Ekstrand,
Marcin Slusarz, stable, Jon Bloomfield
On Wed, May 19, 2021 at 5:06 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> Once we no longer rely on error propagation, I think there's a lot we
> can rip out.
I honestly did not find that much ... what did you uncover?
-Daniel
>
> --Jason
>
> On Wed, May 19, 2021 at 5:15 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > From: Jason Ekstrand <jason@jlekstrand.net>
> >
> > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> > since that commit, we've been having issues where a hang in one client
> > can propagate to another. In particular, a hang in an app can propagate
> > to the X server which causes the whole desktop to lock up.
> >
> > Error propagation along fences sound like a good idea, but as your bug
> > shows, surprising consequences, since propagating errors across security
> > boundaries is not a good thing.
> >
> > What we do have is track the hangs on the ctx, and report information to
> > userspace using RESET_STATS. That's how arb_robustness works. Also, if my
> > understanding is still correct, the EIO from execbuf is when your context
> > is banned (because not recoverable or too many hangs). And in all these
> > cases it's up to userspace to figure out what is all impacted and should
> > be reported to the application, that's not on the kernel to guess and
> > automatically propagate.
> >
> > What's more, we're also building more features on top of ctx error
> > reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
> > userspace fence wait also relies on that mechanism. So it is the path
> > going forward for reporting gpu hangs and resets to userspace.
> >
> > So all together that's why I think we should just bury this idea again as
> > not quite the direction we want to go to, hence why I think the revert is
> > the right option here.Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
> >
> > v2: Augment commit message. Also restore Jason's sob that I
> > accidentally lost.
> >
> > Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> (v1)
> > Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
> > Cc: <stable@vger.kernel.org> # v5.6+
> > Cc: Jason Ekstrand <jason.ekstrand@intel.com>
> > Cc: Marcin Slusarz <marcin.slusarz@intel.com>
> > Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index 970d8f4986bb..b796197c0772 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq,
> >
> > do {
> > fence = *child++;
> > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> > - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> > continue;
> > - }
> >
> > if (fence->context == rq->fence.context)
> > continue;
> > @@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
> >
> > do {
> > fence = *child++;
> > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> > - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> > continue;
> > - }
> >
> > /*
> > * Requests on the same timeline are explicitly ordered, along
> > --
> > 2.31.0
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
@ 2021-05-19 17:16 ` Daniel Vetter
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-05-19 17:16 UTC (permalink / raw)
To: Jason Ekstrand
Cc: Intel Graphics Development, stable, Jason Ekstrand,
Jon Bloomfield, DRI Development, Marcin Slusarz
On Wed, May 19, 2021 at 5:06 PM Jason Ekstrand <jason@jlekstrand.net> wrote:
>
> Once we no longer rely on error propagation, I think there's a lot we
> can rip out.
I honestly did not find that much ... what did you uncover?
-Daniel
>
> --Jason
>
> On Wed, May 19, 2021 at 5:15 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >
> > From: Jason Ekstrand <jason@jlekstrand.net>
> >
> > This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> > since that commit, we've been having issues where a hang in one client
> > can propagate to another. In particular, a hang in an app can propagate
> > to the X server which causes the whole desktop to lock up.
> >
> > Error propagation along fences sound like a good idea, but as your bug
> > shows, surprising consequences, since propagating errors across security
> > boundaries is not a good thing.
> >
> > What we do have is track the hangs on the ctx, and report information to
> > userspace using RESET_STATS. That's how arb_robustness works. Also, if my
> > understanding is still correct, the EIO from execbuf is when your context
> > is banned (because not recoverable or too many hangs). And in all these
> > cases it's up to userspace to figure out what is all impacted and should
> > be reported to the application, that's not on the kernel to guess and
> > automatically propagate.
> >
> > What's more, we're also building more features on top of ctx error
> > reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
> > userspace fence wait also relies on that mechanism. So it is the path
> > going forward for reporting gpu hangs and resets to userspace.
> >
> > So all together that's why I think we should just bury this idea again as
> > not quite the direction we want to go to, hence why I think the revert is
> > the right option here.Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
> >
> > v2: Augment commit message. Also restore Jason's sob that I
> > accidentally lost.
> >
> > Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> (v1)
> > Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
> > Cc: <stable@vger.kernel.org> # v5.6+
> > Cc: Jason Ekstrand <jason.ekstrand@intel.com>
> > Cc: Marcin Slusarz <marcin.slusarz@intel.com>
> > Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> > Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> > index 970d8f4986bb..b796197c0772 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq,
> >
> > do {
> > fence = *child++;
> > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> > - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> > continue;
> > - }
> >
> > if (fence->context == rq->fence.context)
> > continue;
> > @@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
> >
> > do {
> > fence = *child++;
> > - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> > - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> > + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> > continue;
> > - }
> >
> > /*
> > * Requests on the same timeline are explicitly ordered, along
> > --
> > 2.31.0
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-05-19 10:15 ` Daniel Vetter
@ 2021-05-19 15:06 ` Jason Ekstrand
-1 siblings, 0 replies; 18+ messages in thread
From: Jason Ekstrand @ 2021-05-19 15:06 UTC (permalink / raw)
To: Daniel Vetter
Cc: Intel Graphics Development, DRI Development, Jason Ekstrand,
Marcin Slusarz, stable, Jon Bloomfield
Once we no longer rely on error propagation, I think there's a lot we
can rip out.
--Jason
On Wed, May 19, 2021 at 5:15 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> From: Jason Ekstrand <jason@jlekstrand.net>
>
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> since that commit, we've been having issues where a hang in one client
> can propagate to another. In particular, a hang in an app can propagate
> to the X server which causes the whole desktop to lock up.
>
> Error propagation along fences sound like a good idea, but as your bug
> shows, surprising consequences, since propagating errors across security
> boundaries is not a good thing.
>
> What we do have is track the hangs on the ctx, and report information to
> userspace using RESET_STATS. That's how arb_robustness works. Also, if my
> understanding is still correct, the EIO from execbuf is when your context
> is banned (because not recoverable or too many hangs). And in all these
> cases it's up to userspace to figure out what is all impacted and should
> be reported to the application, that's not on the kernel to guess and
> automatically propagate.
>
> What's more, we're also building more features on top of ctx error
> reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
> userspace fence wait also relies on that mechanism. So it is the path
> going forward for reporting gpu hangs and resets to userspace.
>
> So all together that's why I think we should just bury this idea again as
> not quite the direction we want to go to, hence why I think the revert is
> the right option here.Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
>
> v2: Augment commit message. Also restore Jason's sob that I
> accidentally lost.
>
> Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> (v1)
> Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
> Cc: <stable@vger.kernel.org> # v5.6+
> Cc: Jason Ekstrand <jason.ekstrand@intel.com>
> Cc: Marcin Slusarz <marcin.slusarz@intel.com>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/i915/i915_request.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index 970d8f4986bb..b796197c0772 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq,
>
> do {
> fence = *child++;
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> continue;
> - }
>
> if (fence->context == rq->fence.context)
> continue;
> @@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
>
> do {
> fence = *child++;
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> continue;
> - }
>
> /*
> * Requests on the same timeline are explicitly ordered, along
> --
> 2.31.0
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
@ 2021-05-19 15:06 ` Jason Ekstrand
0 siblings, 0 replies; 18+ messages in thread
From: Jason Ekstrand @ 2021-05-19 15:06 UTC (permalink / raw)
To: Daniel Vetter
Cc: Intel Graphics Development, stable, Jason Ekstrand,
Jon Bloomfield, DRI Development, Marcin Slusarz
Once we no longer rely on error propagation, I think there's a lot we
can rip out.
--Jason
On Wed, May 19, 2021 at 5:15 AM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> From: Jason Ekstrand <jason@jlekstrand.net>
>
> This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
> since that commit, we've been having issues where a hang in one client
> can propagate to another. In particular, a hang in an app can propagate
> to the X server which causes the whole desktop to lock up.
>
> Error propagation along fences sound like a good idea, but as your bug
> shows, surprising consequences, since propagating errors across security
> boundaries is not a good thing.
>
> What we do have is track the hangs on the ctx, and report information to
> userspace using RESET_STATS. That's how arb_robustness works. Also, if my
> understanding is still correct, the EIO from execbuf is when your context
> is banned (because not recoverable or too many hangs). And in all these
> cases it's up to userspace to figure out what is all impacted and should
> be reported to the application, that's not on the kernel to guess and
> automatically propagate.
>
> What's more, we're also building more features on top of ctx error
> reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
> userspace fence wait also relies on that mechanism. So it is the path
> going forward for reporting gpu hangs and resets to userspace.
>
> So all together that's why I think we should just bury this idea again as
> not quite the direction we want to go to, hence why I think the revert is
> the right option here.Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
>
> v2: Augment commit message. Also restore Jason's sob that I
> accidentally lost.
>
> Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> (v1)
> Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
> Cc: <stable@vger.kernel.org> # v5.6+
> Cc: Jason Ekstrand <jason.ekstrand@intel.com>
> Cc: Marcin Slusarz <marcin.slusarz@intel.com>
> Cc: Jon Bloomfield <jon.bloomfield@intel.com>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
> Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/i915/i915_request.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index 970d8f4986bb..b796197c0772 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq,
>
> do {
> fence = *child++;
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> continue;
> - }
>
> if (fence->context == rq->fence.context)
> continue;
> @@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
>
> do {
> fence = *child++;
> - if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
> - i915_sw_fence_set_error_once(&rq->submit, fence->error);
> + if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
> continue;
> - }
>
> /*
> * Requests on the same timeline are explicitly ordered, along
> --
> 2.31.0
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
2021-05-19 7:43 [PATCH 2/2] " Daniel Vetter
@ 2021-05-19 10:15 ` Daniel Vetter
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-05-19 10:15 UTC (permalink / raw)
To: Intel Graphics Development, DRI Development
Cc: Jason Ekstrand, Jason Ekstrand, Marcin Slusarz, stable,
Jon Bloomfield, Daniel Vetter
From: Jason Ekstrand <jason@jlekstrand.net>
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
since that commit, we've been having issues where a hang in one client
can propagate to another. In particular, a hang in an app can propagate
to the X server which causes the whole desktop to lock up.
Error propagation along fences sound like a good idea, but as your bug
shows, surprising consequences, since propagating errors across security
boundaries is not a good thing.
What we do have is track the hangs on the ctx, and report information to
userspace using RESET_STATS. That's how arb_robustness works. Also, if my
understanding is still correct, the EIO from execbuf is when your context
is banned (because not recoverable or too many hangs). And in all these
cases it's up to userspace to figure out what is all impacted and should
be reported to the application, that's not on the kernel to guess and
automatically propagate.
What's more, we're also building more features on top of ctx error
reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
userspace fence wait also relies on that mechanism. So it is the path
going forward for reporting gpu hangs and resets to userspace.
So all together that's why I think we should just bury this idea again as
not quite the direction we want to go to, hence why I think the revert is
the right option here.Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
v2: Augment commit message. Also restore Jason's sob that I
accidentally lost.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> (v1)
Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
Cc: <stable@vger.kernel.org> # v5.6+
Cc: Jason Ekstrand <jason.ekstrand@intel.com>
Cc: Marcin Slusarz <marcin.slusarz@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/i915/i915_request.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 970d8f4986bb..b796197c0772 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq,
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- i915_sw_fence_set_error_once(&rq->submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
- }
if (fence->context == rq->fence.context)
continue;
@@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- i915_sw_fence_set_error_once(&rq->submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
- }
/*
* Requests on the same timeline are explicitly ordered, along
--
2.31.0
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences"
@ 2021-05-19 10:15 ` Daniel Vetter
0 siblings, 0 replies; 18+ messages in thread
From: Daniel Vetter @ 2021-05-19 10:15 UTC (permalink / raw)
To: Intel Graphics Development, DRI Development
Cc: Daniel Vetter, stable, Jason Ekstrand, Jon Bloomfield,
Jason Ekstrand, Marcin Slusarz
From: Jason Ekstrand <jason@jlekstrand.net>
This reverts commit 9e31c1fe45d555a948ff66f1f0e3fe1f83ca63f7. Ever
since that commit, we've been having issues where a hang in one client
can propagate to another. In particular, a hang in an app can propagate
to the X server which causes the whole desktop to lock up.
Error propagation along fences sound like a good idea, but as your bug
shows, surprising consequences, since propagating errors across security
boundaries is not a good thing.
What we do have is track the hangs on the ctx, and report information to
userspace using RESET_STATS. That's how arb_robustness works. Also, if my
understanding is still correct, the EIO from execbuf is when your context
is banned (because not recoverable or too many hangs). And in all these
cases it's up to userspace to figure out what is all impacted and should
be reported to the application, that's not on the kernel to guess and
automatically propagate.
What's more, we're also building more features on top of ctx error
reporting with RESET_STATS ioctl: Encrypted buffers use the same, and the
userspace fence wait also relies on that mechanism. So it is the path
going forward for reporting gpu hangs and resets to userspace.
So all together that's why I think we should just bury this idea again as
not quite the direction we want to go to, hence why I think the revert is
the right option here.Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
v2: Augment commit message. Also restore Jason's sob that I
accidentally lost.
Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com> (v1)
Reported-by: Marcin Slusarz <marcin.slusarz@intel.com>
Cc: <stable@vger.kernel.org> # v5.6+
Cc: Jason Ekstrand <jason.ekstrand@intel.com>
Cc: Marcin Slusarz <marcin.slusarz@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3080
Fixes: 9e31c1fe45d5 ("drm/i915: Propagate errors on awaiting already signaled fences")
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/i915/i915_request.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 970d8f4986bb..b796197c0772 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1426,10 +1426,8 @@ i915_request_await_execution(struct i915_request *rq,
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- i915_sw_fence_set_error_once(&rq->submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
- }
if (fence->context == rq->fence.context)
continue;
@@ -1527,10 +1525,8 @@ i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
do {
fence = *child++;
- if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) {
- i915_sw_fence_set_error_once(&rq->submit, fence->error);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
continue;
- }
/*
* Requests on the same timeline are explicitly ordered, along
--
2.31.0
^ permalink raw reply related [flat|nested] 18+ messages in thread
end of thread, other threads:[~2021-05-19 19:01 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-05 17:05 [PATCH] Revert "drm/i915: Propagate errors on awaiting already signaled fences" Jason Ekstrand
2021-03-05 17:05 ` [Intel-gfx] " Jason Ekstrand
2021-03-05 17:21 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2021-03-05 17:49 ` [PATCH] " Chris Wilson
2021-03-05 17:49 ` [Intel-gfx] " Chris Wilson
2021-03-05 17:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2021-03-05 21:53 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-03-11 16:01 ` [Intel-gfx] [PATCH] " Daniel Vetter
2021-03-11 16:01 ` Daniel Vetter
2021-03-11 16:17 ` Chris Wilson
2021-03-11 16:17 ` Chris Wilson
2021-05-19 7:43 [PATCH 2/2] " Daniel Vetter
2021-05-19 10:15 ` [PATCH] " Daniel Vetter
2021-05-19 10:15 ` Daniel Vetter
2021-05-19 15:06 ` Jason Ekstrand
2021-05-19 15:06 ` Jason Ekstrand
2021-05-19 17:16 ` Daniel Vetter
2021-05-19 17:16 ` Daniel Vetter
2021-05-19 19:01 ` Jason Ekstrand
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.