Re: ✗ Fi.CI.BAT: failure for drm/i915: Move load time stolen memory init earlier

Daniel Vetter
2016-01-25T17:47:01Z

On Mon, Jan 25, 2016 at 07:34:08PM +0200, Imre Deak wrote:
> On ma, 2016-01-25 at 17:21 +0100, Daniel Vetter wrote:
> > On Tue, Jan 19, 2016 at 06:22:21PM +0200, Imre Deak wrote:
> > > On ti, 2016-01-19 at 13:49 +0000, Patchwork wrote:
> > > > == Summary ==
> > > >
> > > > Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-
> > > > nightly:
> > > > 2016y-01m-18d-16h-50m-37s UTC integration manifest
> > > >
> > > > Test gem_ctx_basic:
> > > >                 pass       -> FAIL       (bdw-ultra)
> > >
> > > Couldn't reproduce it on the same machine. To me it looks unrelated
> > > as
> > > it happened already several times for other patches, always on the
> > > same
> > > machine. These BAT results are not shown on the test's "long term"
> > > history btw. I filed a bug:
> >
> > long term only shows changes, not all tests.
>
> Ok, so I take that's changes for CI runs, but not for patchwork
> initiated tests.
>
> > Which means it didn't yet
> > fail in -nightly, which is somewhat suspicious ... But I agree that
> > this
> > seems to have blown up a few times in other CI runs.
>
> Ok, so based on that this patchset is good to go I guess.
>
> Still not sure why the test fails. One thing I noticed is a bunch of
> "gem_concurrent: drop caches" messages in dmesg before any test would
> be even started. So I think something in gem_concurrent is not guarded
> with igt_fixture{} and gets to run when piglit enumerates the subtests
> (to get the BAT subtests). Not sure though if this has a negative
> effect on anything.

We iirc drop caches as part of gem_quiescent too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation