On Wed, Oct 13, 2021 at 02:35:25PM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-10-13 14:02:59 [+0200], Daniel Vetter wrote:
> > On Tue, Oct 05, 2021 at 08:51:51AM +0200, Sebastian Andrzej Siewior wrote:
> > > The warning poped up, it says it increase it by the number of occurrence.
> > > I saw it 18 times so here it is.
> > > It started to up since commit
> > > 2f425cf5242a0 ("drm: Fix oops in damage self-tests by mocking damage property")
> > >
> > > Increase DRM_OBJECT_MAX_PROPERTY by 18.
> > >
> > > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> >
> > Which driver where? Whomever added that into upstream should also have
> > realized this (things will just not work) and include it in there. So if
> > things are tested correctly this should be part of a larger series to add
> > these 18 props somewhere.
>
> This is on i915 with full debug. If I remember correctly, it wasn't
> there before commit
> c7fcbf2513973 ("drm/plane: check that fb_damage is set up when used")
>
> With that commit the box crashed until commit
> 2f425cf5242a0 ("drm: Fix oops in damage self-tests by mocking damage property")
>
> where I then observed this.
Hm there's a pile of commits there, and nothing immediately jumps to
light. The thing is, 18 is likely way too much, since if e.g. we have a
single new property on a plane and that pushes over the limit on all of
them, you get iirc 3x4 already simply because we have that many planes.
So would be good to know the actual culprit.
Can you pls try to bisect the above range, applying the patch as a fixup
locally (without commit, that will confuse git bisect a bit I think), so
we know what/where went wrong?
I'm still confused why this isn't showing up anywhere in our intel ci ...
Thanks, Daniel
>
> > Also maybe we should just dynamically allocate this array if people have
> > this many properties on their objects.
> > -Daniel
>
> Sebastian
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
