Quoting Chris Wilson (2018-02-24 18:54:04) > If the specified object can not fit into the GTT due to overlap with a > neighbouring pinned object (not part of the execobjects[]), we expect to > fail with ENOSPC (as we cannot evict, rather than EINVAL for the user > error in a badly constructed execobjects[]). To prevent the tests > causing overlap with other external objects expand the test hole by a > page on either side. > > (Setting up the system to deliberately hit ENOSPC is trickier as for > example it requires pinned an object into the scanout with enough free > space on either side to test.) Anybody? I know it's an esoteric part of ancient HW that no one cares about... -Chris > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > --- > tests/gem_softpin.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c > index 99388599..23f93623 100644 > --- a/tests/gem_softpin.c > +++ b/tests/gem_softpin.c > @@ -302,11 +302,11 @@ static void test_evict_snoop(int fd) > > /* Find a hole */ > memset(object, 0, sizeof(object)); > - object[0].handle = gem_create(fd, 3*4096); > + object[0].handle = gem_create(fd, 5*4096); > gem_write(fd, object[0].handle, 0, &bbe, sizeof(bbe)); > gem_execbuf(fd, &execbuf); > gem_close(fd, object[0].handle); > - hole = object[0].offset; > + hole = object[0].offset + 4096; > > /* Create a snoop + uncached pair */ > object[0].handle = gem_create(fd, 4096); > -- > 2.16.1 > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
