tests/gem_bad_address: Adapt test to ppgtt to pass with command parser
diff mbox

Message ID 1431684301-19259-1-git-send-email-pavel.e.popov@intel.com
State New
Headers show

Commit Message

Pavel Popov May 15, 2015, 10:05 a.m. UTC
The gem_bad_address test started to fail on Gen7 with enabled command parser.
Error message is printed because MI_GLOBAL_GTT equals to MI_MEM_VIRTUAL:
    "CMD: Rejected command 0x10600002 for bitmask 0x00400000...".
MI_MEM_VIRTUAL means global gtt. This bit shouldn't be set for ppgtt.

Changed test like it was done previously for storedw tests in the commit:
    afbdc7af8d9324ae065c47d6122bb020c579fd0a.

Signed-off-by: Pavel Popov <pavel.e.popov@intel.com>
---
 tests/gem_bad_address.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

Comments

Chris Wilson May 15, 2015, 11:16 a.m. UTC | #1
On Fri, May 15, 2015 at 04:05:01PM +0600, Pavel Popov wrote:
> The gem_bad_address test started to fail on Gen7 with enabled command parser.
> Error message is printed because MI_GLOBAL_GTT equals to MI_MEM_VIRTUAL:
>     "CMD: Rejected command 0x10600002 for bitmask 0x00400000...".
> MI_MEM_VIRTUAL means global gtt. This bit shouldn't be set for ppgtt.
> 
> Changed test like it was done previously for storedw tests in the commit:
>     afbdc7af8d9324ae065c47d6122bb020c579fd0a.

Heh, gem_bad_address is supposed to fail ;-)

As with gem_bad_blit, this is testing antiquated notions of what is
allowed: BAD_GTT_DEST is not what it claims to be.
-Chris
Pavel Popov May 18, 2015, 3:47 a.m. UTC | #2
Hi Chris,

Thanks for quick response. 

I see that these tests from HANG section. 
Probably all tests with unclear behavior are put here.

But what is about the test gem_exec_bad_domains?
It also contains BAD_GTT_DEST with the same value.
This test isn't from HANG section.

Pavel

-----Original Message-----
From: Chris Wilson [mailto:chris@chris-wilson.co.uk] 
Sent: Friday, May 15, 2015 5:17 PM
To: Popov, Pavel E
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] tests/gem_bad_address: Adapt test to ppgtt to pass with command parser

On Fri, May 15, 2015 at 04:05:01PM +0600, Pavel Popov wrote:
> The gem_bad_address test started to fail on Gen7 with enabled command parser.
> Error message is printed because MI_GLOBAL_GTT equals to MI_MEM_VIRTUAL:
>     "CMD: Rejected command 0x10600002 for bitmask 0x00400000...".
> MI_MEM_VIRTUAL means global gtt. This bit shouldn't be set for ppgtt.
> 
> Changed test like it was done previously for storedw tests in the commit:
>     afbdc7af8d9324ae065c47d6122bb020c579fd0a.

Heh, gem_bad_address is supposed to fail ;-)

As with gem_bad_blit, this is testing antiquated notions of what is
allowed: BAD_GTT_DEST is not what it claims to be.
-Chris
Chris Wilson May 18, 2015, 7:59 a.m. UTC | #3
On Mon, May 18, 2015 at 03:47:25AM +0000, Popov, Pavel E wrote:
> Hi Chris,
> 
> Thanks for quick response. 
> 
> I see that these tests from HANG section. 
> Probably all tests with unclear behavior are put here.
> 
> But what is about the test gem_exec_bad_domains?
> It also contains BAD_GTT_DEST with the same value.
> This test isn't from HANG section.

Cut and paste bugette. It is not used in the file as the test is about
correctness of the execbuffer API.
-Chris

Patch
diff mbox

diff --git a/tests/gem_bad_address.c b/tests/gem_bad_address.c
index 4a4a570..ccc55f1 100644
--- a/tests/gem_bad_address.c
+++ b/tests/gem_bad_address.c
@@ -44,14 +44,19 @@ 
 
 static drm_intel_bufmgr *bufmgr;
 struct intel_batchbuffer *batch;
+static int has_ppgtt = 0;
 
 #define BAD_GTT_DEST ((512*1024*1024)) /* past end of aperture */
 
 static void
 bad_store(void)
 {
+	int cmd = MI_STORE_DWORD_IMM | 1 << 21;
+	if (!has_ppgtt)
+		cmd |= MI_MEM_VIRTUAL;
+
 	BEGIN_BATCH(4, 0);
-	OUT_BATCH(MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL | 1 << 21);
+	OUT_BATCH(cmd);
 	OUT_BATCH(0);
 	OUT_BATCH(BAD_GTT_DEST);
 	OUT_BATCH(0xdeadbeef);
@@ -66,6 +71,8 @@  igt_simple_main
 
 	fd = drm_open_any();
 
+	has_ppgtt = gem_uses_aliasing_ppgtt(fd);
+
 	bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
 	drm_intel_bufmgr_gem_enable_reuse(bufmgr);
 	batch = intel_batchbuffer_alloc(bufmgr, intel_get_drm_devid(fd));