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 <[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. 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
