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

[Jani Nikula <jani.nikula@intel.com>]

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.


BR,
Jani.


-- 
Jani Nikula, Intel