Re: ✗ i915.CI.Full: failure for drm/i915/display: stop using the configurable fence timeout (rev2)

Maarten Lankhorst
2026-04-02T15:41:59Z

[-- Attachment #1: Type: text/plain, Size: 4654 bytes --]

Den 2026-04-02 kl. 11:40, skrev Jani Nikula:
> On Wed, 03 Dec 2025, Maarten Lankhorst <maarten.lankhorst@intel.com> wrote:
>> Hey,
>>
>> Den 2025-11-25 kl. 18:24, skrev Ville Syrjälä:
>>> On Tue, Nov 25, 2025 at 03:55:02PM +0200, Jani Nikula wrote:
>>>> On Fri, 14 Nov 2025, Patchwork <patchwork@emeril.freedesktop.org> wrote:
>>>>> == Series Details ==
>>>>>
>>>>> Series: drm/i915/display: stop using the configurable fence timeout (rev2)
>>>>> URL : https://patchwork.freedesktop.org/series/157441/
>>>>> State : failure
>>>>>
>>>>> == Summary ==
>>>>>
>>>>> CI Bug Log - changes from CI_DRM_17544_full -> Patchwork_157441v2_full
>>>>> ====================================================
>>>>>
>>>>> Summary
>>>>> -------
>>>>>
>>>>> **FAILURE**
>>>>>
>>>>> Serious unknown changes coming with Patchwork_157441v2_full absolutely need to be
>>>>> verified manually.
>>>>>
>>>>> If you think the reported changes have nothing to do with the changes
>>>>> introduced in Patchwork_157441v2_full, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
>>>>> to document this new failure mode, which will reduce false positives in CI.
>>>>>
>>>>>
>>>>>
>>>>> Participating hosts (10 -> 11)
>>>>> ------------------------------
>>>>>
>>>>> Additional (1): shard-dg2-set2
>>>>>
>>>>> Possible new issues
>>>>> -------------------
>>>>>
>>>>> Here are the unknown changes that may have been introduced in Patchwork_157441v2_full:
>>>>>
>>>>> ### IGT changes ###
>>>>>
>>>>> #### Possible regressions ####
>>>>>
>>>>> * igt@kms_busy@extended-modeset-hang-newfb-with-reset@pipe-a:
>>>>> - shard-mtlp: [PASS][1] -> [DMESG-WARN][2] +5 other tests dmesg-warn
>>>>> [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17544/shard-mtlp-7/igt@kms_busy@extended-modeset-hang-newfb-with-reset@pipe-a.html
>>>>> [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_157441v2/shard-mtlp-3/igt@kms_busy@extended-modeset-hang-newfb-with-reset@pipe-a.html
>>>>>
>>>>> * igt@kms_busy@extended-modeset-hang-newfb-with-reset@pipe-b:
>>>>> - shard-snb: [PASS][3] -> [DMESG-WARN][4] +3 other tests dmesg-warn
>>>>> [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17544/shard-snb5/igt@kms_busy@extended-modeset-hang-newfb-with-reset@pipe-b.html
>>>>> [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_157441v2/shard-snb7/igt@kms_busy@extended-modeset-hang-newfb-with-reset@pipe-b.html
>>>>>
>>>>> * igt@kms_busy@extended-modeset-hang-newfb-with-reset@pipe-d:
>>>>> - shard-dg2: [PASS][5] -> [DMESG-WARN][6] +5 other tests dmesg-warn
>>>>> [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17544/shard-dg2-6/igt@kms_busy@extended-modeset-hang-newfb-with-reset@pipe-d.html
>>>>> [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_157441v2/shard-dg2-5/igt@kms_busy@extended-modeset-hang-newfb-with-reset@pipe-d.html
>>>>>
>>>>> * igt@kms_busy@extended-modeset-hang-oldfb-with-reset:
>>>>> - shard-dg1: [PASS][7] -> [DMESG-WARN][8] +2 other tests dmesg-warn
>>>>> [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17544/shard-dg1-12/igt@kms_busy@extended-modeset-hang-oldfb-with-reset.html
>>>>> [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_157441v2/shard-dg1-18/igt@kms_busy@extended-modeset-hang-oldfb-with-reset.html
>>>> Maarten, Ville, any ideas what to do about these?
>>> Looks like we need the timeout to unbreak the modeset vs. reset
>>> deadlock in a timely fashion.
>>>
>>> I'm not where we signal/error the fences the modeset is waiting
>>> for, but I guess that must be happening after the whole reset
>>> sequence is done. Doing that earlier would seem like another
>>> solution, but dunno what other fallout it would have.
>> intel_prepare_plane_fb() adds all dma-resv fences for old_obj on
>> intel_crtc_needs_modeset(), does it change anything if we remove that,
>> at least for the GPU reset commit?
> We dropped the ball here a bit, and I'm a bit clueless as to what to
> do. Except we'll need to unify i915 and xe here somehow.
>
> Alternatives:
>
> - Remove the timeout from i915 (the patch at hand), and fix the fallout
> somehow.
>
> - Add the timeout to xe, and fix the fallout, if any.
>
> - Add the timeout to display parent interface, which is a bit meh.
>
>
The mention in the commit is old_obj needs to be wait for flip_done, I do not believe this
is the case that it was ever used in hardware supported by xe, so for xe the wait can be dropped entirely.

Is this required for i915 still? In that case you can just eliminate the wait only for xe.

Kind regards,
~Maarten Lankhorst

[-- Attachment #2: Type: text/html, Size: 7107 bytes --]