Some return values are not useful and can be ignored. Wrap those cases
inside igt_ignore_warn(), not only to make sure compilers are happy but
also to clearly document our decisions.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 6 +++---
1 file changed, 3 insertions(+), 3
A pointer to fatal error messages can be passed around via hotunplug
structure, no need to declare it as global.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 92 +-
1 file changed, 45 insertions(+), 47 deletions(-)
diff --git a/tests
bodies.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
index a4071f51e..557f9e3fa 100644
--- a/tests/core_hotunplug.c
+++ b/tests
' function accordingly.
A side benefit of using the PCI device sysfs node, not the DRM one,
while removing the device is that a future subtest may now easily
perform both driver unbind and device remove operations in a row.
Suggested-by: Michał Winiarski
Signed-off-by: Janusz Krzysztofik
---
tests
Since health checks are now run from follow-up fixture sections, it is
safe to fail subtests without the need to abort the test execution. Do
that on device close errors instead of emitting warnings.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 8
1 file changed, 4
been exited with the marker set.
Also, precede health check operations with a driver rebind or bus
rescan attempt as needed.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 107 +
1 file changed, 75 insertions(+), 32 deletions(-)
diff --git
Since we no longer open a device DRM sysfs node, only a PCI one, driver
unbind operations are no longer affected by missed or unsuccessful
sysfs file close attempts. Skip only affected subtests if that
happens.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 9 +
1 file
.
For that to be possible, maintain a single instance of hotunplug
structure at igt_main level and pass it down to subtests.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 56 --
1 file changed, 26 insertions(+), 30 deletions(-)
diff --git a/tests
unplug operation
and a successful device health check, fail current test section right
after a device close error occurs, warn otherwise. If still running,
examine device file descriptor fields in subsequent igt_fixture
sections and skip on errors.
Signed-off-by: Janusz Krzysztofik
---
tests
A trailing newline is missing from one of fatal error messages, fix it.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/core_hotunplug.c b/tests/core_hotunplug.c
index 6ceb325ad..cac88c2f3 100644
--- a/tests
Return value of igt_device_filter_add() representing a number of
successfully installed device filters is now ignored. Fail if not 1.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/core_hotunplug.c b/tests
Hi Michał,
On Thu, 2020-06-25 at 21:57 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:14)
> > Even if all device file descriptors are closed on device hotunplug,
> > PRIME exported objects may still exists, referenced by still open
> > dma-b
Hi Michał,
On Thu, 2020-06-25 at 21:23 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:09)
> > Future subtests may want to access PCI attributes of the device after
> > driver unbind. Refactor prepare() helper.
> >
> > v2: rebase on u
Hi Michał,
Thanks for review.
On Thu, 2020-06-25 at 17:27 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:08)
> > The purpose of debug messages displayed by the test is to make
> > identification of a subtest phase that fails more easy. Since issue
Hi Michał,
On Thu, 2020-06-25 at 22:02 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:15)
> > Verify if a device with a GEM batch job still running on a GPU can be
> > hot-unplugged cleanly and released, then recovered.
> >
>
Hi Michał,
Thanks for review.
On Thu, 2020-06-25 at 21:51 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:13)
> > GEM objects belonging to user file descriptors still open on device
> > hotunplug may exhibit still more driver issues.
Hi Michał,
thanks for review.
On Thu, 2020-06-25 at 21:42 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:12)
> > Verify if an additional address space associated with an open device
> > file descriptor is cleaned up correctly on device hotunpl
Future subtests may want to access PCI attributes of the device after
driver unbind. Refactor prepare() helper.
v2: rebase on upstream
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 68 +-
1 file changed, 40 insertions(+), 28 deletions
Check if this 3-step procedure exhibits any issues with device recover
after unplug. Such issues may indicate insufficient device hardware
re-initialization performed by the device driver, or other kernel bugs
outside the driver code.
v2: rebase on upstream
Signed-off-by: Janusz Krzysztofik
Verify if an additional address space associated with an open device
file descriptor is cleaned up correctly on device hotunplug.
v2: rebase on upstream, update includes order
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 31 +++
1 file changed, 31
The purpose of debug messages displayed by the test is to make
identification of a subtest phase that fails more easy. Since issues
exhibited by the test are mostly reported to dmesg, print those debug
messages to /dev/kmsg as well.
v2: rebase on upstream
Signed-off-by: Janusz Krzysztofik
GEM objects belonging to user file descriptors still open on device
hotunplug may exhibit still more driver issues. Add a subtest that
implements this scenario.
v2: rebase on upstream
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 30 ++
1 file
Verify if a device with a GEM batch job still running on a GPU can be
hot-unplugged cleanly and released, then recovered.
v2: rebase on upstream
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 34 ++
1 file changed, 34 insertions(+)
diff --git
Add a bunch of new test variants, enhance debugging of hotunplug driver
issues.
v2: rebase on upstream
Janusz Krzysztofik (8):
tests/core_hotunplug: Duplicate debug messages in dmesg
tests/core_hotunplug: Use PCI device sysfs entry, not DRM
tests/core_hotunplug: Add unbind-unplug-rescan
on exercising the lateclose phase regardless of
potential rebind/re-plug issues under old names.
v2: rebase on upstream
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 57 +++---
1 file changed, 54 insertions(+), 3 deletions(-)
diff --git
Even if all device file descriptors are closed on device hotunplug,
PRIME exported objects may still exists, referenced by still open
dma-buf file handles. Add a subtest that keeps such handle open on
device hotunplug.
v2: rebase on upstream
Signed-off-by: Janusz Krzysztofik
---
tests
GEM objects belonging to user file descriptors still open on device
hotunplug may exhibit still more driver issues. Add a subtest that
implements this scenario.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 30 ++
1 file changed, 30 insertions
Verify if a device with a GEM batch job still running on a GPU can be
hot-unplugged cleanly and released, then recovered.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/tests/core_hotunplug.c b
on exercising the lateclose phase regardless of
potential rebind/re-plug issues under old names.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 57 +++---
1 file changed, 54 insertions(+), 3 deletions(-)
diff --git a/tests/core_hotunplug.c b
The purpose of debug messages displayed by the test is to make
identification of a subtest phase that fails more easy. Since issues
exhibited by the test are mostly reported to dmesg, print those debug
messages to /dev/kmsg as well.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c
Verify if an additional address space associated with an open device
file descriptor is cleaned up correctly on device hotunplug.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 32
1 file changed, 32 insertions(+)
diff --git a/tests
Even if all device file descriptors are closed on device hotunplug,
PRIME exported objects may still exists, referenced by still open
dma-buf file handles. Add a subtest that keeps such handle open on
device hotunplug.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 36
Add a bunch of new test variants, enhance debugging of hotunplug driver
issues.
Janusz Krzysztofik (8):
tests/core_hotunplug: Duplicate debug messages in dmesg
tests/core_hotunplug: Use PCI device sysfs entry, not DRM
tests/core_hotunplug: Add unbind-unplug-rescan variant
tests
Future subtests may want to access PCI attributes of the device after
driver unbind. Refactor prepare() helper.
Signed-off-by: Janusz Krzysztofik
---
tests/core_hotunplug.c | 68 +-
1 file changed, 40 insertions(+), 28 deletions(-)
diff --git a/tests
Check if this 3-step procedure exhibits any issues with device recover
after unplug. Such issues may indicate insufficient device hardware
re-initialization performed by the device driver, or other kernel bugs
outside the driver code.
Signed-off-by: Janusz Krzysztofik
---
tests
Hi Chris,
On Thu, 2020-05-28 at 14:41 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2020-05-28 14:34:42)
> > On 28/05/2020 13:10, Janusz Krzysztofik wrote:
> > > Hi Tvrtko,
> > >
> > > On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> > &
Hi Tvrtko,
On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> On 18/05/2020 19:17, Janusz Krzysztofik wrote:
> > Contexts associated with open device file descriptors together with
> > their assigned address spaces are now closed on device file close. On
>
> i915_ge
Hi Michał,
On Wed, 2020-05-27 at 21:15 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-05-18 20:17:20)
> > UC firmware is stored in a GEM object. Clean it up on driver remove to
>^ double whitespace
That's a result of
On Wed, 2020-05-27 at 21:12 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-05-18 20:17:19)
> > GGTT including its scratch page is not cleaned up until driver release.
> > Since DMA mappings still exist before scratch page cleanup, unmapping
> > them on la
eck the test requirements. For this we want to specify the baseline
> measurement timeout in milliseconds, allowing us to speed up our other
> baseline measurements elsewhere as well.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Janusz Krzysztofik
Thanks,
Janusz
> ---
>
The idea is to revoke DMA mappings on driver remove in order to work
around intel-iommu judging late unmapping on driver release after an
open device is removed as bugs. That also resolves runtime power
management warnings on late object removal.
Janusz Krzysztofik (4):
drm/i915: Drop user
81.341352] R13: 7ffcc5165850 R14: R15:
[ 81.343059] Modules linked in: i915 mfd_core intel_gtt prime_numbers
[ 81.345015] ---[ end trace 010aae55e56f8998 ]---
Signed-off-by: Janusz Krzysztofik
drm/i915: Defer GGTT vm address space fini to vm release
83] ? kthread_park+0x80/0x80
<4> [36.901792] ret_from_fork+0x24/0x50
<4> [36.901804] Modules linked in: mei_hdcp i915 x86_pkg_temp_thermal coretemp
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ax88179_178a usbnet mii
mei_me mei prime_numbers intel_lpss_pci
<4> [36.901857] ---[ end trace
77] softirqs last enabled at (204208): []
__do_softirq+0x395/0x49e
<4> [93.339307] softirqs last disabled at (204197): []
irq_exit+0xba/0xc0
<4> [93.339330] ---[ end trace f066187622b8c484 ]---
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
1 file cha
pclmul crc32_pclmul snd_hda_intel snd_intel_dspcfg snd_hda_codec
e1000e ax88179_178a usbnet snd_hwdep mii snd_hda_core ghash_clmulni_intel
snd_pcm ptp pps_core mei_me mei intel_lpss_pci prime_numbers
<4> [39.201764] ---[ end trace f3ec1bae3de04509 ]---
Signed-off-by: Janusz Krzysztof
if the subtest wants to use gem_test_engine() helper as
it reopens the device for its internal use and may certainly leave it
open on failure.
Provide a variant of the helper that doesn't reopen the device.
Signed-off-by: Janusz Krzysztofik
---
lib/i915/gem_submission.c | 31
Hi Chris,
On Fri, 2020-05-08 at 18:54 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-05-08 14:56:31)
> > static double nop_on_ring(int fd, uint32_t handle,
> > const struct intel_execution_engine2 *e, i
- by commit a0eebbddecaa ("igt/gem_exec_nop: Relax assertion for
parallel execution") to sum * 2.
With the criteria relaxed up to that extent, the purpose of that check
has been limited to a showcase for an old GuC failure. Since that is
now obsolete, kill that assert.
Suggested-by: Chri
subtests which don't require submicrosecond precision.
Janusz Krzysztofik (2):
tests/gem_exec_nop: Kill obsolete pass/fail metric
tests/gem_exec_nop: Remove submission batching
tests/i915/gem_exec_nop.c | 137 --
1 file changed, 59 insertions(+), 78 deletions
ze
(number of iterations), then update its users to initialize that
argument according to their individual requirements.
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_exec_nop.c | 120 +++---
1 file changed, 59 insertions(+), 61
til required.
>
> Signed-off-by: Chris Wilson
> Cc: Janusz Krzysztofik
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_obje
On Tue, 2020-04-28 at 15:48 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-04-28 15:35:03)
> > On Tue, 2020-04-28 at 13:59 +0100, Chris Wilson wrote:
> > > Quoting Janusz Krzysztofik (2020-04-28 13:45:13)
> > > > Hi Chris,
> > > >
> &
On Tue, 2020-04-28 at 13:59 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-04-28 13:45:13)
> > Hi Chris,
> >
> > On Fri, 2020-04-24 at 16:24 +0100, Chris Wilson wrote:
> > > We only need the device wakeref on freeing the objects if we have to
> >
Signed-off-by: Chris Wilson
> Cc: Janusz Krzysztofik
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 3 +++
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 9 +++--
> drivers/gpu/drm/i915/gt/intel_gtt.h| 1
that point.
Thanks,
Janusz
>
> Signed-off-by: Chris Wilson
> Cc: Janusz Krzysztofik
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 3 +++
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 9 +++--
> drivers/gpu/drm/
or taking car of this issue. Your solution looks very
promising to me at a first glance, but let me review it more thoroughly
and test it before I'm able to respond with an ack or R-b.
Thanks,
Janusz
>
> Signed-off-by: Chris Wilson
> Cc: Janusz Krzysztofik
> ---
> driv
From: Janusz Krzysztofik
There is a test which verifies unloading of i915 driver module but no
test exists that checks how a driver behaves when it gets unbound from
a device or when the device gets unplugged. Implement such test using
sysfs interface.
Two minimalistic subtests - "u
From: Janusz Krzysztofik
There is a test which verifies unloading of i915 driver module but no
test exists that checks how a driver behaves when it gets unbound from
a device or when the device gets unplugged. Implement such test using
sysfs interface.
Two minimalistic subtests - "u
From: Janusz Krzysztofik
There is a test which verifies unloading of i915 driver module but no
test exists that checks how a driver behaves when it gets unbound from
a device or when the device gets unplugged. Implement such test using
sysfs interface.
Two minimalistic subtests - "u
type if there are any.
v2: Clear 'map' before reuse (Zbigniew).
v3: Kill out-of-context errno check (Chris).
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Zbigniew Kempczyński
Cc: Chris Wilson
---
tests/i915/gem_userptr_blits.c | 111 -
1 file changed, 81
Refresh subtests which are still using pre-v4 MMAP_GTT API.
v2: Patch 2/2: clear 'map' before reuse (Zbigniew).
v3: Patch 2/2: kill out-of-context errno check (Chris).
Janusz Krzysztofik (2):
tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise
tests/gem_userptr_blits: Refresh
Upgrade the subtest to use MMAP_GTT API v4 (aka MMAP_OFFSET),
dynamically examine each mapping type supported by i915 driver.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Zbigniew Kempczyński
---
tests/i915/gem_userptr_blits.c | 21 -
1 file changed, 16 insertions(+), 5
From: Janusz Krzysztofik
There is a test which verifies unloading of i915 driver module but no
test exists that checks how a driver behaves when it gets unbound from
a device or when the device gets unplugged. Implement such test using
sysfs interface.
Two minimalistic subtests - "u
From: Janusz Krzysztofik
There is a test which verifies unloading of i915 driver module but no
test exists that checks how a driver behaves when it gets unbound from
a device or when the device gets unplugged. Implement such test using
sysfs interface.
Two minimalistic subtests - "u
Refresh subtests which are still using pre-v4 MMAP_GTT API.
v2: Patch 2/2: clear 'map' before reuse (Zbigniew).
Janusz Krzysztofik (2):
tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise
tests/gem_userptr_blits: Refresh other still MMAP_GTT dependent
subtests
tests/i915
Upgrade the subtest to use MMAP_GTT API v4 (aka MMAP_OFFSET),
dynamically examine each mapping type supported by i915 driver.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Zbigniew Kempczyński
---
tests/i915/gem_userptr_blits.c | 21 -
1 file changed, 16 insertions(+), 5
type if there are any.
v2: Clear 'map' before reuse (Zbigniew).
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Zbigniew Kempczyński
---
tests/i915/gem_userptr_blits.c | 111 -
1 file changed, 81 insertions(+), 30 deletions(-)
diff --git a/tests/i915
approach, looks still better.
Reviewed-and-Tested-by: Janusz Krzysztofik
Thanks,
Janusz
>
> Signed-off-by: Chris Wilson
> Cc: Janusz Krzysztofik
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 7 +
> drivers/gpu/drm/i915/gt/intel_en
the list before device attributes are destroyed
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Zbigniew Kempczyński
---
lib/igt_device_scan.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/lib/igt_device_scan.c b/lib/igt_device_scan.c
index cf7c4d951
that we never fail to park the engine due to
> oom.
>
> v2: Only use the mempool for nonblocking allocations which are not
> expected to fail.
LGTM. Thanks for addressing the issue.
Reviewed-by: Janusz Krzysztofik
Thanks,
Janusz
>
> Signed-off-by: Chris Wilson
> Cc: Janusz K
On Thu, 2020-04-02 at 11:42 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-04-02 11:36:21)
> > On Thu, 2020-04-02 at 11:32 +0100, Chris Wilson wrote:
> > > Quoting Janusz Krzysztofik (2020-04-02 11:28:03)
> > > > On Thu, 2020-04-02 at 1
On Thu, 2020-04-02 at 11:32 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-04-02 11:28:03)
> > On Thu, 2020-04-02 at 11:21 +0100, Chris Wilson wrote:
> > > Quoting Janusz Krzysztofik (2020-04-02 11:19:06)
> > > > On memory constrained syste
On Thu, 2020-04-02 at 11:21 +0100, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-04-02 11:19:06)
> > On memory constrained systems it may happen that no pages are available
> > for serving object creation attempt during engine park. Since we can
> > and we do ignor
On memory constrained systems it may happen that no pages are available
for serving object creation attempt during engine park. Since we can
and we do ignore that failure, let's suppress possible warnings from
page allocator to avoid confusion and make CI happy.
Signed-off-by: Janusz Krzysztofik
see below.
>
> On Tue, Mar 17, 2020 at 09:53:51AM +0100, Janusz Krzysztofik wrote:
> > Hi,
> >
> > On Mon, 2020-03-16 at 19:25 +, Patchwork wrote:
> > > == Series Details ==
> > >
> > > Series: tests/gem_userptr_blits: Refresh other now MMA
Hi,
On Mon, 2020-03-16 at 19:25 +, Patchwork wrote:
> == Series Details ==
>
> Series: tests/gem_userptr_blits: Refresh other now MMAP_GTT dependent
> subtests (rev2)
> URL : https://patchwork.freedesktop.org/series/74201/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes
Upgrade the subtest to use MMAP_GTT API v4 (aka MMAP_OFFSET),
dynamically examine each mapping type supported by i915 driver.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/tests
type if there are any.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 108 -
1 file changed, 79 insertions(+), 29 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index 975cd9dab..475200930 100644
Together with recently submitted patches, this series concludes
MMAP_OFFSET related changes required for gem_userptr_blits.
Thanks,
Janusz
Janusz Krzysztofik (2):
tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise
tests/gem_userptr_blits: Refresh other now MMAP_GTT dependent
On Thu, 2020-03-05 at 18:53 +0100, Janusz Krzysztofik wrote:
> The test already tried to use a working mapping by first trying legacy
> WC, then GTT. Use gem_mmap__device_coherent() helper instead of
> approaching its implementation locally.
>
> Signed-off-by: Janusz Krzysztofik
The test already tried to use a working mapping by first trying legacy
WC, then GTT. Use gem_mmap__device_coherent() helper instead of
approaching its implementation locally.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_exec_gttfill.c | 13 -
1 file changed, 4 insertions
Hi,
Here are my comments to CI results from testing the IGT changes on
Trybot with kernel change that prevents non-GTT mmap-offset mapping to
userptr reverted.
On Thu, 2020-03-05 at 06:15 +, Patchwork wrote:
> == Series Details ==
>
> Series: gem_userptr_blits: mmap-offset-invalidate
Message
From: Patchwork
Reply-To: intel-gfx-try...@lists.freedesktop.org
To: Janusz Krzysztofik
Cc: intel-gfx-try...@lists.freedesktop.org
Subject: ✓ Fi.CI.IGT: success for gem_userptr_blits: Refresh other now
MMAP_GTT dependent subtests
Date: Wed, 04 Mar 2020 11:24:45 -
== Series
It has been observed that mmap-offset-invalidate@wb subtest has never
triggered a lockdep loop complain. To fix it, don't use the ->domain
field of a mapping type being examined, always set read and write
domains to I915_GEM_DOMAIN_GTT instead.
Signed-off-by: Janusz Krzysztofik
---
tests/i
Add a variant that also attaches a igt_spin_t to the userptr, waits for
it to start executing, call igt_spin_set_timeout and then do the munmap.
Suggested-by: Chris Wilson
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 33 -
1 file
If mmap-offset over userptr fails, skip with respective message about
lockdep loop preventive failure occurrence only if ENODEV, fail
otherwise.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests
Janusz Krzysztofik (3):
tests/gem_userptr_blits: More effectively set pages before invalidation
tests/gem_userptr_blits: More exact detection of lockdep loop prevention
tests/gem_userptr_blits: Add active variant of mmap-offset-invalidate
tests/i915/gem_userptr_blits.c | 40
se" series,
still waiting for someone to provide a review) patches, this series
concludes MMAP_OFFSET related changes required for gem_userptr_blits,
I believe.
Thanks,
Janusz
Janusz Krzysztofik (2):
tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise
tests/gem_userptr_blits: Refres
type if there are any.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 108 -
1 file changed, 79 insertions(+), 29 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index efe34c512..3c659db0c 100644
Upgrade the subtest to use MMAP_GTT API v4 (aka MMAP_OFFSET),
dynamically examine each mapping type supported by i915 driver.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/tests
actually try to anger lockdep using gem_set_tiling() (Chris).
- rebase on top of "lib/i915: Restrict mmap types to GTT if no
MMAP_OFFSET support".
Janusz Krzysztofik (2):
tests/gem_userptr_blits: Exercise new invalid mapping types
tests/gem_userptr_blits: Try to anger lo
A currently unavoidable lockdep loop related to userptr MMU notifier
exists inside the i915 driver. For as long as that issue is not
resolved, operations which are believed to potentially result in the
loop being triggered are expected to fail early to prevent from that
badness to happen.
The
t; section,
- rebase on top of "lib/i915: Restrict mmap types to GTT if no
MMAP_OFFSET support".
Signed-off-by: Janusz Krzysztofik
Cc: Antonio Argenziano
---
tests/i915/gem_userptr_blits.c | 38 +++---
1 file changed, 21 insertions(+), 17 deletions(-)
mmap
types to GTT if no MMAP_OFFSET support").
Signed-off-by: Janusz Krzysztofik
Cc: Michał Winiarski
---
tests/i915/gem_userptr_blits.c | 43 +++---
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/
Hi Chris,
On Fri, 2020-02-21 at 14:28 +, Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-21 11:17:01)
> > Currently unavoidable lockedp loop related to userptr MMU notifier
> > exists in the i915 driver. For that reason, attempts to set up a
> > mmap-offset
Hi Chris,
Thanks for review.
On Friday, February 21, 2020 3:28:03 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-21 11:17:01)
> > Currently unavoidable lockedp loop related to userptr MMU notifier
> > exists in the i915 driver. For that reason, attempts to se
t; + return __batch_create(i915, 0);
> +}
> +
> +static unsigned int measure_inflight(int i915, unsigned int engine, int
> timeout)
> +{
> + IGT_CORK_FENCE(cork);
> + struct drm_i915_gem_exec_object2 obj = {
> + .handle = batch_create(i915)
> + };
> +
fset could redefine the macro back to its initial form for
internal use.
v2: Move extra condition to a separate function and call it via
for_each_if(), in case we need to fix it again in future (Chris)
v3: Fix blind copy-paste
Suggested-by: Michał Winiarski
Signed-off-by: Janusz Krzysztofik
Cc: Ch
ping to userptr".
Thanks,
Janusz
Janusz Krzysztofik (2):
lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
tests/gem_userptr_blits: Exercise mmap-offset mapping to userptr
lib/i915/gem_mman.c| 5
lib/i915/gem_mman.h| 7 --
tests/i915/gem_
Currently unavoidable lockedp loop related to userptr MMU notifier
exists in the i915 driver. For that reason, attempts to set up a
mmap-offset (or mmap-gtt) mapping to a userptr object may be now
preventively rejected by the driver.
A test should exists which checks for that. Would a mapping
501 - 600 of 808 matches
Mail list logo
