[Intel-gfx] [PATCH] drm/shmem-helper: Fix compile error

[Saarinen, Jani]

Hi, 
> -----Original Message-----
> From: Nikula, Jani <jani.nikula at intel.com>
> Sent: tiistai 28. helmikuuta 2023 16.40
> To: Andi Shyti <andi.shyti at linux.intel.com>
> Cc: Andi Shyti <andi.shyti at linux.intel.com>; Dmitry Osipenko
> <dmitry.osipenko at collabora.com>; dri-devel at lists.freedesktop.org; Maarten
> Lankhorst <maarten.lankhorst at linux.intel.com>; Maxime Ripard
> <mripard at kernel.org>; Thomas Zimmermann <tzimmermann at suse.de>; David
> Airlie <airlied at gmail.com>; Daniel Vetter <daniel at ffwll.ch>; Javier Martinez
> Canillas <javierm at redhat.com>; Asahi Lina <lina at asahilina.net>; Andi Shyti
> <andi at etezian.org>; Intel GFX <intel-gfx at lists.freedesktop.org>; Tvrtko Ursulin
> <tvrtko.ursulin at linux.intel.com>; Vivi, Rodrigo <rodrigo.vivi at intel.com>; Joonas
> Lahtinen <joonas.lahtinen at linux.intel.com>; Saarinen, Jani
> <jani.saarinen at intel.com>
> Subject: Re: [PATCH] drm/shmem-helper: Fix compile error
> 
> On Tue, 28 Feb 2023, Andi Shyti <andi.shyti at 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 <tzimmermann at 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-busy@vecs0.html
Please fix asap. Or revert from tree asap. 

> 
> 
> BR,
> Jani.
> 
> 
> --
> Jani Nikula, Intel Open Source Graphics Center