On Tue, Nov 25, 2025 at 03:55:02PM +0200, Jani Nikula wrote: > On Fri, 14 Nov 2025, Patchwork <[email protected]> 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 > > ([email protected]) 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@[email protected] > > [2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_157441v2/shard-mtlp-3/igt@kms_busy@[email protected] > > > > * 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@[email protected] > > [4]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_157441v2/shard-snb7/igt@kms_busy@[email protected] > > > > * 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@[email protected] > > [6]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_157441v2/shard-dg2-5/igt@kms_busy@[email protected] > > > > * 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@[email protected] > > [8]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_157441v2/shard-dg1-18/igt@[email protected] > > 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
