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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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.

-- 
Ville Syrjälä
Intel