* [RFC PATCH i-g-t v3] tests/gem_exec_reloc: Don't filter out invalid addresses
@ 2019-10-30 17:15 ` Janusz Krzysztofik
0 siblings, 0 replies; 10+ messages in thread
From: Janusz Krzysztofik @ 2019-10-30 17:15 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev, intel-gfx
Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
addresses for !ppgtt") introduced filtering of addresses possibly
occupied by other users of shared GTT. Unfortunately, that filtering
doesn't distinguish actually occupied addresses from otherwise invalid
softpin offsets. For example, on a future hardware backing store with
a page size larger than 4 kB incorrect object alignment is assumed and
the test results are distorted as it happily skips over incorrectly
aligned objects instead of reporting the problem.
Filter out failing addresses only if not reported as invalid.
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/i915/gem_exec_reloc.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index fdd9661d..1d0c791e 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
uint64_t gtt_size = gem_aperture_size(fd);
const uint32_t bbe = MI_BATCH_BUFFER_END;
igt_spin_t *spin = NULL;
- int count, n;
+ int count, n, err;
igt_require(gem_has_softpin(fd));
@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
execbuf.buffers_ptr = to_user_pointer(&obj[n]);
execbuf.buffer_count = 1;
- if (__gem_execbuf(fd, &execbuf))
+ err = __gem_execbuf(fd, &execbuf);
+ if (err) {
+ igt_assert(err != -EINVAL);
continue;
+ }
igt_debug("obj[%d] handle=%d, address=%llx\n",
n, obj[n].handle, (long long)obj[n].offset);
@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
execbuf.buffers_ptr = to_user_pointer(&obj[n]);
execbuf.buffer_count = 1;
- if (__gem_execbuf(fd, &execbuf))
+ err = __gem_execbuf(fd, &execbuf);
+ if (err) {
+ igt_assert(err != -EINVAL);
continue;
+ }
igt_debug("obj[%d] handle=%d, address=%llx\n",
n, obj[n].handle, (long long)obj[n].offset);
--
2.21.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [Intel-gfx] [RFC PATCH i-g-t v3] tests/gem_exec_reloc: Don't filter out invalid addresses
@ 2019-10-30 17:15 ` Janusz Krzysztofik
0 siblings, 0 replies; 10+ messages in thread
From: Janusz Krzysztofik @ 2019-10-30 17:15 UTC (permalink / raw)
To: Chris Wilson; +Cc: igt-dev, intel-gfx
Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
addresses for !ppgtt") introduced filtering of addresses possibly
occupied by other users of shared GTT. Unfortunately, that filtering
doesn't distinguish actually occupied addresses from otherwise invalid
softpin offsets. For example, on a future hardware backing store with
a page size larger than 4 kB incorrect object alignment is assumed and
the test results are distorted as it happily skips over incorrectly
aligned objects instead of reporting the problem.
Filter out failing addresses only if not reported as invalid.
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/i915/gem_exec_reloc.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index fdd9661d..1d0c791e 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
uint64_t gtt_size = gem_aperture_size(fd);
const uint32_t bbe = MI_BATCH_BUFFER_END;
igt_spin_t *spin = NULL;
- int count, n;
+ int count, n, err;
igt_require(gem_has_softpin(fd));
@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
execbuf.buffers_ptr = to_user_pointer(&obj[n]);
execbuf.buffer_count = 1;
- if (__gem_execbuf(fd, &execbuf))
+ err = __gem_execbuf(fd, &execbuf);
+ if (err) {
+ igt_assert(err != -EINVAL);
continue;
+ }
igt_debug("obj[%d] handle=%d, address=%llx\n",
n, obj[n].handle, (long long)obj[n].offset);
@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
execbuf.buffers_ptr = to_user_pointer(&obj[n]);
execbuf.buffer_count = 1;
- if (__gem_execbuf(fd, &execbuf))
+ err = __gem_execbuf(fd, &execbuf);
+ if (err) {
+ igt_assert(err != -EINVAL);
continue;
+ }
igt_debug("obj[%d] handle=%d, address=%llx\n",
n, obj[n].handle, (long long)obj[n].offset);
--
2.21.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [igt-dev] ✓ Fi.CI.BAT: success for tests/gem_exec_reloc: Don't filter out invalid addresses
2019-10-30 17:15 ` [Intel-gfx] " Janusz Krzysztofik
(?)
@ 2019-10-30 18:03 ` Patchwork
-1 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2019-10-30 18:03 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev
== Series Details ==
Series: tests/gem_exec_reloc: Don't filter out invalid addresses
URL : https://patchwork.freedesktop.org/series/68779/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7226 -> IGTPW_3634
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/index.html
Known issues
------------
Here are the changes found in IGTPW_3634 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_switch@legacy-render:
- fi-cml-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#110566])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-cml-u2/igt@gem_ctx_switch@legacy-render.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-cml-u2/igt@gem_ctx_switch@legacy-render.html
* igt@gem_mmap_gtt@basic-write-read:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-icl-u3/igt@gem_mmap_gtt@basic-write-read.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-icl-u3/igt@gem_mmap_gtt@basic-write-read.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [PASS][7] -> [FAIL][8] ([fdo#103167])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-icl-u3/igt@kms_frontbuffer_tracking@basic.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-icl-u3/igt@kms_frontbuffer_tracking@basic.html
#### Possible fixes ####
* igt@gem_ctx_create@basic-files:
- {fi-cml-s}: [INCOMPLETE][9] ([fdo#110566]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-cml-s/igt@gem_ctx_create@basic-files.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-cml-s/igt@gem_ctx_create@basic-files.html
- {fi-icl-u4}: [INCOMPLETE][11] ([fdo#107713] / [fdo#109100]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-icl-u4/igt@gem_ctx_create@basic-files.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-icl-u4/igt@gem_ctx_create@basic-files.html
- {fi-icl-guc}: [INCOMPLETE][13] ([fdo#107713] / [fdo#109100]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-icl-guc/igt@gem_ctx_create@basic-files.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-icl-guc/igt@gem_ctx_create@basic-files.html
* igt@gem_ctx_switch@rcs0:
- fi-icl-u2: [INCOMPLETE][15] ([fdo#107713]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-icl-u2/igt@gem_ctx_switch@rcs0.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-icl-u2/igt@gem_ctx_switch@rcs0.html
* igt@gem_mmap_gtt@basic:
- fi-icl-u3: [DMESG-WARN][17] ([fdo#107724]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-icl-u3/igt@gem_mmap_gtt@basic.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-icl-u3/igt@gem_mmap_gtt@basic.html
* {igt@i915_selftest@live_gt_heartbeat}:
- fi-skl-guc: [DMESG-FAIL][19] ([fdo#112096]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/fi-skl-guc/igt@i915_selftest@live_gt_heartbeat.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/fi-skl-guc/igt@i915_selftest@live_gt_heartbeat.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111831]: https://bugs.freedesktop.org/show_bug.cgi?id=111831
[fdo#112096]: https://bugs.freedesktop.org/show_bug.cgi?id=112096
Participating hosts (51 -> 42)
------------------------------
Missing (9): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-apl-guc fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5253 -> IGTPW_3634
CI-20190529: 20190529
CI_DRM_7226: 6190cecae6196d219ea9a19c16a81598141c68af @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_3634: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/index.html
IGT_5253: d46ccb32cf693e8d8253543e9a4fbe5eaef4aa41 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [igt-dev] [RFC PATCH i-g-t v3] tests/gem_exec_reloc: Don't filter out invalid addresses
@ 2019-10-30 21:19 ` Vanshidhar Konda
0 siblings, 0 replies; 10+ messages in thread
From: Vanshidhar Konda @ 2019-10-30 21:19 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev, intel-gfx
On Wed, Oct 30, 2019 at 06:15:35PM +0100, Janusz Krzysztofik wrote:
>Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
>addresses for !ppgtt") introduced filtering of addresses possibly
>occupied by other users of shared GTT. Unfortunately, that filtering
>doesn't distinguish actually occupied addresses from otherwise invalid
>softpin offsets. For example, on a future hardware backing store with
>a page size larger than 4 kB incorrect object alignment is assumed and
>the test results are distorted as it happily skips over incorrectly
>aligned objects instead of reporting the problem.
>
>Filter out failing addresses only if not reported as invalid.
>
>Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
>Cc: Chris Wilson <chris@chris-wilson.co.uk>
>---
> tests/i915/gem_exec_reloc.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
>diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
>index fdd9661d..1d0c791e 100644
>--- a/tests/i915/gem_exec_reloc.c
>+++ b/tests/i915/gem_exec_reloc.c
>@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
> uint64_t gtt_size = gem_aperture_size(fd);
> const uint32_t bbe = MI_BATCH_BUFFER_END;
> igt_spin_t *spin = NULL;
>- int count, n;
>+ int count, n, err;
>
> igt_require(gem_has_softpin(fd));
>
>@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
> gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> execbuf.buffer_count = 1;
>- if (__gem_execbuf(fd, &execbuf))
>+ err = __gem_execbuf(fd, &execbuf);
>+ if (err) {
>+ igt_assert(err != -EINVAL);
> continue;
The addresses to which the object is being pinned is generated as part
of the test. The code is just assuming that the address needs to be 4K
aligned instead of figuring out what the alignment requirement for the
device is.
Shouldn't the test be updated to generate virtual addresses per the
alignment requirements of the test device instead of just assuming 4K
increments are good?
Vanshi
>+ }
>
> igt_debug("obj[%d] handle=%d, address=%llx\n",
> n, obj[n].handle, (long long)obj[n].offset);
>@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
> gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> execbuf.buffer_count = 1;
>- if (__gem_execbuf(fd, &execbuf))
>+ err = __gem_execbuf(fd, &execbuf);
>+ if (err) {
>+ igt_assert(err != -EINVAL);
> continue;
>+ }
>
> igt_debug("obj[%d] handle=%d, address=%llx\n",
> n, obj[n].handle, (long long)obj[n].offset);
>--
>2.21.0
>
>_______________________________________________
>igt-dev mailing list
>igt-dev@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v3] tests/gem_exec_reloc: Don't filter out invalid addresses
@ 2019-10-30 21:19 ` Vanshidhar Konda
0 siblings, 0 replies; 10+ messages in thread
From: Vanshidhar Konda @ 2019-10-30 21:19 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev, intel-gfx
On Wed, Oct 30, 2019 at 06:15:35PM +0100, Janusz Krzysztofik wrote:
>Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
>addresses for !ppgtt") introduced filtering of addresses possibly
>occupied by other users of shared GTT. Unfortunately, that filtering
>doesn't distinguish actually occupied addresses from otherwise invalid
>softpin offsets. For example, on a future hardware backing store with
>a page size larger than 4 kB incorrect object alignment is assumed and
>the test results are distorted as it happily skips over incorrectly
>aligned objects instead of reporting the problem.
>
>Filter out failing addresses only if not reported as invalid.
>
>Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
>Cc: Chris Wilson <chris@chris-wilson.co.uk>
>---
> tests/i915/gem_exec_reloc.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
>diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
>index fdd9661d..1d0c791e 100644
>--- a/tests/i915/gem_exec_reloc.c
>+++ b/tests/i915/gem_exec_reloc.c
>@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
> uint64_t gtt_size = gem_aperture_size(fd);
> const uint32_t bbe = MI_BATCH_BUFFER_END;
> igt_spin_t *spin = NULL;
>- int count, n;
>+ int count, n, err;
>
> igt_require(gem_has_softpin(fd));
>
>@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
> gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> execbuf.buffer_count = 1;
>- if (__gem_execbuf(fd, &execbuf))
>+ err = __gem_execbuf(fd, &execbuf);
>+ if (err) {
>+ igt_assert(err != -EINVAL);
> continue;
The addresses to which the object is being pinned is generated as part
of the test. The code is just assuming that the address needs to be 4K
aligned instead of figuring out what the alignment requirement for the
device is.
Shouldn't the test be updated to generate virtual addresses per the
alignment requirements of the test device instead of just assuming 4K
increments are good?
Vanshi
>+ }
>
> igt_debug("obj[%d] handle=%d, address=%llx\n",
> n, obj[n].handle, (long long)obj[n].offset);
>@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
> gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> execbuf.buffer_count = 1;
>- if (__gem_execbuf(fd, &execbuf))
>+ err = __gem_execbuf(fd, &execbuf);
>+ if (err) {
>+ igt_assert(err != -EINVAL);
> continue;
>+ }
>
> igt_debug("obj[%d] handle=%d, address=%llx\n",
> n, obj[n].handle, (long long)obj[n].offset);
>--
>2.21.0
>
>_______________________________________________
>igt-dev mailing list
>igt-dev@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/igt-dev
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [igt-dev] [RFC PATCH i-g-t v3] tests/gem_exec_reloc: Don't filter out invalid addresses
@ 2019-10-31 7:40 ` Janusz Krzysztofik
0 siblings, 0 replies; 10+ messages in thread
From: Janusz Krzysztofik @ 2019-10-31 7:40 UTC (permalink / raw)
To: Vanshidhar Konda; +Cc: igt-dev, intel-gfx
On Wednesday, October 30, 2019 10:19:43 PM CET Vanshidhar Konda wrote:
> On Wed, Oct 30, 2019 at 06:15:35PM +0100, Janusz Krzysztofik wrote:
> >Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> >addresses for !ppgtt") introduced filtering of addresses possibly
> >occupied by other users of shared GTT. Unfortunately, that filtering
> >doesn't distinguish actually occupied addresses from otherwise invalid
> >softpin offsets. For example, on a future hardware backing store with
> >a page size larger than 4 kB incorrect object alignment is assumed and
> >the test results are distorted as it happily skips over incorrectly
> >aligned objects instead of reporting the problem.
> >
> >Filter out failing addresses only if not reported as invalid.
> >
> >Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> >Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >---
> > tests/i915/gem_exec_reloc.c | 12 +++++++++---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> >diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
> >index fdd9661d..1d0c791e 100644
> >--- a/tests/i915/gem_exec_reloc.c
> >+++ b/tests/i915/gem_exec_reloc.c
> >@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
> > uint64_t gtt_size = gem_aperture_size(fd);
> > const uint32_t bbe = MI_BATCH_BUFFER_END;
> > igt_spin_t *spin = NULL;
> >- int count, n;
> >+ int count, n, err;
> >
> > igt_require(gem_has_softpin(fd));
> >
> >@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> > execbuf.buffer_count = 1;
> >- if (__gem_execbuf(fd, &execbuf))
> >+ err = __gem_execbuf(fd, &execbuf);
> >+ if (err) {
> >+ igt_assert(err != -EINVAL);
> > continue;
>
> The addresses to which the object is being pinned is generated as part
> of the test. The code is just assuming that the address needs to be 4K
> aligned instead of figuring out what the alignment requirement for the
> device is.
>
> Shouldn't the test be updated to generate virtual addresses per the
> alignment requirements of the test device instead of just assuming 4K
> increments are good?
You're perfectly right, and that's what I've been trying to achieve in my
series https://lists.freedesktop.org/archives/igt-dev/2019-October/017081.html.
As suggested by Chris (https://lists.freedesktop.org/archives/igt-dev/2019-October/016936.html),
I've been trying to add a library function that detects the alignment
requirement of a device. We haven't agreed yet on necessity of my approach to
distinguish failures caused by incorrect offset alignment from those which are
simply coming from addresses being occupied by other users, and how to do
that distinction. In my current approach, I'm retrying at different offsets
to conclude possible failure reasons, but maybe error codes can be used for
that.
Back to this patch, skipping over invalid offsets, calculated from incorrectly
assumed or detected alignment requirements still seems wrong to me, anyway.
That's the reason for this patch.
Thanks,
Janusz
>
> Vanshi
>
> >+ }
> >
> > igt_debug("obj[%d] handle=%d, address=%llx\n",
> > n, obj[n].handle, (long long)obj[n].offset);
> >@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> > execbuf.buffer_count = 1;
> >- if (__gem_execbuf(fd, &execbuf))
> >+ err = __gem_execbuf(fd, &execbuf);
> >+ if (err) {
> >+ igt_assert(err != -EINVAL);
> > continue;
> >+ }
> >
> > igt_debug("obj[%d] handle=%d, address=%llx\n",
> > n, obj[n].handle, (long long)obj[n].offset);
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v3] tests/gem_exec_reloc: Don't filter out invalid addresses
@ 2019-10-31 7:40 ` Janusz Krzysztofik
0 siblings, 0 replies; 10+ messages in thread
From: Janusz Krzysztofik @ 2019-10-31 7:40 UTC (permalink / raw)
To: Vanshidhar Konda; +Cc: igt-dev, intel-gfx
On Wednesday, October 30, 2019 10:19:43 PM CET Vanshidhar Konda wrote:
> On Wed, Oct 30, 2019 at 06:15:35PM +0100, Janusz Krzysztofik wrote:
> >Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> >addresses for !ppgtt") introduced filtering of addresses possibly
> >occupied by other users of shared GTT. Unfortunately, that filtering
> >doesn't distinguish actually occupied addresses from otherwise invalid
> >softpin offsets. For example, on a future hardware backing store with
> >a page size larger than 4 kB incorrect object alignment is assumed and
> >the test results are distorted as it happily skips over incorrectly
> >aligned objects instead of reporting the problem.
> >
> >Filter out failing addresses only if not reported as invalid.
> >
> >Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> >Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >---
> > tests/i915/gem_exec_reloc.c | 12 +++++++++---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> >diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
> >index fdd9661d..1d0c791e 100644
> >--- a/tests/i915/gem_exec_reloc.c
> >+++ b/tests/i915/gem_exec_reloc.c
> >@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
> > uint64_t gtt_size = gem_aperture_size(fd);
> > const uint32_t bbe = MI_BATCH_BUFFER_END;
> > igt_spin_t *spin = NULL;
> >- int count, n;
> >+ int count, n, err;
> >
> > igt_require(gem_has_softpin(fd));
> >
> >@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> > execbuf.buffer_count = 1;
> >- if (__gem_execbuf(fd, &execbuf))
> >+ err = __gem_execbuf(fd, &execbuf);
> >+ if (err) {
> >+ igt_assert(err != -EINVAL);
> > continue;
>
> The addresses to which the object is being pinned is generated as part
> of the test. The code is just assuming that the address needs to be 4K
> aligned instead of figuring out what the alignment requirement for the
> device is.
>
> Shouldn't the test be updated to generate virtual addresses per the
> alignment requirements of the test device instead of just assuming 4K
> increments are good?
You're perfectly right, and that's what I've been trying to achieve in my
series https://lists.freedesktop.org/archives/igt-dev/2019-October/017081.html.
As suggested by Chris (https://lists.freedesktop.org/archives/igt-dev/2019-October/016936.html),
I've been trying to add a library function that detects the alignment
requirement of a device. We haven't agreed yet on necessity of my approach to
distinguish failures caused by incorrect offset alignment from those which are
simply coming from addresses being occupied by other users, and how to do
that distinction. In my current approach, I'm retrying at different offsets
to conclude possible failure reasons, but maybe error codes can be used for
that.
Back to this patch, skipping over invalid offsets, calculated from incorrectly
assumed or detected alignment requirements still seems wrong to me, anyway.
That's the reason for this patch.
Thanks,
Janusz
>
> Vanshi
>
> >+ }
> >
> > igt_debug("obj[%d] handle=%d, address=%llx\n",
> > n, obj[n].handle, (long long)obj[n].offset);
> >@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> > execbuf.buffer_count = 1;
> >- if (__gem_execbuf(fd, &execbuf))
> >+ err = __gem_execbuf(fd, &execbuf);
> >+ if (err) {
> >+ igt_assert(err != -EINVAL);
> > continue;
> >+ }
> >
> > igt_debug("obj[%d] handle=%d, address=%llx\n",
> > n, obj[n].handle, (long long)obj[n].offset);
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [igt-dev] [RFC PATCH i-g-t v3] tests/gem_exec_reloc: Don't filter out invalid addresses
@ 2019-10-31 16:22 ` Vanshidhar Konda
0 siblings, 0 replies; 10+ messages in thread
From: Vanshidhar Konda @ 2019-10-31 16:22 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev, intel-gfx
On Thu, Oct 31, 2019 at 08:40:58AM +0100, Janusz Krzysztofik wrote:
>On Wednesday, October 30, 2019 10:19:43 PM CET Vanshidhar Konda wrote:
>> On Wed, Oct 30, 2019 at 06:15:35PM +0100, Janusz Krzysztofik wrote:
>> >Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
>> >addresses for !ppgtt") introduced filtering of addresses possibly
>> >occupied by other users of shared GTT. Unfortunately, that filtering
>> >doesn't distinguish actually occupied addresses from otherwise invalid
>> >softpin offsets. For example, on a future hardware backing store with
>> >a page size larger than 4 kB incorrect object alignment is assumed and
>> >the test results are distorted as it happily skips over incorrectly
>> >aligned objects instead of reporting the problem.
>> >
>> >Filter out failing addresses only if not reported as invalid.
>> >
>> >Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
>> >Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> >---
>> > tests/i915/gem_exec_reloc.c | 12 +++++++++---
>> > 1 file changed, 9 insertions(+), 3 deletions(-)
>> >
>> >diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
>> >index fdd9661d..1d0c791e 100644
>> >--- a/tests/i915/gem_exec_reloc.c
>> >+++ b/tests/i915/gem_exec_reloc.c
>> >@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
>> > uint64_t gtt_size = gem_aperture_size(fd);
>> > const uint32_t bbe = MI_BATCH_BUFFER_END;
>> > igt_spin_t *spin = NULL;
>> >- int count, n;
>> >+ int count, n, err;
>> >
>> > igt_require(gem_has_softpin(fd));
>> >
>> >@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
>> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
>> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
>> > execbuf.buffer_count = 1;
>> >- if (__gem_execbuf(fd, &execbuf))
>> >+ err = __gem_execbuf(fd, &execbuf);
>> >+ if (err) {
>> >+ igt_assert(err != -EINVAL);
>> > continue;
>>
>> The addresses to which the object is being pinned is generated as part
>> of the test. The code is just assuming that the address needs to be 4K
>> aligned instead of figuring out what the alignment requirement for the
>> device is.
>>
>> Shouldn't the test be updated to generate virtual addresses per the
>> alignment requirements of the test device instead of just assuming 4K
>> increments are good?
>
>You're perfectly right, and that's what I've been trying to achieve in my
>series https://lists.freedesktop.org/archives/igt-dev/2019-October/017081.html.
Thanks for providing the context for the changes.
>As suggested by Chris (https://lists.freedesktop.org/archives/igt-dev/2019-October/016936.html),
>I've been trying to add a library function that detects the alignment
>requirement of a device. We haven't agreed yet on necessity of my approach to
>distinguish failures caused by incorrect offset alignment from those which are
>simply coming from addresses being occupied by other users, and how to do
For a context that has just been created, I would assume that the PPGTTs would be
empty as no object should be mapped by default in it. With this
assumption, is it safe to assume that unaligned addresses would be the
only ones that return an EINVAL error?
I'll take a look at the latest version of the patch series for this.
Thanks,
Vanshi
>that distinction. In my current approach, I'm retrying at different offsets
>to conclude possible failure reasons, but maybe error codes can be used for
>that.
>
>Back to this patch, skipping over invalid offsets, calculated from incorrectly
>assumed or detected alignment requirements still seems wrong to me, anyway.
>That's the reason for this patch.
>
>Thanks,
>Janusz
>
>
>>
>> Vanshi
>>
>> >+ }
>> >
>> > igt_debug("obj[%d] handle=%d, address=%llx\n",
>> > n, obj[n].handle, (long long)obj[n].offset);
>> >@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
>> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
>> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
>> > execbuf.buffer_count = 1;
>> >- if (__gem_execbuf(fd, &execbuf))
>> >+ err = __gem_execbuf(fd, &execbuf);
>> >+ if (err) {
>> >+ igt_assert(err != -EINVAL);
>> > continue;
>> >+ }
>> >
>> > igt_debug("obj[%d] handle=%d, address=%llx\n",
>> > n, obj[n].handle, (long long)obj[n].offset);
>>
>
>
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Intel-gfx] [igt-dev] [RFC PATCH i-g-t v3] tests/gem_exec_reloc: Don't filter out invalid addresses
@ 2019-10-31 16:22 ` Vanshidhar Konda
0 siblings, 0 replies; 10+ messages in thread
From: Vanshidhar Konda @ 2019-10-31 16:22 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev, intel-gfx
On Thu, Oct 31, 2019 at 08:40:58AM +0100, Janusz Krzysztofik wrote:
>On Wednesday, October 30, 2019 10:19:43 PM CET Vanshidhar Konda wrote:
>> On Wed, Oct 30, 2019 at 06:15:35PM +0100, Janusz Krzysztofik wrote:
>> >Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
>> >addresses for !ppgtt") introduced filtering of addresses possibly
>> >occupied by other users of shared GTT. Unfortunately, that filtering
>> >doesn't distinguish actually occupied addresses from otherwise invalid
>> >softpin offsets. For example, on a future hardware backing store with
>> >a page size larger than 4 kB incorrect object alignment is assumed and
>> >the test results are distorted as it happily skips over incorrectly
>> >aligned objects instead of reporting the problem.
>> >
>> >Filter out failing addresses only if not reported as invalid.
>> >
>> >Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
>> >Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> >---
>> > tests/i915/gem_exec_reloc.c | 12 +++++++++---
>> > 1 file changed, 9 insertions(+), 3 deletions(-)
>> >
>> >diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
>> >index fdd9661d..1d0c791e 100644
>> >--- a/tests/i915/gem_exec_reloc.c
>> >+++ b/tests/i915/gem_exec_reloc.c
>> >@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
>> > uint64_t gtt_size = gem_aperture_size(fd);
>> > const uint32_t bbe = MI_BATCH_BUFFER_END;
>> > igt_spin_t *spin = NULL;
>> >- int count, n;
>> >+ int count, n, err;
>> >
>> > igt_require(gem_has_softpin(fd));
>> >
>> >@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
>> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
>> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
>> > execbuf.buffer_count = 1;
>> >- if (__gem_execbuf(fd, &execbuf))
>> >+ err = __gem_execbuf(fd, &execbuf);
>> >+ if (err) {
>> >+ igt_assert(err != -EINVAL);
>> > continue;
>>
>> The addresses to which the object is being pinned is generated as part
>> of the test. The code is just assuming that the address needs to be 4K
>> aligned instead of figuring out what the alignment requirement for the
>> device is.
>>
>> Shouldn't the test be updated to generate virtual addresses per the
>> alignment requirements of the test device instead of just assuming 4K
>> increments are good?
>
>You're perfectly right, and that's what I've been trying to achieve in my
>series https://lists.freedesktop.org/archives/igt-dev/2019-October/017081.html.
Thanks for providing the context for the changes.
>As suggested by Chris (https://lists.freedesktop.org/archives/igt-dev/2019-October/016936.html),
>I've been trying to add a library function that detects the alignment
>requirement of a device. We haven't agreed yet on necessity of my approach to
>distinguish failures caused by incorrect offset alignment from those which are
>simply coming from addresses being occupied by other users, and how to do
For a context that has just been created, I would assume that the PPGTTs would be
empty as no object should be mapped by default in it. With this
assumption, is it safe to assume that unaligned addresses would be the
only ones that return an EINVAL error?
I'll take a look at the latest version of the patch series for this.
Thanks,
Vanshi
>that distinction. In my current approach, I'm retrying at different offsets
>to conclude possible failure reasons, but maybe error codes can be used for
>that.
>
>Back to this patch, skipping over invalid offsets, calculated from incorrectly
>assumed or detected alignment requirements still seems wrong to me, anyway.
>That's the reason for this patch.
>
>Thanks,
>Janusz
>
>
>>
>> Vanshi
>>
>> >+ }
>> >
>> > igt_debug("obj[%d] handle=%d, address=%llx\n",
>> > n, obj[n].handle, (long long)obj[n].offset);
>> >@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
>> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
>> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
>> > execbuf.buffer_count = 1;
>> >- if (__gem_execbuf(fd, &execbuf))
>> >+ err = __gem_execbuf(fd, &execbuf);
>> >+ if (err) {
>> >+ igt_assert(err != -EINVAL);
>> > continue;
>> >+ }
>> >
>> > igt_debug("obj[%d] handle=%d, address=%llx\n",
>> > n, obj[n].handle, (long long)obj[n].offset);
>>
>
>
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 10+ messages in thread
* [igt-dev] ✓ Fi.CI.IGT: success for tests/gem_exec_reloc: Don't filter out invalid addresses
2019-10-30 17:15 ` [Intel-gfx] " Janusz Krzysztofik
` (2 preceding siblings ...)
(?)
@ 2019-10-31 19:03 ` Patchwork
-1 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2019-10-31 19:03 UTC (permalink / raw)
To: Janusz Krzysztofik; +Cc: igt-dev
== Series Details ==
Series: tests/gem_exec_reloc: Don't filter out invalid addresses
URL : https://patchwork.freedesktop.org/series/68779/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7226_full -> IGTPW_3634_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in IGTPW_3634_full:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render:
- {shard-tglb}: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-tglb2/igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-tglb8/igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-render.html
Known issues
------------
Here are the changes found in IGTPW_3634_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_isolation@vcs1-none:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb2/igt@gem_ctx_isolation@vcs1-none.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb7/igt@gem_ctx_isolation@vcs1-none.html
* igt@gem_ctx_isolation@vecs0-s3:
- shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-apl7/igt@gem_ctx_isolation@vecs0-s3.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-apl6/igt@gem_ctx_isolation@vecs0-s3.html
* igt@gem_exec_parallel@vcs1-fds:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112080]) +6 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb4/igt@gem_exec_parallel@vcs1-fds.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb6/igt@gem_exec_parallel@vcs1-fds.html
* igt@gem_exec_schedule@out-order-bsd2:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +12 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb2/igt@gem_exec_schedule@out-order-bsd2.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb7/igt@gem_exec_schedule@out-order-bsd2.html
* igt@gem_exec_schedule@preempt-other-bsd:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb5/igt@gem_exec_schedule@preempt-other-bsd.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb2/igt@gem_exec_schedule@preempt-other-bsd.html
* igt@gem_persistent_relocs@forked-interruptible-thrashing:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#112037])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb8/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb4/igt@gem_persistent_relocs@forked-interruptible-thrashing.html
* igt@gem_userptr_blits@map-fixed-invalidate-busy:
- shard-hsw: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) +1 similar issue
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-hsw6/igt@gem_userptr_blits@map-fixed-invalidate-busy.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-hsw8/igt@gem_userptr_blits@map-fixed-invalidate-busy.html
* igt@gem_userptr_blits@sync-unmap:
- shard-snb: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) +1 similar issue
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-snb4/igt@gem_userptr_blits@sync-unmap.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-snb1/igt@gem_userptr_blits@sync-unmap.html
* igt@i915_selftest@live_hangcheck:
- shard-hsw: [PASS][19] -> [DMESG-FAIL][20] ([fdo#111991])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-hsw2/igt@i915_selftest@live_hangcheck.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-hsw6/igt@i915_selftest@live_hangcheck.html
* igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +4 similar issues
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb2/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb6/igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) +7 similar issues
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-kbl1/igt@kms_frontbuffer_tracking@fbc-suspend.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-kbl4/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-iclb: [PASS][25] -> [INCOMPLETE][26] ([fdo#107713])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb6/igt@kms_plane@plane-position-covered-pipe-b-planes.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb7/igt@kms_plane@plane-position-covered-pipe-b-planes.html
* igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-iclb: [PASS][27] -> [FAIL][28] ([fdo#103166])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-y.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb8/igt@kms_plane_lowres@pipe-a-tiling-y.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][29] -> [SKIP][30] ([fdo#109441]) +2 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb1/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][31] -> [FAIL][32] ([fdo#99912])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-apl3/igt@kms_setmode@basic.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-apl7/igt@kms_setmode@basic.html
#### Possible fixes ####
* igt@gem_ctx_isolation@rcs0-s3:
- {shard-tglb}: [INCOMPLETE][33] ([fdo#111832]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-tglb5/igt@gem_ctx_isolation@rcs0-s3.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-tglb2/igt@gem_ctx_isolation@rcs0-s3.html
* {igt@gem_ctx_persistence@bcs0-queued}:
- shard-iclb: [FAIL][35] ([fdo#112180]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb1/igt@gem_ctx_persistence@bcs0-queued.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb4/igt@gem_ctx_persistence@bcs0-queued.html
- {shard-tglb}: [FAIL][37] ([fdo#112180]) -> [PASS][38] +1 similar issue
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-tglb4/igt@gem_ctx_persistence@bcs0-queued.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-tglb7/igt@gem_ctx_persistence@bcs0-queued.html
* {igt@gem_ctx_persistence@vcs1-mixed-process}:
- shard-iclb: [SKIP][39] ([fdo#109276] / [fdo#112080]) -> [PASS][40] +3 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb6/igt@gem_ctx_persistence@vcs1-mixed-process.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb1/igt@gem_ctx_persistence@vcs1-mixed-process.html
* igt@gem_ctx_switch@vcs1:
- shard-iclb: [SKIP][41] ([fdo#112080]) -> [PASS][42] +9 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb6/igt@gem_ctx_switch@vcs1.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb1/igt@gem_ctx_switch@vcs1.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [SKIP][43] ([fdo#110854]) -> [PASS][44]
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb5/igt@gem_exec_balancer@smoke.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb1/igt@gem_exec_balancer@smoke.html
* igt@gem_exec_blt@dumb-buf:
- shard-iclb: [INCOMPLETE][45] ([fdo#107713]) -> [PASS][46] +1 similar issue
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb4/igt@gem_exec_blt@dumb-buf.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb8/igt@gem_exec_blt@dumb-buf.html
* igt@gem_exec_schedule@preempt-hang-bsd1:
- shard-iclb: [SKIP][47] ([fdo#109276]) -> [PASS][48] +13 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb5/igt@gem_exec_schedule@preempt-hang-bsd1.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb4/igt@gem_exec_schedule@preempt-hang-bsd1.html
* igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [SKIP][49] ([fdo#112146]) -> [PASS][50] +7 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb2/igt@gem_exec_schedule@preemptive-hang-bsd.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb8/igt@gem_exec_schedule@preemptive-hang-bsd.html
* igt@gem_mmap_gtt@medium-copy-xy:
- {shard-tglb}: [INCOMPLETE][51] ([fdo#111747]) -> [PASS][52] +2 similar issues
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-tglb1/igt@gem_mmap_gtt@medium-copy-xy.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-tglb8/igt@gem_mmap_gtt@medium-copy-xy.html
* igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing:
- shard-kbl: [FAIL][53] ([fdo#112037]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-kbl1/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-kbl4/igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [DMESG-WARN][55] ([fdo#108566]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-apl4/igt@gem_softpin@noreloc-s3.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-apl8/igt@gem_softpin@noreloc-s3.html
* igt@gem_userptr_blits@sync-unmap-after-close:
- shard-hsw: [DMESG-WARN][57] ([fdo#111870]) -> [PASS][58] +3 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-hsw6/igt@gem_userptr_blits@sync-unmap-after-close.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-hsw1/igt@gem_userptr_blits@sync-unmap-after-close.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-snb: [DMESG-WARN][59] ([fdo#111870]) -> [PASS][60] +1 similar issue
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-snb7/igt@gem_userptr_blits@sync-unmap-cycles.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-snb5/igt@gem_userptr_blits@sync-unmap-cycles.html
* {igt@i915_pm_dc@dc6-psr}:
- shard-iclb: [FAIL][61] ([fdo#110548]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb2/igt@i915_pm_dc@dc6-psr.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb5/igt@i915_pm_dc@dc6-psr.html
* igt@i915_pm_rpm@system-suspend:
- {shard-tglb}: [INCOMPLETE][63] ([fdo#111747] / [fdo#111850]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-tglb2/igt@i915_pm_rpm@system-suspend.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-tglb7/igt@i915_pm_rpm@system-suspend.html
* igt@kms_flip@flip-vs-modeset-interruptible:
- shard-hsw: [DMESG-WARN][65] ([fdo#102614]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-hsw5/igt@kms_flip@flip-vs-modeset-interruptible.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-hsw1/igt@kms_flip@flip-vs-modeset-interruptible.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu:
- {shard-tglb}: [INCOMPLETE][67] ([fdo#111884]) -> [PASS][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-cpu.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render:
- shard-iclb: [FAIL][69] ([fdo#103167]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb6/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbcpsr-shrfb-scaledprimary:
- {shard-tglb}: [FAIL][71] ([fdo#103167]) -> [PASS][72] +4 similar issues
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-tglb8/igt@kms_frontbuffer_tracking@fbcpsr-shrfb-scaledprimary.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-tglb7/igt@kms_frontbuffer_tracking@fbcpsr-shrfb-scaledprimary.html
* igt@kms_frontbuffer_tracking@fbcpsr-suspend:
- {shard-tglb}: [INCOMPLETE][73] ([fdo#111832] / [fdo#111850] / [fdo#111884]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-tglb4/igt@kms_frontbuffer_tracking@fbcpsr-suspend.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- shard-kbl: [DMESG-WARN][75] ([fdo#103313]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-kbl2/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-kbl4/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl: [DMESG-WARN][77] ([fdo#108566]) -> [PASS][78] +3 similar issues
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-kbl2/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-kbl3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- {shard-tglb}: [INCOMPLETE][79] ([fdo#111832] / [fdo#111850]) -> [PASS][80]
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-tglb4/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-tglb6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [SKIP][81] ([fdo#109441]) -> [PASS][82] +1 similar issue
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb3/igt@kms_psr@psr2_primary_page_flip.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
#### Warnings ####
* igt@gem_exec_schedule@preempt-queue-contexts-bsd2:
- shard-iclb: [INCOMPLETE][83] ([fdo#107713]) -> [SKIP][84] ([fdo#109276])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb1/igt@gem_exec_schedule@preempt-queue-contexts-bsd2.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb8/igt@gem_exec_schedule@preempt-queue-contexts-bsd2.html
* igt@gem_mocs_settings@mocs-settings-bsd2:
- shard-iclb: [FAIL][85] ([fdo#111330]) -> [SKIP][86] ([fdo#109276])
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7226/shard-iclb4/igt@gem_mocs_settings@mocs-settings-bsd2.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/shard-iclb6/igt@gem_mocs_settings@mocs-settings-bsd2.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103313]: https://bugs.freedesktop.org/show_bug.cgi?id=103313
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#110548]: https://bugs.freedesktop.org/show_bug.cgi?id=110548
[fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[fdo#111330]: https://bugs.freedesktop.org/show_bug.cgi?id=111330
[fdo#111646]: https://bugs.freedesktop.org/show_bug.cgi?id=111646
[fdo#111671]: https://bugs.freedesktop.org/show_bug.cgi?id=111671
[fdo#111703]: https://bugs.freedesktop.org/show_bug.cgi?id=111703
[fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
[fdo#111736]: https://bugs.freedesktop.org/show_bug.cgi?id=111736
[fdo#111747]: https://bugs.freedesktop.org/show_bug.cgi?id=111747
[fdo#111832]: https://bugs.freedesktop.org/show_bug.cgi?id=111832
[fdo#111850]: https://bugs.freedesktop.org/show_bug.cgi?id=111850
[fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
[fdo#111884]: https://bugs.freedesktop.org/show_bug.cgi?id=111884
[fdo#111991]: https://bugs.freedesktop.org/show_bug.cgi?id=111991
[fdo#112037]: https://bugs.freedesktop.org/show_bug.cgi?id=112037
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112180]: https://bugs.freedesktop.org/show_bug.cgi?id=112180
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (11 -> 8)
------------------------------
Missing (3): pig-skl-6260u pig-glk-j5005 pig-hsw-4770r
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5253 -> IGTPW_3634
* Piglit: piglit_4509 -> None
CI-20190529: 20190529
CI_DRM_7226: 6190cecae6196d219ea9a19c16a81598141c68af @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_3634: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/index.html
IGT_5253: d46ccb32cf693e8d8253543e9a4fbe5eaef4aa41 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3634/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-10-31 19:03 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-30 17:15 [RFC PATCH i-g-t v3] tests/gem_exec_reloc: Don't filter out invalid addresses Janusz Krzysztofik
2019-10-30 17:15 ` [Intel-gfx] " Janusz Krzysztofik
2019-10-30 18:03 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2019-10-30 21:19 ` [igt-dev] [RFC PATCH i-g-t v3] " Vanshidhar Konda
2019-10-30 21:19 ` [Intel-gfx] " Vanshidhar Konda
2019-10-31 7:40 ` Janusz Krzysztofik
2019-10-31 7:40 ` [Intel-gfx] " Janusz Krzysztofik
2019-10-31 16:22 ` Vanshidhar Konda
2019-10-31 16:22 ` [Intel-gfx] " Vanshidhar Konda
2019-10-31 19:03 ` [igt-dev] ✓ Fi.CI.IGT: success for " Patchwork
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.