Hi,
> -----Original Message-----
> From: Nikula, Jani <jani.nik...@intel.com>
> Sent: tiistai 28. helmikuuta 2023 16.40
> To: Andi Shyti <andi.sh...@linux.intel.com>
> Cc: Andi Shyti <andi.sh...@linux.intel.com>; Dmitry Osipenko
> <dmitry.osipe...@collabora.com>; dri-de...@lists.freedesktop.org; Maarten
> Lankhorst <maarten.lankho...@linux.intel.com>; Maxime Ripard
> <mrip...@kernel.org>; Thomas Zimmermann <tzimmerm...@suse.de>; David
> Airlie <airl...@gmail.com>; Daniel Vetter <dan...@ffwll.ch>; Javier Martinez
> Canillas <javi...@redhat.com>; Asahi Lina <l...@asahilina.net>; Andi Shyti
> <a...@etezian.org>; Intel GFX <intel-gfx@lists.freedesktop.org>; Tvrtko
> Ursulin
> <tvrtko.ursu...@linux.intel.com>; Vivi, Rodrigo <rodrigo.v...@intel.com>;
> Joonas
> Lahtinen <joonas.lahti...@linux.intel.com>; Saarinen, Jani
> <jani.saari...@intel.com>
> Subject: Re: [PATCH] drm/shmem-helper: Fix compile error
>
> On Tue, 28 Feb 2023, Andi Shyti <andi.sh...@linux.intel.com> wrote:
> > Hi,
> >
> >> >> > Commit 67b7836d4458 ("drm/shmem-helper: Switch to reservation
> >> >> > lock") removes the drm_gem_shmem_get_pages_locked() and
> >> >> > drm_gem_shmem_put_pages_locked().
> >> >> >
> >> >> > But then commit ddddedaa0db9 ("drm/shmem-helper: Fix locking for
> >> >> > drm_gem_shmem_get_pages_sgt()") reintroduces it.
> >> >> >
> >> >> > Somehow these two commits got mixed up and produce the following
> >> >> > compile error:
> >> >>
> >> >> The 67b7836d4458 goes after ddddedaa0db9 in misc-next. It was a
> >> >> bad merge conflict resolution in drm-tip that was fixed yesterday,
> >> >> there is no problem in misc-next. Where do you see this error?
> >> >
> >> > yes, indeed! I was indeed surprised to see this mismatch.
> >> >
> >> > I see it in the Intel's drm-tip branch[*]
> >>
> >> To set the record straight, drm-tip isn't Intel's, it's an
> >> integration branch shared by the drm community.
> >
> > yes of course... it's a matter of fast writing :)
> >
> >> Looks like the same bad merge resolution has resurrected itself
> >> somehow, maybe Thomas'
> >>
> >> commit 418ce969b4c8533c7c76cc0b7adeb432ccdc137e
> >> Author: Thomas Zimmermann <tzimmerm...@suse.de>
> >> Date: Tue Feb 28 10:03:24 2023 +0100
> >>
> >> 2023y-02m-28d-09h-02m-44s UTC: drm-tip rerere cache update
> >>
> >> git version 2.39.2
> >>
> >> in drm-rerere brought it back.
> >>
> >> And the build is indeed currently broken.
> >>
> >> Moreover, when the build was fine for a while, apparently the changes
> >> in shmem broke a bunch of machines in Intel CI. And due to this, we
> >> aren't getting any CI results for incoming patches right now.
> >
> > Is there any plans for fixing it?
>
> Someone(tm) needs to step up and do it. Personally, I'm clueless.
>
> The whole thing is made worse by the conflict and the various resolutions. At
> this
> time, I'm not certain whether the whole thing was broken to begin with, or if
> it's
> just the conflict resolution that caused the issues.
>
> I'll just note that for future reference, Cc'ing intel-gfx for anything
> non-trivial
> touching the guts of drm will be useful for running CI on our test farm
> pre-merge.
> Now, we don't know.
Yeah, and sad story can be seen from
https://intel-gfx-ci.01.org/tree/drm-tip/index.html? .
All systems now abort on BAT run.
Just to pick one:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/fi-tgl-1115g4/igt@gem_exec_fence@basic-b...@vecs0.html
Please fix asap. Or revert from tree asap.
>
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
