On Thu, Dec 04, 2014 at 04:18:39PM +0000, Chris Wilson wrote: > On Thu, Dec 04, 2014 at 01:58:54PM +0000, Damien Lespiau wrote: > > Here is a cheap way for this test to give consistent results. This > > doesn't change the usefulness of this test, hopefully. > > > > Signed-off-by: Damien Lespiau <damien.lespiau@xxxxxxxxx> > > --- > > tests/gem_bad_reloc.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/tests/gem_bad_reloc.c b/tests/gem_bad_reloc.c > > index df0100f..ef6b52a 100644 > > --- a/tests/gem_bad_reloc.c > > +++ b/tests/gem_bad_reloc.c > > @@ -87,7 +87,13 @@ static int negative_reloc(int fd, unsigned flags) > > gem_close(fd, gem_exec[1].handle); > > > > igt_info("Found offset %ld for 4k batch\n", (long)gem_exec[0].offset); > > - igt_require(gem_exec[0].offset < BIAS); > > + /* > > + * Ideally we'd like to be able to control where the kernel is going to > > + * place the buffer. We don't SKIP here because it causes the test > > + * to "randomly" flip-flop between the SKIP and PASS states. > > + */ > > Riddle me thus: the test scripts try to ensure that every test run has > the identical environment. Yet between runs we have different layouts of > framebuffer objects... > > To improve this test, what you could actually try is disabling all > CRTCs. That should give consistent results. I actually didn't manage to reproduce the erratic behaviour described in the bug. So maybe we've already fixed what caused the flip-flopping in the first place. Or maybe I can't reproduce it because I'm running in a clean environment wihout having run a few dozen kms tests beforehand. In any case, I'd rather go for the quick option that doesn't make the worse in a too awful way and is won't regress (it's also less work, I'm lazy). -- Damien _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx