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@xxxxxxx>
> > >> 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.
yeah... I think we either need to fix the rerere branch (which,
allow me, is like talking to an angry wife without knowing why
she's angry) or just take my patch and have it fixed right away
(with some bisect broken in between, I guess).
I don't know what's the best approach and in any case I don't
have the power to fix it (let me know, in any case, if I can
help).
> > 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.
Yes, fully agree!
Andi
> 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@xxxxxxxxxx
> Please fix asap. Or revert from tree asap.
>
> >
> >
> > BR,
> > Jani.
> >
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
