[PATCH i-g-t 0/3] aubdump: A few improvements

[PATCH i-g-t 0/3] aubdump: A few improvements

[Jason Ekstrand]

These three patches are improvements that I've had locally in my tree for
some period of time.  The first one is required for Vulkan to work
correctly with aubdump ever since we turned on 48-bit addressing.  The
second is just a bit of future-proofing.  The third makes the tool dump
some information to stderr which I have found very useful when debugging
things.

Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

Jason Ekstrand (3):
  aubdump: Reject execbuffer2 calls with bad BOs
  aubdump: Use write_reloc for filling out the ringbuffer
  aubdump: Log some information about the execbuf calls

 tools/aubdump.c | 80 +++++++++++++++++++++++++++++++++------------------------
 1 file changed, 46 insertions(+), 34 deletions(-)

-- 
2.5.0.400.gff86faf

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs

[Jason Ekstrand]

This is required for the supports_48b_addresses check in the Vulkan
driver to work without messing up the resulting aub.
---
 tools/aubdump.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index 610526c..c14c9fa 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -426,6 +426,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
 		obj = &exec_objects[i];
 		bo = get_bo(obj->handle);
 
+		/* If bo->size == 0, this means they passed us an invalid
+		 * buffer.  The kernel will reject it and so should we.
+		 */
+		if (bo->size == 0)
+			return;
+
 		if (obj->flags & EXEC_OBJECT_PINNED) {
 			bo->offset = obj->offset;
 		} else {
@@ -475,6 +481,7 @@ add_new_bo(int handle, uint64_t size, void *map)
 	struct bo *bo = &bos[handle];
 
 	fail_if(handle >= MAX_BO_COUNT, "intel_aubdump: bo handle out of range\n");
+	fail_if(size == 0, "intel_aubdump: bo size is invalid\n");
 
 	bo->size = size;
 	bo->map = map;
@@ -487,6 +494,7 @@ remove_bo(int handle)
 
 	if (bo->map && !IS_USERPTR(bo->map))
 		munmap(bo->map, bo->size);
+	bo->size = 0;
 	bo->map = NULL;
 }
 
-- 
2.5.0.400.gff86faf

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 1/3] aubdump: Reject execbuffer2 calls with bad BOs

[Lionel Landwerlin]

Heh, fixed the same in ksim. Don't know why I didn't see it while using 
aubdump recently...

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

On 23/08/17 18:14, Jason Ekstrand wrote:
> This is required for the supports_48b_addresses check in the Vulkan
> driver to work without messing up the resulting aub.
> ---
>   tools/aubdump.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index 610526c..c14c9fa 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -426,6 +426,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
>   		obj = &exec_objects[i];
>   		bo = get_bo(obj->handle);
>   
> +		/* If bo->size == 0, this means they passed us an invalid
> +		 * buffer.  The kernel will reject it and so should we.
> +		 */
> +		if (bo->size == 0)
> +			return;
> +
>   		if (obj->flags & EXEC_OBJECT_PINNED) {
>   			bo->offset = obj->offset;
>   		} else {
> @@ -475,6 +481,7 @@ add_new_bo(int handle, uint64_t size, void *map)
>   	struct bo *bo = &bos[handle];
>   
>   	fail_if(handle >= MAX_BO_COUNT, "intel_aubdump: bo handle out of range\n");
> +	fail_if(size == 0, "intel_aubdump: bo size is invalid\n");
>   
>   	bo->size = size;
>   	bo->map = map;
> @@ -487,6 +494,7 @@ remove_bo(int handle)
>   
>   	if (bo->map && !IS_USERPTR(bo->map))
>   		munmap(bo->map, bo->size);
> +	bo->size = 0;
>   	bo->map = NULL;
>   }
>   


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH i-g-t 2/3] aubdump: Use write_reloc for filling out the ringbuffer

[Jason Ekstrand]

---
 tools/aubdump.c | 66 ++++++++++++++++++++++++++++-----------------------------
 1 file changed, 32 insertions(+), 34 deletions(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index c14c9fa..567de3d 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -262,9 +262,36 @@ aub_write_trace_block(uint32_t type, void *virtual, uint32_t size, uint64_t gtt_
 }
 
 static void
+write_reloc(void *p, uint64_t v)
+{
+	if (gen >= 8) {
+		/* From the Broadwell PRM Vol. 2a,
+		 * MI_LOAD_REGISTER_MEM::MemoryAddress:
+		 *
+		 *	"This field specifies the address of the memory
+		 *	location where the register value specified in the
+		 *	DWord above will read from.  The address specifies
+		 *	the DWord location of the data. Range =
+		 *	GraphicsVirtualAddress[63:2] for a DWord register
+		 *	GraphicsAddress [63:48] are ignored by the HW and
+		 *	assumed to be in correct canonical form [63:48] ==
+		 *	[47]."
+		 *
+		 * In practice, this will always mean the top bits are zero
+		 * because of the GTT size limitation of the aubdump tool.
+		 */
+		const int shift = 63 - 47;
+		*(uint64_t *)p = (((int64_t)v) << shift) >> shift;
+	} else {
+		*(uint32_t *)p = v;
+	}
+}
+
+static void
 aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
 {
 	uint32_t ringbuffer[4096];
+	unsigned aub_mi_bbs_len;
 	int ring = AUB_TRACE_TYPE_RING_PRB0; /* The default ring */
 	int ring_count = 0;
 
@@ -275,14 +302,11 @@ aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
 
 	/* Make a ring buffer to execute our batchbuffer. */
 	memset(ringbuffer, 0, sizeof(ringbuffer));
-	if (gen >= 8) {
-		ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START | (3 - 2);
-		ringbuffer[ring_count++] = batch_offset;
-		ringbuffer[ring_count++] = batch_offset >> 32;
-	} else {
-		ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START;
-		ringbuffer[ring_count++] = batch_offset;
-	}
+
+	aub_mi_bbs_len = gen >= 8 ? 3 : 2;
+	ringbuffer[ring_count] = AUB_MI_BATCH_BUFFER_START | (aub_mi_bbs_len - 2);
+	write_reloc(&ringbuffer[ring_count + 1], batch_offset);
+	ring_count += aub_mi_bbs_len;
 
 	/* Write out the ring.  This appears to trigger execution of
 	 * the ring in the simulator.
@@ -299,32 +323,6 @@ aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
 	data_out(ringbuffer, ring_count * 4);
 }
 
-static void
-write_reloc(void *p, uint64_t v)
-{
-	if (gen >= 8) {
-		/* From the Broadwell PRM Vol. 2a,
-		 * MI_LOAD_REGISTER_MEM::MemoryAddress:
-		 *
-		 *	"This field specifies the address of the memory
-		 *	location where the register value specified in the
-		 *	DWord above will read from.  The address specifies
-		 *	the DWord location of the data. Range =
-		 *	GraphicsVirtualAddress[63:2] for a DWord register
-		 *	GraphicsAddress [63:48] are ignored by the HW and
-		 *	assumed to be in correct canonical form [63:48] ==
-		 *	[47]."
-		 *
-		 * In practice, this will always mean the top bits are zero
-		 * because of the GTT size limitation of the aubdump tool.
-		 */
-		const int shift = 63 - 47;
-		*(uint64_t *)p = (((int64_t)v) << shift) >> shift;
-	} else {
-		*(uint32_t *)p = v;
-	}
-}
-
 static void *
 relocate_bo(struct bo *bo, const struct drm_i915_gem_execbuffer2 *execbuffer2,
 	    const struct drm_i915_gem_exec_object2 *obj)
-- 
2.5.0.400.gff86faf

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 2/3] aubdump: Use write_reloc for filling out the ringbuffer

[Lionel Landwerlin]

Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

On 23/08/17 18:14, Jason Ekstrand wrote:
> ---
>   tools/aubdump.c | 66 ++++++++++++++++++++++++++++-----------------------------
>   1 file changed, 32 insertions(+), 34 deletions(-)
>
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index c14c9fa..567de3d 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -262,9 +262,36 @@ aub_write_trace_block(uint32_t type, void *virtual, uint32_t size, uint64_t gtt_
>   }
>   
>   static void
> +write_reloc(void *p, uint64_t v)
> +{
> +	if (gen >= 8) {
> +		/* From the Broadwell PRM Vol. 2a,
> +		 * MI_LOAD_REGISTER_MEM::MemoryAddress:
> +		 *
> +		 *	"This field specifies the address of the memory
> +		 *	location where the register value specified in the
> +		 *	DWord above will read from.  The address specifies
> +		 *	the DWord location of the data. Range =
> +		 *	GraphicsVirtualAddress[63:2] for a DWord register
> +		 *	GraphicsAddress [63:48] are ignored by the HW and
> +		 *	assumed to be in correct canonical form [63:48] ==
> +		 *	[47]."
> +		 *
> +		 * In practice, this will always mean the top bits are zero
> +		 * because of the GTT size limitation of the aubdump tool.
> +		 */
> +		const int shift = 63 - 47;
> +		*(uint64_t *)p = (((int64_t)v) << shift) >> shift;
> +	} else {
> +		*(uint32_t *)p = v;
> +	}
> +}
> +
> +static void
>   aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
>   {
>   	uint32_t ringbuffer[4096];
> +	unsigned aub_mi_bbs_len;
>   	int ring = AUB_TRACE_TYPE_RING_PRB0; /* The default ring */
>   	int ring_count = 0;
>   
> @@ -275,14 +302,11 @@ aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
>   
>   	/* Make a ring buffer to execute our batchbuffer. */
>   	memset(ringbuffer, 0, sizeof(ringbuffer));
> -	if (gen >= 8) {
> -		ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START | (3 - 2);
> -		ringbuffer[ring_count++] = batch_offset;
> -		ringbuffer[ring_count++] = batch_offset >> 32;
> -	} else {
> -		ringbuffer[ring_count++] = AUB_MI_BATCH_BUFFER_START;
> -		ringbuffer[ring_count++] = batch_offset;
> -	}
> +
> +	aub_mi_bbs_len = gen >= 8 ? 3 : 2;
> +	ringbuffer[ring_count] = AUB_MI_BATCH_BUFFER_START | (aub_mi_bbs_len - 2);
> +	write_reloc(&ringbuffer[ring_count + 1], batch_offset);
> +	ring_count += aub_mi_bbs_len;
>   
>   	/* Write out the ring.  This appears to trigger execution of
>   	 * the ring in the simulator.
> @@ -299,32 +323,6 @@ aub_dump_ringbuffer(uint64_t batch_offset, uint64_t offset, int ring_flag)
>   	data_out(ringbuffer, ring_count * 4);
>   }
>   
> -static void
> -write_reloc(void *p, uint64_t v)
> -{
> -	if (gen >= 8) {
> -		/* From the Broadwell PRM Vol. 2a,
> -		 * MI_LOAD_REGISTER_MEM::MemoryAddress:
> -		 *
> -		 *	"This field specifies the address of the memory
> -		 *	location where the register value specified in the
> -		 *	DWord above will read from.  The address specifies
> -		 *	the DWord location of the data. Range =
> -		 *	GraphicsVirtualAddress[63:2] for a DWord register
> -		 *	GraphicsAddress [63:48] are ignored by the HW and
> -		 *	assumed to be in correct canonical form [63:48] ==
> -		 *	[47]."
> -		 *
> -		 * In practice, this will always mean the top bits are zero
> -		 * because of the GTT size limitation of the aubdump tool.
> -		 */
> -		const int shift = 63 - 47;
> -		*(uint64_t *)p = (((int64_t)v) << shift) >> shift;
> -	} else {
> -		*(uint32_t *)p = v;
> -	}
> -}
> -
>   static void *
>   relocate_bo(struct bo *bo, const struct drm_i915_gem_execbuffer2 *execbuffer2,
>   	    const struct drm_i915_gem_exec_object2 *obj)


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH i-g-t 3/3] aubdump: Log some information about the execbuf calls

[Jason Ekstrand]

---
 tools/aubdump.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/aubdump.c b/tools/aubdump.c
index 567de3d..cf4c6e8 100644
--- a/tools/aubdump.c
+++ b/tools/aubdump.c
@@ -405,6 +405,8 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
 	struct bo *bo, *batch_bo;
 	void *data;
 
+	fprintf(stderr, "Dumping execbuffer2:\n");
+
 	/* We can't do this at open time as we're not yet authenticated. */
 	if (device == 0) {
 		device = gem_get_param(fd, I915_PARAM_CHIPSET_ID);
@@ -427,8 +429,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
 		/* If bo->size == 0, this means they passed us an invalid
 		 * buffer.  The kernel will reject it and so should we.
 		 */
-		if (bo->size == 0)
+		if (bo->size == 0) {
+			fprintf(stderr, "BO #%d is invalid!\n", obj->handle);
 			return;
+		}
+
+		fprintf(stderr, "BO #%d (%dB) @ 0x%x\n", obj->handle, bo->size, offset);
 
 		if (obj->flags & EXEC_OBJECT_PINNED) {
 			bo->offset = obj->offset;
-- 
2.5.0.400.gff86faf

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH i-g-t 3/3] aubdump: Log some information about the execbuf calls

[Scott D Phillips]

Jason Ekstrand <jason@jlekstrand.net> writes:

> ---
>  tools/aubdump.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/tools/aubdump.c b/tools/aubdump.c
> index 567de3d..cf4c6e8 100644
> --- a/tools/aubdump.c
> +++ b/tools/aubdump.c
> @@ -405,6 +405,8 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
>  	struct bo *bo, *batch_bo;
>  	void *data;
>  
> +	fprintf(stderr, "Dumping execbuffer2:\n");
> +

Maybe put these prints under an `if (verbose)'. Series is

Reviewed-by: Scott D Phillips <scott.d.phillips@intel.com>

>  	/* We can't do this at open time as we're not yet authenticated. */
>  	if (device == 0) {
>  		device = gem_get_param(fd, I915_PARAM_CHIPSET_ID);
> @@ -427,8 +429,12 @@ dump_execbuffer2(int fd, struct drm_i915_gem_execbuffer2 *execbuffer2)
>  		/* If bo->size == 0, this means they passed us an invalid
>  		 * buffer.  The kernel will reject it and so should we.
>  		 */
> -		if (bo->size == 0)
> +		if (bo->size == 0) {
> +			fprintf(stderr, "BO #%d is invalid!\n", obj->handle);
>  			return;
> +		}
> +
> +		fprintf(stderr, "BO #%d (%dB) @ 0x%x\n", obj->handle, bo->size, offset);
>  
>  		if (obj->flags & EXEC_OBJECT_PINNED) {
>  			bo->offset = obj->offset;
> -- 
> 2.5.0.400.gff86faf
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.BAT: failure for aubdump: A few improvements

[Patchwork]

== Series Details ==

Series: aubdump: A few improvements
URL   : https://patchwork.freedesktop.org/series/29225/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
42b42c99cd9d1b890807ae97cbd1c593396ae051 tests/Makefile.am: Wrap audio test with dedicated conditional

with latest DRM-Tip kernel build CI_DRM_2995
2964b2f40295 drm-tip: 2017y-08m-23d-13h-11m-32s UTC integration manifest

Test kms_cursor_legacy:
        Subgroup basic-flip-after-cursor-varying-size:
                pass       -> FAIL       (fi-hsw-4770)
        Subgroup basic-flip-before-cursor-varying-size:
                pass       -> FAIL       (fi-hsw-4770)
Test kms_flip:
        Subgroup basic-flip-vs-modeset:
                pass       -> SKIP       (fi-skl-x1585l) fdo#101781

fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781

fi-bdw-5557u     total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:457s
fi-bdw-gvtdvm    total:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  time:438s
fi-blb-e6850     total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  time:366s
fi-bsw-n3050     total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  time:568s
fi-bwr-2160      total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  time:251s
fi-bxt-j4205     total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:518s
fi-byt-j1900     total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  time:531s
fi-byt-n2820     total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  time:529s
fi-elk-e7500     total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  time:440s
fi-glk-2a        total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:618s
fi-hsw-4770      total:279  pass:261  dwarn:0   dfail:0   fail:2   skip:16  time:443s
fi-hsw-4770r     total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:425s
fi-ilk-650       total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  time:419s
fi-ivb-3520m     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:509s
fi-ivb-3770      total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:475s
fi-kbl-7500u     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:477s
fi-kbl-7560u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:598s
fi-kbl-r         total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:603s
fi-pnv-d510      total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  time:529s
fi-skl-6260u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:468s
fi-skl-6700k     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:480s
fi-skl-6770hq    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:489s
fi-skl-gvtdvm    total:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  time:444s
fi-skl-x1585l    total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:488s
fi-snb-2520m     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:550s
fi-snb-2600      total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  time:408s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_91/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for aubdump: A few improvements

[Patchwork]

== Series Details ==

Series: aubdump: A few improvements
URL   : https://patchwork.freedesktop.org/series/29225/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
80cc54023e198165eca34450e9cc75c9cffcb072 lib/core: Use igt_info instead of printf

with latest DRM-Tip kernel build CI_DRM_2998
3adc9e3cacef drm-tip: 2017y-08m-23d-21h-35m-35s UTC integration manifest

Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-b:
                pass       -> DMESG-WARN (fi-byt-n2820) fdo#101705
        Subgroup suspend-read-crc-pipe-c:
                fail       -> PASS       (fi-skl-6700k) fdo#100367

fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705
fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367

fi-bdw-5557u     total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:454s
fi-bdw-gvtdvm    total:279  pass:265  dwarn:0   dfail:0   fail:0   skip:14  time:439s
fi-blb-e6850     total:279  pass:224  dwarn:1   dfail:0   fail:0   skip:54  time:365s
fi-bsw-n3050     total:279  pass:243  dwarn:0   dfail:0   fail:0   skip:36  time:557s
fi-bwr-2160      total:279  pass:184  dwarn:0   dfail:0   fail:0   skip:95  time:253s
fi-bxt-j4205     total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:526s
fi-byt-j1900     total:279  pass:254  dwarn:1   dfail:0   fail:0   skip:24  time:525s
fi-byt-n2820     total:279  pass:250  dwarn:1   dfail:0   fail:0   skip:28  time:517s
fi-elk-e7500     total:279  pass:230  dwarn:0   dfail:0   fail:0   skip:49  time:437s
fi-glk-2a        total:279  pass:260  dwarn:0   dfail:0   fail:0   skip:19  time:621s
fi-hsw-4770      total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:447s
fi-hsw-4770r     total:279  pass:263  dwarn:0   dfail:0   fail:0   skip:16  time:420s
fi-ilk-650       total:279  pass:229  dwarn:0   dfail:0   fail:0   skip:50  time:420s
fi-ivb-3520m     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:504s
fi-ivb-3770      total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:475s
fi-kbl-7500u     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:479s
fi-kbl-r         total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:598s
fi-pnv-d510      total:279  pass:223  dwarn:1   dfail:0   fail:0   skip:55  time:526s
fi-skl-6260u     total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:474s
fi-skl-6700k     total:279  pass:261  dwarn:0   dfail:0   fail:0   skip:18  time:482s
fi-skl-6770hq    total:279  pass:269  dwarn:0   dfail:0   fail:0   skip:10  time:494s
fi-skl-gvtdvm    total:279  pass:266  dwarn:0   dfail:0   fail:0   skip:13  time:453s
fi-skl-x1585l    total:279  pass:268  dwarn:0   dfail:0   fail:0   skip:11  time:486s
fi-snb-2520m     total:279  pass:251  dwarn:0   dfail:0   fail:0   skip:28  time:551s
fi-snb-2600      total:279  pass:250  dwarn:0   dfail:0   fail:0   skip:29  time:412s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_93/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for aubdump: A few improvements

[Patchwork]

== Series Details ==

Series: aubdump: A few improvements
URL   : https://patchwork.freedesktop.org/series/29225/
State : success

== Summary ==

shard-hsw        total:2230 pass:1229 dwarn:0   dfail:0   fail:19  skip:982 time:9603s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_93/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx