On 05/06/2023 16:06, Jani Nikula wrote:
On Wed, 31 May 2023, Patchwork <patchw...@emeril.freedesktop.org> wrote:
#### Possible regressions ####
* igt@gem_close_race@basic-process:
- fi-blb-e6850: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13203/fi-blb-e6850/igt@gem_close_r...@basic-process.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v3/fi-blb-e6850/igt@gem_close_r...@basic-process.html
- fi-hsw-4770: [PASS][3] -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13203/fi-hsw-4770/igt@gem_close_r...@basic-process.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v3/fi-hsw-4770/igt@gem_close_r...@basic-process.html
- fi-elk-e7500: [PASS][5] -> [ABORT][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13203/fi-elk-e7500/igt@gem_close_r...@basic-process.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v3/fi-elk-e7500/igt@gem_close_r...@basic-process.html
* igt@i915_selftest@live@evict:
- bat-adlp-9: [PASS][7] -> [ABORT][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13203/bat-adlp-9/igt@i915_selftest@l...@evict.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v3/bat-adlp-9/igt@i915_selftest@l...@evict.html
- bat-rpls-2: [PASS][9] -> [ABORT][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13203/bat-rpls-2/igt@i915_selftest@l...@evict.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v3/bat-rpls-2/igt@i915_selftest@l...@evict.html
- bat-adlm-1: [PASS][11] -> [ABORT][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13203/bat-adlm-1/igt@i915_selftest@l...@evict.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v3/bat-adlm-1/igt@i915_selftest@l...@evict.html
- bat-rpls-1: [PASS][13] -> [ABORT][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13203/bat-rpls-1/igt@i915_selftest@l...@evict.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117618v3/bat-rpls-1/igt@i915_selftest@l...@evict.html
This still fails consistently, I have no clue why, and the above aren't
even remotely related to display.
What now? Tvrtko?
Hmm..
<4> [46.782321] Chain exists of:
(wq_completion)i915 --> (work_completion)(&i915->mm.free_work) --> &vm->mutex
<4> [46.782329] Possible unsafe locking scenario:
<4> [46.782332] CPU0 CPU1
<4> [46.782334] ---- ----
<4> [46.782337] lock(&vm->mutex);
<4> [46.782340]
lock((work_completion)(&i915->mm.free_work));
<4> [46.782344] lock(&vm->mutex);
<4> [46.782348] lock((wq_completion)i915);
"(wq_completion)i915"
So it's not about the new wq even. Perhaps it is this hunk:
--- a/drivers/gpu/drm/i915/intel_wakeref.c
+++ b/drivers/gpu/drm/i915/intel_wakeref.c
@@ -75,7 +75,7 @@ void __intel_wakeref_put_last(struct intel_wakeref *wf,
unsigned long flags)
/* Assume we are not in process context and so cannot sleep. */
if (flags & INTEL_WAKEREF_PUT_ASYNC || !mutex_trylock(&wf->mutex)) {
- mod_delayed_work(system_wq, &wf->work,
+ mod_delayed_work(wf->i915->wq, &wf->work,
Transformation from this patch otherwise is system_wq with the new unordered
wq, so I'd try that first.
Regards,
Tvrtko
