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

Ville Syrjälä
2025-11-25T17:24:43Z

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