* [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
@ 2020-12-15 20:31 ` Chris Wilson
0 siblings, 0 replies; 14+ messages in thread
From: Chris Wilson @ 2020-12-15 20:31 UTC (permalink / raw)
To: intel-gfx; +Cc: Chris Wilson, CQ Tang, stable
When inserting a VMA, we restrict the placement to the low 4G unless the
caller opts into using the full range. This was done to allow usersapce
the opportunity to transition slowly from a 32b address space, and to
avoid breaking inherent 32b assumptions of some commands.
However, for insert we limited ourselves to 4G-4K, but on verification
we allowed the full 4G. This causes some attempts to bind a new buffer
to sporadically fail with -ENOSPC, but at other times be bound
successfully.
commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
page") suggests that there is a genuine problem with stateless addressing
that cannot utilize the last page in 4G and so we purposefully excluded
it.
Reported-by: CQ Tang <cq.tang@intel.com>
Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: CQ Tang <cq.tang@intel.com>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 193996144c84..2ff32daa50bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -382,7 +382,7 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2 *entry,
return true;
if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
- (vma->node.start + vma->node.size - 1) >> 32)
+ (vma->node.start + vma->node.size + 4095) >> 32)
return true;
if (flags & __EXEC_OBJECT_NEEDS_MAP &&
--
2.20.1
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
@ 2020-12-15 20:31 ` Chris Wilson
0 siblings, 0 replies; 14+ messages in thread
From: Chris Wilson @ 2020-12-15 20:31 UTC (permalink / raw)
To: intel-gfx; +Cc: stable, Chris Wilson
When inserting a VMA, we restrict the placement to the low 4G unless the
caller opts into using the full range. This was done to allow usersapce
the opportunity to transition slowly from a 32b address space, and to
avoid breaking inherent 32b assumptions of some commands.
However, for insert we limited ourselves to 4G-4K, but on verification
we allowed the full 4G. This causes some attempts to bind a new buffer
to sporadically fail with -ENOSPC, but at other times be bound
successfully.
commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
page") suggests that there is a genuine problem with stateless addressing
that cannot utilize the last page in 4G and so we purposefully excluded
it.
Reported-by: CQ Tang <cq.tang@intel.com>
Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: CQ Tang <cq.tang@intel.com>
Cc: stable@vger.kernel.org
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 193996144c84..2ff32daa50bd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -382,7 +382,7 @@ eb_vma_misplaced(const struct drm_i915_gem_exec_object2 *entry,
return true;
if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
- (vma->node.start + vma->node.size - 1) >> 32)
+ (vma->node.start + vma->node.size + 4095) >> 32)
return true;
if (flags & __EXEC_OBJECT_NEEDS_MAP &&
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 14+ messages in thread
* RE: [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-15 20:31 ` [Intel-gfx] " Chris Wilson
@ 2020-12-15 21:50 ` Tang, CQ
-1 siblings, 0 replies; 14+ messages in thread
From: Tang, CQ @ 2020-12-15 21:50 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: stable
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Tuesday, December 15, 2020 12:31 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ <cq.tang@intel.com>;
> stable@vger.kernel.org
> Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check and
> vma insert
>
> When inserting a VMA, we restrict the placement to the low 4G unless the
> caller opts into using the full range. This was done to allow usersapce the
> opportunity to transition slowly from a 32b address space, and to avoid
> breaking inherent 32b assumptions of some commands.
>
> However, for insert we limited ourselves to 4G-4K, but on verification we
> allowed the full 4G. This causes some attempts to bind a new buffer to
> sporadically fail with -ENOSPC, but at other times be bound successfully.
>
> commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> page") suggests that there is a genuine problem with stateless addressing
> that cannot utilize the last page in 4G and so we purposefully excluded it.
>
> Reported-by: CQ Tang <cq.tang@intel.com>
> Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> page")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: CQ Tang <cq.tang@intel.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 193996144c84..2ff32daa50bd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> drm_i915_gem_exec_object2 *entry,
> return true;
>
> if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> - (vma->node.start + vma->node.size - 1) >> 32)
> + (vma->node.start + vma->node.size + 4095) >> 32)
Why 4095 not 4096?
--CQ
> return true;
>
> if (flags & __EXEC_OBJECT_NEEDS_MAP &&
> --
> 2.20.1
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
@ 2020-12-15 21:50 ` Tang, CQ
0 siblings, 0 replies; 14+ messages in thread
From: Tang, CQ @ 2020-12-15 21:50 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: stable
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Tuesday, December 15, 2020 12:31 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ <cq.tang@intel.com>;
> stable@vger.kernel.org
> Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check and
> vma insert
>
> When inserting a VMA, we restrict the placement to the low 4G unless the
> caller opts into using the full range. This was done to allow usersapce the
> opportunity to transition slowly from a 32b address space, and to avoid
> breaking inherent 32b assumptions of some commands.
>
> However, for insert we limited ourselves to 4G-4K, but on verification we
> allowed the full 4G. This causes some attempts to bind a new buffer to
> sporadically fail with -ENOSPC, but at other times be bound successfully.
>
> commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> page") suggests that there is a genuine problem with stateless addressing
> that cannot utilize the last page in 4G and so we purposefully excluded it.
>
> Reported-by: CQ Tang <cq.tang@intel.com>
> Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> page")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: CQ Tang <cq.tang@intel.com>
> Cc: stable@vger.kernel.org
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 193996144c84..2ff32daa50bd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> drm_i915_gem_exec_object2 *entry,
> return true;
>
> if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> - (vma->node.start + vma->node.size - 1) >> 32)
> + (vma->node.start + vma->node.size + 4095) >> 32)
Why 4095 not 4096?
--CQ
> return true;
>
> if (flags & __EXEC_OBJECT_NEEDS_MAP &&
> --
> 2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-15 21:50 ` [Intel-gfx] " Tang, CQ
(?)
@ 2020-12-15 22:02 ` Chris Wilson
2020-12-15 22:33 ` Tang, CQ
2020-12-16 0:51 ` Tang, CQ
-1 siblings, 2 replies; 14+ messages in thread
From: Chris Wilson @ 2020-12-15 22:02 UTC (permalink / raw)
To: Tang, CQ, intel-gfx; +Cc: stable
Quoting Tang, CQ (2020-12-15 21:50:53)
>
>
> > -----Original Message-----
> > From: Chris Wilson <chris@chris-wilson.co.uk>
> > Sent: Tuesday, December 15, 2020 12:31 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ <cq.tang@intel.com>;
> > stable@vger.kernel.org
> > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check and
> > vma insert
> >
> > When inserting a VMA, we restrict the placement to the low 4G unless the
> > caller opts into using the full range. This was done to allow usersapce the
> > opportunity to transition slowly from a 32b address space, and to avoid
> > breaking inherent 32b assumptions of some commands.
> >
> > However, for insert we limited ourselves to 4G-4K, but on verification we
> > allowed the full 4G. This causes some attempts to bind a new buffer to
> > sporadically fail with -ENOSPC, but at other times be bound successfully.
> >
> > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > page") suggests that there is a genuine problem with stateless addressing
> > that cannot utilize the last page in 4G and so we purposefully excluded it.
> >
> > Reported-by: CQ Tang <cq.tang@intel.com>
> > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > page")
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: CQ Tang <cq.tang@intel.com>
> > Cc: stable@vger.kernel.org
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > index 193996144c84..2ff32daa50bd 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > drm_i915_gem_exec_object2 *entry,
> > return true;
> >
> > if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > - (vma->node.start + vma->node.size - 1) >> 32)
> > + (vma->node.start + vma->node.size + 4095) >> 32)
>
> Why 4095 not 4096?
It's the nature of the test that we need an inclusive bound.
Consider an object of size 4G - 4K, that is allowed to fit within our 32b
GTT.
4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
4G - 4k + 4k - 1 = 4G -1 = 0xffffffff => vma ok
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-15 22:02 ` Chris Wilson
@ 2020-12-15 22:33 ` Tang, CQ
2020-12-16 0:51 ` Tang, CQ
1 sibling, 0 replies; 14+ messages in thread
From: Tang, CQ @ 2020-12-15 22:33 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: stable@
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Tuesday, December 15, 2020 2:02 PM
> To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: stable@ <vger.kernel.org stable@vger.kernel.org>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced
> vma check and vma insert
>
> Quoting Tang, CQ (2020-12-15 21:50:53)
> >
> >
> > > -----Original Message-----
> > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > Sent: Tuesday, December 15, 2020 12:31 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ
> > > <cq.tang@intel.com>; stable@vger.kernel.org
> > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check
> > > and vma insert
> > >
> > > When inserting a VMA, we restrict the placement to the low 4G unless
> > > the caller opts into using the full range. This was done to allow
> > > usersapce the opportunity to transition slowly from a 32b address
> > > space, and to avoid breaking inherent 32b assumptions of some
> commands.
> > >
> > > However, for insert we limited ourselves to 4G-4K, but on
> > > verification we allowed the full 4G. This causes some attempts to
> > > bind a new buffer to sporadically fail with -ENOSPC, but at other times be
> bound successfully.
> > >
> > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > page") suggests that there is a genuine problem with stateless
> > > addressing that cannot utilize the last page in 4G and so we purposefully
> excluded it.
> > >
> > > Reported-by: CQ Tang <cq.tang@intel.com>
> > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > page")
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: CQ Tang <cq.tang@intel.com>
> > > Cc: stable@vger.kernel.org
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > index 193996144c84..2ff32daa50bd 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > > drm_i915_gem_exec_object2 *entry,
> > > return true;
> > >
> > > if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > > - (vma->node.start + vma->node.size - 1) >> 32)
> > > + (vma->node.start + vma->node.size + 4095) >> 32)
> >
> > Why 4095 not 4096?
>
> It's the nature of the test that we need an inclusive bound.
>
> Consider an object of size 4G - 4K, that is allowed to fit within our 32b GTT.
>
> 4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
>
> 4G - 4k + 4k - 1 = 4G -1 = 0xffffffff => vma ok
Yes, the checking in i915_vma_insert() is ">" not ">="
if (size > end) {
DRM_DEBUG("Attempting to bind an object larger than the aperture: request=%llu > %s aperture=%llu\n",
size, flags & PIN_MAPPABLE ? "mappable" : "total",
end);
return -ENOSPC;
}
Reviewed-by: CQ Tang <cq.tang@intel.com>
>
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-15 20:31 ` [Intel-gfx] " Chris Wilson
(?)
(?)
@ 2020-12-15 23:41 ` Patchwork
-1 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2020-12-15 23:41 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 4624 bytes --]
== Series Details ==
Series: drm/i915: Fix mismatch between misplaced vma check and vma insert
URL : https://patchwork.freedesktop.org/series/84975/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9489 -> Patchwork_19150
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/index.html
Known issues
------------
Here are the changes found in Patchwork_19150 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_cs_nop@nop-gfx0:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-apl-guc/igt@amdgpu/amd_cs_nop@nop-gfx0.html
* igt@gem_exec_suspend@basic-s0:
- fi-snb-2600: [PASS][2] -> [DMESG-WARN][3] ([i915#2772])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-snb-2600/igt@gem_exec_suspend@basic-s0.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-snb-2600/igt@gem_exec_suspend@basic-s0.html
* igt@i915_module_load@reload:
- fi-kbl-7500u: [PASS][4] -> [DMESG-WARN][5] ([i915#2605])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-kbl-7500u/igt@i915_module_load@reload.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-kbl-7500u/igt@i915_module_load@reload.html
* igt@kms_psr@primary_page_flip:
- fi-glk-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +21 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-glk-dsi/igt@kms_psr@primary_page_flip.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][7] ([i915#2029] / [i915#2722])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-bdw-5557u/igt@runner@aborted.html
* igt@vgem_basic@create:
- fi-tgl-y: [PASS][8] -> [DMESG-WARN][9] ([i915#402]) +2 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@vgem_basic@create.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-tgl-y/igt@vgem_basic@create.html
#### Possible fixes ####
* igt@i915_selftest@live@gt_timelines:
- fi-apl-guc: [INCOMPLETE][10] ([i915#2750]) -> [PASS][11]
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-apl-guc/igt@i915_selftest@live@gt_timelines.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-glk-dsi: [INCOMPLETE][12] ([i915#2377]) -> [PASS][13]
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-glk-dsi/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-glk-dsi/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a.html
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [DMESG-WARN][14] ([i915#402]) -> [PASS][15] +2 similar issues
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2377]: https://gitlab.freedesktop.org/drm/intel/issues/2377
[i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#2750]: https://gitlab.freedesktop.org/drm/intel/issues/2750
[i915#2772]: https://gitlab.freedesktop.org/drm/intel/issues/2772
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (43 -> 39)
------------------------------
Missing (4): fi-ctg-p8600 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-------------
* Linux: CI_DRM_9489 -> Patchwork_19150
CI-20190529: 20190529
CI_DRM_9489: bef2104ec6e0aa163b1b01b661e734b08b567aeb @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5902: 1c1fc6c4d506dc69d8e85b09bcb932466712d416 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19150: 0077303b2c4369d3cf3565ee1b3b7c5f3890d209 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0077303b2c43 drm/i915: Fix mismatch between misplaced vma check and vma insert
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/index.html
[-- Attachment #1.2: Type: text/html, Size: 5579 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-15 22:02 ` Chris Wilson
2020-12-15 22:33 ` Tang, CQ
@ 2020-12-16 0:51 ` Tang, CQ
2020-12-16 8:43 ` Chris Wilson
1 sibling, 1 reply; 14+ messages in thread
From: Tang, CQ @ 2020-12-16 0:51 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: stable@
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Tuesday, December 15, 2020 2:02 PM
> To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: stable@ <vger.kernel.org stable@vger.kernel.org>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced
> vma check and vma insert
>
> Quoting Tang, CQ (2020-12-15 21:50:53)
> >
> >
> > > -----Original Message-----
> > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > Sent: Tuesday, December 15, 2020 12:31 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ
> > > <cq.tang@intel.com>; stable@vger.kernel.org
> > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check
> > > and vma insert
> > >
> > > When inserting a VMA, we restrict the placement to the low 4G unless
> > > the caller opts into using the full range. This was done to allow
> > > usersapce the opportunity to transition slowly from a 32b address
> > > space, and to avoid breaking inherent 32b assumptions of some
> commands.
> > >
> > > However, for insert we limited ourselves to 4G-4K, but on
> > > verification we allowed the full 4G. This causes some attempts to
> > > bind a new buffer to sporadically fail with -ENOSPC, but at other times be
> bound successfully.
> > >
> > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > page") suggests that there is a genuine problem with stateless
> > > addressing that cannot utilize the last page in 4G and so we purposefully
> excluded it.
> > >
> > > Reported-by: CQ Tang <cq.tang@intel.com>
> > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > page")
> > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > Cc: CQ Tang <cq.tang@intel.com>
> > > Cc: stable@vger.kernel.org
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > index 193996144c84..2ff32daa50bd 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > > drm_i915_gem_exec_object2 *entry,
> > > return true;
> > >
> > > if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > > - (vma->node.start + vma->node.size - 1) >> 32)
> > > + (vma->node.start + vma->node.size + 4095) >> 32)
> >
> > Why 4095 not 4096?
>
> It's the nature of the test that we need an inclusive bound.
>
> Consider an object of size 4G - 4K, that is allowed to fit within our 32b GTT.
>
> 4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
>
> 4G - 4k + 4k - 1 = 4G -1 = 0xffffffff => vma ok
How do we trigger this code? I run gem_exec_params@larger-than-life-batch but did not see this code is executed.
Basically how do we triggre first attempt to pin the object in place.
--CQ
>
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-15 20:31 ` [Intel-gfx] " Chris Wilson
` (2 preceding siblings ...)
(?)
@ 2020-12-16 5:35 ` Patchwork
-1 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2020-12-16 5:35 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 17368 bytes --]
== Series Details ==
Series: drm/i915: Fix mismatch between misplaced vma check and vma insert
URL : https://patchwork.freedesktop.org/series/84975/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9489_full -> Patchwork_19150_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_19150_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_19150_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_19150_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_parallel@contexts@rcs0:
- shard-skl: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl5/igt@gem_exec_parallel@contexts@rcs0.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl3/igt@gem_exec_parallel@contexts@rcs0.html
* igt@gem_exec_params@larger-than-life-batch:
- shard-iclb: [PASS][3] -> [FAIL][4]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb3/igt@gem_exec_params@larger-than-life-batch.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-iclb3/igt@gem_exec_params@larger-than-life-batch.html
- shard-tglb: [PASS][5] -> [FAIL][6]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb6/igt@gem_exec_params@larger-than-life-batch.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-tglb1/igt@gem_exec_params@larger-than-life-batch.html
Known issues
------------
Here are the changes found in Patchwork_19150_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][7] -> [SKIP][8] ([i915#2190])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb5/igt@gem_huc_copy@huc-copy.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-tglb6/igt@gem_huc_copy@huc-copy.html
* igt@gem_pread@exhaustion:
- shard-apl: NOTRUN -> [WARN][9] ([i915#2658])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-apl3/igt@gem_pread@exhaustion.html
* igt@gem_render_copy@linear-to-vebox-y-tiled:
- shard-skl: NOTRUN -> [SKIP][10] ([fdo#109271]) +11 similar issues
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl6/igt@gem_render_copy@linear-to-vebox-y-tiled.html
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#146] / [i915#198])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl7/igt@i915_suspend@fence-restore-tiled2untiled.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl6/igt@i915_suspend@fence-restore-tiled2untiled.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-90:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271]) +2 similar issues
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-glk5/igt@kms_big_fb@x-tiled-32bpp-rotate-90.html
* igt@kms_color@pipe-b-ctm-0-25:
- shard-skl: [PASS][14] -> [DMESG-WARN][15] ([i915#1982]) +1 similar issue
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl3/igt@kms_color@pipe-b-ctm-0-25.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl3/igt@kms_color@pipe-b-ctm-0-25.html
* igt@kms_color_chamelium@pipe-a-ctm-red-to-blue:
- shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-apl3/igt@kms_color_chamelium@pipe-a-ctm-red-to-blue.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#2405] / [i915#300])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl2/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl4/igt@kms_cursor_crc@pipe-b-cursor-suspend.html
* igt@kms_cursor_crc@pipe-c-cursor-128x128-offscreen:
- shard-skl: [PASS][19] -> [FAIL][20] ([i915#54])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl7/igt@kms_cursor_crc@pipe-c-cursor-128x128-offscreen.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl6/igt@kms_cursor_crc@pipe-c-cursor-128x128-offscreen.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl: [PASS][21] -> [FAIL][22] ([i915#79]) +1 similar issue
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl1/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl1/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2:
- shard-glk: [PASS][23] -> [FAIL][24] ([i915#79])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-glk7/igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-glk7/igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2.html
* igt@kms_flip@plain-flip-ts-check@a-edp1:
- shard-skl: [PASS][25] -> [FAIL][26] ([i915#2122])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl5/igt@kms_flip@plain-flip-ts-check@a-edp1.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl3/igt@kms_flip@plain-flip-ts-check@a-edp1.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [PASS][27] -> [FAIL][28] ([fdo#108145] / [i915#265])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl10/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.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_9489/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-iclb7/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@perf@blocking:
- shard-skl: [PASS][31] -> [FAIL][32] ([i915#1542])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl8/igt@perf@blocking.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl2/igt@perf@blocking.html
* igt@prime_vgem@fence-write-hang:
- shard-apl: NOTRUN -> [SKIP][33] ([fdo#109271]) +12 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-apl3/igt@prime_vgem@fence-write-hang.html
#### Possible fixes ####
* igt@drm_mm@all@evict:
- shard-skl: [INCOMPLETE][34] ([i915#2295]) -> [PASS][35]
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl4/igt@drm_mm@all@evict.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl8/igt@drm_mm@all@evict.html
* igt@gem_exec_capture@pi@rcs0:
- shard-skl: [INCOMPLETE][36] ([i915#2369] / [i915#2502]) -> [PASS][37]
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl8/igt@gem_exec_capture@pi@rcs0.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl2/igt@gem_exec_capture@pi@rcs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-glk: [DMESG-WARN][38] ([i915#118] / [i915#95]) -> [PASS][39]
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-glk2/igt@gem_exec_flush@basic-batch-kernel-default-uc.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-glk7/igt@gem_exec_flush@basic-batch-kernel-default-uc.html
* {igt@gem_exec_schedule@u-fairslice@vcs0}:
- shard-apl: [DMESG-WARN][40] ([i915#1610]) -> [PASS][41]
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-apl7/igt@gem_exec_schedule@u-fairslice@vcs0.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-apl3/igt@gem_exec_schedule@u-fairslice@vcs0.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [FAIL][42] ([i915#644]) -> [PASS][43]
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-glk9/igt@gem_ppgtt@flink-and-close-vma-leak.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-glk4/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-hsw: [WARN][44] ([i915#1519]) -> [PASS][45]
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-hsw4/igt@i915_pm_rc6_residency@rc6-idle.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-hsw7/igt@i915_pm_rc6_residency@rc6-idle.html
* igt@i915_selftest@live@active:
- shard-skl: [DMESG-FAIL][46] ([i915#2291]) -> [PASS][47]
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl9/igt@i915_selftest@live@active.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl10/igt@i915_selftest@live@active.html
* igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl: [FAIL][48] ([i915#2521]) -> [PASS][49]
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl8/igt@kms_async_flips@alternate-sync-async-flip.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl4/igt@kms_async_flips@alternate-sync-async-flip.html
- shard-kbl: [FAIL][50] ([i915#2521]) -> [PASS][51]
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-kbl7/igt@kms_async_flips@alternate-sync-async-flip.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-kbl3/igt@kms_async_flips@alternate-sync-async-flip.html
* igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen:
- shard-skl: [FAIL][52] ([i915#54]) -> [PASS][53] +4 similar issues
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl9/igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl10/igt@kms_cursor_crc@pipe-c-cursor-64x21-offscreen.html
* igt@kms_cursor_legacy@flip-vs-cursor-toggle:
- shard-tglb: [FAIL][54] ([i915#2346]) -> [PASS][55]
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-tglb7/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-tglb1/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-skl: [INCOMPLETE][56] ([i915#146] / [i915#198]) -> [PASS][57]
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl1/igt@kms_fbcon_fbt@psr-suspend.html
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl9/igt@kms_fbcon_fbt@psr-suspend.html
* igt@kms_flip@2x-flip-vs-modeset-vs-hang@ab-hdmi-a1-hdmi-a2:
- shard-glk: [INCOMPLETE][58] -> [PASS][59]
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-glk7/igt@kms_flip@2x-flip-vs-modeset-vs-hang@ab-hdmi-a1-hdmi-a2.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-glk5/igt@kms_flip@2x-flip-vs-modeset-vs-hang@ab-hdmi-a1-hdmi-a2.html
* igt@kms_flip@2x-plain-flip-fb-recreate@ac-vga1-hdmi-a1:
- shard-hsw: [FAIL][60] ([i915#2122]) -> [PASS][61]
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-hsw6/igt@kms_flip@2x-plain-flip-fb-recreate@ac-vga1-hdmi-a1.html
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-hsw2/igt@kms_flip@2x-plain-flip-fb-recreate@ac-vga1-hdmi-a1.html
* igt@kms_flip@plain-flip-fb-recreate@b-edp1:
- shard-skl: [FAIL][62] ([i915#2122]) -> [PASS][63] +1 similar issue
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl7/igt@kms_flip@plain-flip-fb-recreate@b-edp1.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl6/igt@kms_flip@plain-flip-fb-recreate@b-edp1.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [FAIL][64] ([i915#1188]) -> [PASS][65] +1 similar issue
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-skl5/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_psr@psr2_dpms:
- shard-iclb: [SKIP][66] ([fdo#109441]) -> [PASS][67] +1 similar issue
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb1/igt@kms_psr@psr2_dpms.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-iclb2/igt@kms_psr@psr2_dpms.html
* {igt@perf@non-zero-reason}:
- shard-iclb: [FAIL][68] -> [PASS][69]
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb5/igt@perf@non-zero-reason.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-iclb5/igt@perf@non-zero-reason.html
#### Warnings ####
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-iclb: [WARN][70] ([i915#2681] / [i915#2684]) -> [WARN][71] ([i915#1804] / [i915#2684])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-iclb8/igt@i915_pm_rc6_residency@rc6-fence.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-iclb4/igt@i915_pm_rc6_residency@rc6-fence.html
* igt@runner@aborted:
- shard-apl: ([FAIL][72], [FAIL][73]) ([i915#1610] / [i915#2295] / [i915#2426] / [i915#2722]) -> [FAIL][74] ([i915#2295] / [i915#2722])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-apl7/igt@runner@aborted.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9489/shard-apl8/igt@runner@aborted.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/shard-apl6/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#1519]: https://gitlab.freedesktop.org/drm/intel/issues/1519
[i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
[i915#1610]: https://gitlab.freedesktop.org/drm/intel/issues/1610
[i915#1804]: https://gitlab.freedesktop.org/drm/intel/issues/1804
[i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#2295]: https://gitlab.freedesktop.org/drm/intel/issues/2295
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2369]: https://gitlab.freedesktop.org/drm/intel/issues/2369
[i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2502]: https://gitlab.freedesktop.org/drm/intel/issues/2502
[i915#2521]: https://gitlab.freedesktop.org/drm/intel/issues/2521
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
[i915#2681]: https://gitlab.freedesktop.org/drm/intel/issues/2681
[i915#2684]: https://gitlab.freedesktop.org/drm/intel/issues/2684
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#300]: https://gitlab.freedesktop.org/drm/intel/issues/300
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* Linux: CI_DRM_9489 -> Patchwork_19150
CI-20190529: 20190529
CI_DRM_9489: bef2104ec6e0aa163b1b01b661e734b08b567aeb @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5902: 1c1fc6c4d506dc69d8e85b09bcb932466712d416 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19150: 0077303b2c4369d3cf3565ee1b3b7c5f3890d209 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19150/index.html
[-- Attachment #1.2: Type: text/html, Size: 20008 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-16 0:51 ` Tang, CQ
@ 2020-12-16 8:43 ` Chris Wilson
2020-12-16 9:19 ` Matthew Auld
2020-12-16 17:27 ` Tang, CQ
0 siblings, 2 replies; 14+ messages in thread
From: Chris Wilson @ 2020-12-16 8:43 UTC (permalink / raw)
To: Tang, CQ, intel-gfx; +Cc: , vger.kernel.orgstable
Quoting Tang, CQ (2020-12-16 00:51:21)
>
>
> > -----Original Message-----
> > From: Chris Wilson <chris@chris-wilson.co.uk>
> > Sent: Tuesday, December 15, 2020 2:02 PM
> > To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: stable@ <vger.kernel.org stable@vger.kernel.org>
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced
> > vma check and vma insert
> >
> > Quoting Tang, CQ (2020-12-15 21:50:53)
> > >
> > >
> > > > -----Original Message-----
> > > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Sent: Tuesday, December 15, 2020 12:31 PM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ
> > > > <cq.tang@intel.com>; stable@vger.kernel.org
> > > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check
> > > > and vma insert
> > > >
> > > > When inserting a VMA, we restrict the placement to the low 4G unless
> > > > the caller opts into using the full range. This was done to allow
> > > > usersapce the opportunity to transition slowly from a 32b address
> > > > space, and to avoid breaking inherent 32b assumptions of some
> > commands.
> > > >
> > > > However, for insert we limited ourselves to 4G-4K, but on
> > > > verification we allowed the full 4G. This causes some attempts to
> > > > bind a new buffer to sporadically fail with -ENOSPC, but at other times be
> > bound successfully.
> > > >
> > > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > > page") suggests that there is a genuine problem with stateless
> > > > addressing that cannot utilize the last page in 4G and so we purposefully
> > excluded it.
> > > >
> > > > Reported-by: CQ Tang <cq.tang@intel.com>
> > > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > > page")
> > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Cc: CQ Tang <cq.tang@intel.com>
> > > > Cc: stable@vger.kernel.org
> > > > ---
> > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > index 193996144c84..2ff32daa50bd 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > > > drm_i915_gem_exec_object2 *entry,
> > > > return true;
> > > >
> > > > if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > > > - (vma->node.start + vma->node.size - 1) >> 32)
> > > > + (vma->node.start + vma->node.size + 4095) >> 32)
> > >
> > > Why 4095 not 4096?
> >
> > It's the nature of the test that we need an inclusive bound.
> >
> > Consider an object of size 4G - 4K, that is allowed to fit within our 32b GTT.
> >
> > 4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
> >
> > 4G - 4k + 4k - 1 = 4G -1 = 0xffffffff => vma ok
>
> How do we trigger this code? I run gem_exec_params@larger-than-life-batch but did not see this code is executed.
> Basically how do we triggre first attempt to pin the object in place.
It's the first pin tried, but the incoming execobj.offset must be
available and the object itself must be ready to be pinned. That's true
for the current tree on all current gen.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-16 8:43 ` Chris Wilson
@ 2020-12-16 9:19 ` Matthew Auld
2020-12-16 17:27 ` Tang, CQ
1 sibling, 0 replies; 14+ messages in thread
From: Matthew Auld @ 2020-12-16 9:19 UTC (permalink / raw)
To: Chris Wilson; +Cc: vger.kernel.orgstable, Intel Graphics Development
On Wed, 16 Dec 2020 at 08:43, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>
> Quoting Tang, CQ (2020-12-16 00:51:21)
> >
> >
> > > -----Original Message-----
> > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > Sent: Tuesday, December 15, 2020 2:02 PM
> > > To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> > > Cc: stable@ <vger.kernel.org stable@vger.kernel.org>
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced
> > > vma check and vma insert
> > >
> > > Quoting Tang, CQ (2020-12-15 21:50:53)
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Sent: Tuesday, December 15, 2020 12:31 PM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ
> > > > > <cq.tang@intel.com>; stable@vger.kernel.org
> > > > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma check
> > > > > and vma insert
> > > > >
> > > > > When inserting a VMA, we restrict the placement to the low 4G unless
> > > > > the caller opts into using the full range. This was done to allow
> > > > > usersapce the opportunity to transition slowly from a 32b address
> > > > > space, and to avoid breaking inherent 32b assumptions of some
> > > commands.
> > > > >
> > > > > However, for insert we limited ourselves to 4G-4K, but on
> > > > > verification we allowed the full 4G. This causes some attempts to
> > > > > bind a new buffer to sporadically fail with -ENOSPC, but at other times be
> > > bound successfully.
> > > > >
> > > > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > > > page") suggests that there is a genuine problem with stateless
> > > > > addressing that cannot utilize the last page in 4G and so we purposefully
> > > excluded it.
> > > > >
> > > > > Reported-by: CQ Tang <cq.tang@intel.com>
> > > > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1
> > > > > page")
> > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Cc: CQ Tang <cq.tang@intel.com>
> > > > > Cc: stable@vger.kernel.org
> > > > > ---
> > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > index 193996144c84..2ff32daa50bd 100644
> > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > > > > drm_i915_gem_exec_object2 *entry,
> > > > > return true;
> > > > >
> > > > > if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > > > > - (vma->node.start + vma->node.size - 1) >> 32)
> > > > > + (vma->node.start + vma->node.size + 4095) >> 32)
> > > >
> > > > Why 4095 not 4096?
> > >
> > > It's the nature of the test that we need an inclusive bound.
> > >
> > > Consider an object of size 4G - 4K, that is allowed to fit within our 32b GTT.
> > >
> > > 4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
> > >
> > > 4G - 4k + 4k - 1 = 4G -1 = 0xffffffff => vma ok
> >
> > How do we trigger this code? I run gem_exec_params@larger-than-life-batch but did not see this code is executed.
> > Basically how do we triggre first attempt to pin the object in place.
>
> It's the first pin tried, but the incoming execobj.offset must be
> available and the object itself must be ready to be pinned. That's true
> for the current tree on all current gen.
Missing the original mail so just replying here,
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
> -Chris
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-16 8:43 ` Chris Wilson
2020-12-16 9:19 ` Matthew Auld
@ 2020-12-16 17:27 ` Tang, CQ
2020-12-16 20:44 ` Chris Wilson
1 sibling, 1 reply; 14+ messages in thread
From: Tang, CQ @ 2020-12-16 17:27 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: stable@
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Wednesday, December 16, 2020 12:43 AM
> To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: stable@ <vger.kernel.orgstable@vger.kernel.org>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced
> vma check and vma insert
>
> Quoting Tang, CQ (2020-12-16 00:51:21)
> >
> >
> > > -----Original Message-----
> > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > Sent: Tuesday, December 15, 2020 2:02 PM
> > > To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> > > Cc: stable@ <vger.kernel.org stable@vger.kernel.org>
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between
> > > misplaced vma check and vma insert
> > >
> > > Quoting Tang, CQ (2020-12-15 21:50:53)
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Sent: Tuesday, December 15, 2020 12:31 PM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ
> > > > > <cq.tang@intel.com>; stable@vger.kernel.org
> > > > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma
> > > > > check and vma insert
> > > > >
> > > > > When inserting a VMA, we restrict the placement to the low 4G
> > > > > unless the caller opts into using the full range. This was done
> > > > > to allow usersapce the opportunity to transition slowly from a
> > > > > 32b address space, and to avoid breaking inherent 32b
> > > > > assumptions of some
> > > commands.
> > > > >
> > > > > However, for insert we limited ourselves to 4G-4K, but on
> > > > > verification we allowed the full 4G. This causes some attempts
> > > > > to bind a new buffer to sporadically fail with -ENOSPC, but at
> > > > > other times be
> > > bound successfully.
> > > > >
> > > > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to
> 4GB
> > > > > - 1
> > > > > page") suggests that there is a genuine problem with stateless
> > > > > addressing that cannot utilize the last page in 4G and so we
> > > > > purposefully
> > > excluded it.
> > > > >
> > > > > Reported-by: CQ Tang <cq.tang@intel.com>
> > > > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB
> > > > > - 1
> > > > > page")
> > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Cc: CQ Tang <cq.tang@intel.com>
> > > > > Cc: stable@vger.kernel.org
> > > > > ---
> > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > index 193996144c84..2ff32daa50bd 100644
> > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > > > > drm_i915_gem_exec_object2 *entry,
> > > > > return true;
> > > > >
> > > > > if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > > > > - (vma->node.start + vma->node.size - 1) >> 32)
> > > > > + (vma->node.start + vma->node.size + 4095) >> 32)
> > > >
> > > > Why 4095 not 4096?
> > >
> > > It's the nature of the test that we need an inclusive bound.
> > >
> > > Consider an object of size 4G - 4K, that is allowed to fit within our 32b GTT.
> > >
> > > 4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
> > >
> > > 4G - 4k + 4k - 1 = 4G -1 = 0xffffffff => vma ok
> >
> > How do we trigger this code? I run gem_exec_params@larger-than-life-
> batch but did not see this code is executed.
> > Basically how do we triggre first attempt to pin the object in place.
>
> It's the first pin tried, but the incoming execobj.offset must be available and
> the object itself must be ready to be pinned. That's true for the current tree
> on all current gen.
For gem_exec_params@larger-than-life-batch subtest, I only see i915_vma_misplaced() be called when EXEC_OBJECT_SUPPORTS_48B_ADDRESS flags is specified, and the test passes.
I want to catch the bug before you fixed here. So a 4GB object should be OK, because before your fix, i915_vma_misplaced() returns false.
I did specify execobj.offset=0, but the driver code goes to i915_vma_insert() directly and return -ENOSPC.
How do I make gem_exec_params@larger-than-life-batch code to catch this bug?
--CQ
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-16 17:27 ` Tang, CQ
@ 2020-12-16 20:44 ` Chris Wilson
2020-12-16 21:53 ` Tang, CQ
0 siblings, 1 reply; 14+ messages in thread
From: Chris Wilson @ 2020-12-16 20:44 UTC (permalink / raw)
To: Tang, CQ, intel-gfx; +Cc: , vger.kernel.orgstable
Quoting Tang, CQ (2020-12-16 17:27:40)
>
>
> > -----Original Message-----
> > From: Chris Wilson <chris@chris-wilson.co.uk>
> > Sent: Wednesday, December 16, 2020 12:43 AM
> > To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: stable@ <vger.kernel.orgstable@vger.kernel.org>
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced
> > vma check and vma insert
> >
> > Quoting Tang, CQ (2020-12-16 00:51:21)
> > >
> > >
> > > > -----Original Message-----
> > > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Sent: Tuesday, December 15, 2020 2:02 PM
> > > > To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> > > > Cc: stable@ <vger.kernel.org stable@vger.kernel.org>
> > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between
> > > > misplaced vma check and vma insert
> > > >
> > > > Quoting Tang, CQ (2020-12-15 21:50:53)
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > Sent: Tuesday, December 15, 2020 12:31 PM
> > > > > > To: intel-gfx@lists.freedesktop.org
> > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ
> > > > > > <cq.tang@intel.com>; stable@vger.kernel.org
> > > > > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced vma
> > > > > > check and vma insert
> > > > > >
> > > > > > When inserting a VMA, we restrict the placement to the low 4G
> > > > > > unless the caller opts into using the full range. This was done
> > > > > > to allow usersapce the opportunity to transition slowly from a
> > > > > > 32b address space, and to avoid breaking inherent 32b
> > > > > > assumptions of some
> > > > commands.
> > > > > >
> > > > > > However, for insert we limited ourselves to 4G-4K, but on
> > > > > > verification we allowed the full 4G. This causes some attempts
> > > > > > to bind a new buffer to sporadically fail with -ENOSPC, but at
> > > > > > other times be
> > > > bound successfully.
> > > > > >
> > > > > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to
> > 4GB
> > > > > > - 1
> > > > > > page") suggests that there is a genuine problem with stateless
> > > > > > addressing that cannot utilize the last page in 4G and so we
> > > > > > purposefully
> > > > excluded it.
> > > > > >
> > > > > > Reported-by: CQ Tang <cq.tang@intel.com>
> > > > > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB
> > > > > > - 1
> > > > > > page")
> > > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > Cc: CQ Tang <cq.tang@intel.com>
> > > > > > Cc: stable@vger.kernel.org
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > index 193996144c84..2ff32daa50bd 100644
> > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > > > > > drm_i915_gem_exec_object2 *entry,
> > > > > > return true;
> > > > > >
> > > > > > if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > > > > > - (vma->node.start + vma->node.size - 1) >> 32)
> > > > > > + (vma->node.start + vma->node.size + 4095) >> 32)
> > > > >
> > > > > Why 4095 not 4096?
> > > >
> > > > It's the nature of the test that we need an inclusive bound.
> > > >
> > > > Consider an object of size 4G - 4K, that is allowed to fit within our 32b GTT.
> > > >
> > > > 4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
> > > >
> > > > 4G - 4k + 4k - 1 = 4G -1 = 0xffffffff => vma ok
> > >
> > > How do we trigger this code? I run gem_exec_params@larger-than-life-
> > batch but did not see this code is executed.
> > > Basically how do we triggre first attempt to pin the object in place.
> >
> > It's the first pin tried, but the incoming execobj.offset must be available and
> > the object itself must be ready to be pinned. That's true for the current tree
> > on all current gen.
>
> For gem_exec_params@larger-than-life-batch subtest, I only see i915_vma_misplaced() be called when EXEC_OBJECT_SUPPORTS_48B_ADDRESS flags is specified, and the test passes.
> I want to catch the bug before you fixed here. So a 4GB object should be OK, because before your fix, i915_vma_misplaced() returns false.
> I did specify execobj.offset=0, but the driver code goes to i915_vma_insert() directly and return -ENOSPC.
>
> How do I make gem_exec_params@larger-than-life-batch code to catch this bug?
Prior to the patch, upstream on current gen would always take the fast
pin and hit the bug. It will only fail to take that path if it was not
_allowed_ to place the object at offset 0.
To explicitly test that the page is excluded we would use softpin.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert
2020-12-16 20:44 ` Chris Wilson
@ 2020-12-16 21:53 ` Tang, CQ
0 siblings, 0 replies; 14+ messages in thread
From: Tang, CQ @ 2020-12-16 21:53 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: stable@
> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Wednesday, December 16, 2020 12:44 PM
> To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: stable@ <vger.kernel.orgstable@vger.kernel.org>
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between misplaced
> vma check and vma insert
>
> Quoting Tang, CQ (2020-12-16 17:27:40)
> >
> >
> > > -----Original Message-----
> > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > Sent: Wednesday, December 16, 2020 12:43 AM
> > > To: Tang, CQ <cq.tang@intel.com>; intel-gfx@lists.freedesktop.org
> > > Cc: stable@ <vger.kernel.orgstable@vger.kernel.org>
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between
> > > misplaced vma check and vma insert
> > >
> > > Quoting Tang, CQ (2020-12-16 00:51:21)
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Sent: Tuesday, December 15, 2020 2:02 PM
> > > > > To: Tang, CQ <cq.tang@intel.com>;
> > > > > intel-gfx@lists.freedesktop.org
> > > > > Cc: stable@ <vger.kernel.org stable@vger.kernel.org>
> > > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix mismatch between
> > > > > misplaced vma check and vma insert
> > > > >
> > > > > Quoting Tang, CQ (2020-12-15 21:50:53)
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > > Sent: Tuesday, December 15, 2020 12:31 PM
> > > > > > > To: intel-gfx@lists.freedesktop.org
> > > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>; Tang, CQ
> > > > > > > <cq.tang@intel.com>; stable@vger.kernel.org
> > > > > > > Subject: [PATCH] drm/i915: Fix mismatch between misplaced
> > > > > > > vma check and vma insert
> > > > > > >
> > > > > > > When inserting a VMA, we restrict the placement to the low
> > > > > > > 4G unless the caller opts into using the full range. This
> > > > > > > was done to allow usersapce the opportunity to transition
> > > > > > > slowly from a 32b address space, and to avoid breaking
> > > > > > > inherent 32b assumptions of some
> > > > > commands.
> > > > > > >
> > > > > > > However, for insert we limited ourselves to 4G-4K, but on
> > > > > > > verification we allowed the full 4G. This causes some
> > > > > > > attempts to bind a new buffer to sporadically fail with
> > > > > > > -ENOSPC, but at other times be
> > > > > bound successfully.
> > > > > > >
> > > > > > > commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to
> > > 4GB
> > > > > > > - 1
> > > > > > > page") suggests that there is a genuine problem with
> > > > > > > stateless addressing that cannot utilize the last page in 4G
> > > > > > > and so we purposefully
> > > > > excluded it.
> > > > > > >
> > > > > > > Reported-by: CQ Tang <cq.tang@intel.com>
> > > > > > > Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to
> > > > > > > 4GB
> > > > > > > - 1
> > > > > > > page")
> > > > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > > Cc: CQ Tang <cq.tang@intel.com>
> > > > > > > Cc: stable@vger.kernel.org
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
> > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > index 193996144c84..2ff32daa50bd 100644
> > > > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > > > > > @@ -382,7 +382,7 @@ eb_vma_misplaced(const struct
> > > > > > > drm_i915_gem_exec_object2 *entry,
> > > > > > > return true;
> > > > > > >
> > > > > > > if (!(flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) &&
> > > > > > > - (vma->node.start + vma->node.size - 1) >> 32)
> > > > > > > + (vma->node.start + vma->node.size + 4095) >> 32)
> > > > > >
> > > > > > Why 4095 not 4096?
> > > > >
> > > > > It's the nature of the test that we need an inclusive bound.
> > > > >
> > > > > Consider an object of size 4G - 4K, that is allowed to fit within our 32b
> GTT.
> > > > >
> > > > > 4G - 4k + 4K = 4G == 1 << 32: => vma misplaced
> > > > >
> > > > > 4G - 4k + 4k - 1 = 4G -1 = 0xffffffff => vma ok
> > > >
> > > > How do we trigger this code? I run
> > > > gem_exec_params@larger-than-life-
> > > batch but did not see this code is executed.
> > > > Basically how do we triggre first attempt to pin the object in place.
> > >
> > > It's the first pin tried, but the incoming execobj.offset must be
> > > available and the object itself must be ready to be pinned. That's
> > > true for the current tree on all current gen.
> >
> > For gem_exec_params@larger-than-life-batch subtest, I only see
> i915_vma_misplaced() be called when
> EXEC_OBJECT_SUPPORTS_48B_ADDRESS flags is specified, and the test
> passes.
> > I want to catch the bug before you fixed here. So a 4GB object should be
> OK, because before your fix, i915_vma_misplaced() returns false.
> > I did specify execobj.offset=0, but the driver code goes to
> i915_vma_insert() directly and return -ENOSPC.
> >
> > How do I make gem_exec_params@larger-than-life-batch code to catch
> this bug?
>
> Prior to the patch, upstream on current gen would always take the fast pin
> and hit the bug. It will only fail to take that path if it was not _allowed_ to
> place the object at offset 0.
>
> To explicitly test that the page is excluded we would use softpin.
It looks the upstream code has different behavior than internal DII. With DII I used softpin flag, but did not see fast pin and hit the bug.
--CQ
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-12-16 21:53 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-15 20:31 [PATCH] drm/i915: Fix mismatch between misplaced vma check and vma insert Chris Wilson
2020-12-15 20:31 ` [Intel-gfx] " Chris Wilson
2020-12-15 21:50 ` Tang, CQ
2020-12-15 21:50 ` [Intel-gfx] " Tang, CQ
2020-12-15 22:02 ` Chris Wilson
2020-12-15 22:33 ` Tang, CQ
2020-12-16 0:51 ` Tang, CQ
2020-12-16 8:43 ` Chris Wilson
2020-12-16 9:19 ` Matthew Auld
2020-12-16 17:27 ` Tang, CQ
2020-12-16 20:44 ` Chris Wilson
2020-12-16 21:53 ` Tang, CQ
2020-12-15 23:41 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2020-12-16 5:35 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " 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.