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

Maarten Lankhorst
2025-12-03T10:48:57Z

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?

Kind regards,
~Maarten Lankhorst