Quoting Andrew Morton (2020-08-21 23:34:12)
> On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel wrote:
>
> > The __apply_to_page_range() function is also used to change and/or
> > allocate page-table pages in the vmalloc area of the address space.
> > Make sure these changes get synchronized to
On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel wrote:
> The __apply_to_page_range() function is also used to change and/or
> allocate page-table pages in the vmalloc area of the address space.
> Make sure these changes get synchronized to other page-tables in the
> system by calling
On Fri, Aug 21, 2020 at 03:11:45PM +0530, Manna, Animesh wrote:
>
> On 16-07-2020 04:12, Manasi Navare wrote:
> >From: Maarten Lankhorst
> >
> >Small changes to intel_dp_mode_valid(), allow listing modes that
> >can only be supported in the bigjoiner configuration, which is
> >not supported yet.
Hi!
> > > The __apply_to_page_range() function is also used to change and/or
> > > allocate page-table pages in the vmalloc area of the address space.
> > > Make sure these changes get synchronized to other page-tables in the
> > > system by calling arch_sync_kernel_mappings() when necessary.
> >
Quoting Andrew Morton (2020-08-21 21:35:48)
> On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel wrote:
>
> > The __apply_to_page_range() function is also used to change and/or
> > allocate page-table pages in the vmalloc area of the address space.
> > Make sure these changes get synchronized to
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev5)
URL : https://patchwork.freedesktop.org/series/80542/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8914_full -> Patchwork_18389_full
On Fri, 21 Aug 2020 14:37:46 +0200 Joerg Roedel wrote:
> The __apply_to_page_range() function is also used to change and/or
> allocate page-table pages in the vmalloc area of the address space.
> Make sure these changes get synchronized to other page-tables in the
> system by calling
On Thu, Aug 20, 2020 at 2:31 PM Lyude Paul wrote:
>
> We're going to be doing the same probing process in nouveau for
> determining downstream DP port capabilities, so let's deduplicate the
> work by moving i915's code for handling this into a shared helper:
> drm_dp_downstream_read_info().
>
>
On Fri, Aug 21, 2020 at 5:38 AM Joerg Roedel wrote:
>
> From: Joerg Roedel
>
> The __apply_to_page_range() function is also used to change and/or
> allocate page-table pages in the vmalloc area of the address space.
> Make sure these changes get synchronized to other page-tables in the
> system
Quoting Joerg Roedel (2020-08-21 13:37:46)
> From: Joerg Roedel
>
> The __apply_to_page_range() function is also used to change and/or
> allocate page-table pages in the vmalloc area of the address space.
> Make sure these changes get synchronized to other page-tables in the
> system by calling
On Fri, Aug 21, 2020 at 03:46:48PM +0530, Manna, Animesh wrote:
>
> On 16-07-2020 04:12, Manasi Navare wrote:
> >From: Maarten Lankhorst
> >
> > When the clock is higher than the dotclock, try with 2 pipes enabled.
> > If we can enable 2, then we will go into big joiner mode, and steal
> >
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev5)
URL : https://patchwork.freedesktop.org/series/80542/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8914 -> Patchwork_18389
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev5)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev5)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9288d183ff61 drm/nouveau/kms: Fix some indenting in
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with
On Fri, 2020-08-21 at 01:37 +0300, Imre Deak wrote:
> On Wed, Aug 19, 2020 at 05:34:15PM -0400, Lyude Paul wrote:
> > (adding Ville and Imre to the cc here, they might be interested to know
> > about
> > this, comments down below)
> >
> > On Wed, 2020-08-19 at 11:15 -0400, Sean Paul wrote:
> > >
== Series Details ==
Series: mm: Track page table modifications in __apply_to_page_range()
URL : https://patchwork.freedesktop.org/series/80896/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8913_full -> Patchwork_18388_full
Subtests which don't remove the device, only unbind the driver from it,
seem relatively safe and harmless for CI. Remove them from the CI
blocklist.
Signed-off-by: Janusz Krzysztofik
---
tests/intel-ci/blacklist.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
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.
v3: Refresh.
Signed-off-by: Janusz
The test now ignores device close errors. Those errors are believed to
have no influence on device health so there is no need to process them
the same way as we mostly do on errors, i.e., notify CI about a problem
via igt_abort. However, those errors may indicate issues with the test
itself.
If a GPU gets wedged during driver rebind or device re-plug for some
reason, current hotunbind/hotunplug test variants may time out before
lateclose phase, resulting in incomplete CI reports. Rename those
variants to more adequate hotrebind/hotreplug-lateclose and add new
variants under the old
The test now assumes the i915 driver is able to identify potential
hardware or driver issues while rebinding to a device and indicate them
by marking the GPU wedged. Should that assumption occur wrong, the
health check phase of the test would happily succeed while potentially
leaving the device
Each subtest now calls a prepare() helper which opens a couple of files
required by that subtest. Those files are then closed after use,
either directly from the subtest body, or indirectly from inside one of
helper functions called during the subtest execution. That approach
not only makes
Don't rely on successful write to sysfs control files, assert existence
/ non-existence of a respective device sysfs node as well.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
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 just emitting warnings.
v2: Rebase only.
v3: Refresh.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał
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.
v2: Rebase only.
v3: Refresh.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał
The test now arms a timer before performing each driver unbind / rebind
or device unplug / bus rescan sysfs operation. Then in case of issues
we may prevent the driver from showing us if and how it can handle
them.
Don't arm the timer before sysfs operations which are essential for a
subtest.
Subtests now forcibly call or request igt_abort on failures in order to
avoid silently leaving an exercised device in an unusable state.
However, a failure inside a subtest doesn't always mean the device is
no longer working correctly and reboot is needed. On the other hand,
if a subtest just
Return values of driver bind/unbind / device remove/recover sysfs
operations are now ignored. Assert their correctness.
v2: Add trailing newlines missing from igt_assert messages.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 14 ++
There is a new library helper that asserts validity of open file
descriptors. Use it instead of open coding.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
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
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 6 +++---
1 file
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
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
We don't use drm_driver_open() since in case of an i915 device it keeps
an extra file descriptor of the exercised device open for exit handler
use, while we would like to be able to close the device completely
before running certain test operations. Instead, we call
__drm_driver_open() and handle
A pointer to fatal error messages can be passed around via hotunplug
structure, no need to declare it as global.
v2: Rebase only.
v3: Refresh.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 96 +-
1 file
The following changes to the test are planned:
- avoid global variables,
- skip subtest after device close errors,
- prepare invariant data only once per test run,
- move device health checks to igt_fixture sections,
- try to recover from subtest failures instead of aborting.
For that to be
Some debug messages which designate specific test operations, or their
greater parts at least, sound always the same, no matter which subtest
they are called from. Emit them, possibly updated with subtest
specified modifiers, from inside respective helpers instead of
duplicating them in subtest
Clean up the test code, add some new basic subtests, then unblock
unbind test variants.
Series changelog:
v2: New patch "Un-blocklist *bind* subtests added.
v3: Patch "Follow failed subtests with healthcheck" renamed to "Recover
from subtest failures".
- a new patche "Clean up device open
Device bus address structure field is always initialized with a pointer
to a substring of the device sysfs path and never used for its
modification. Declare it as a constant string.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Michał Winiarski
---
tests/core_hotunplug.c | 2 +-
1 file
== Series Details ==
Series: mm: Track page table modifications in __apply_to_page_range()
URL : https://patchwork.freedesktop.org/series/80896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8913 -> Patchwork_18388
Summary
Quoting Linus Torvalds (2020-08-21 13:41:03)
> On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson wrote:
> >
> > Since synchronising the PTE after assignment is a manual step, use the
> > newly exported interface to flush the PTE after assigning via
> > alloc_vm_area().
>
> This commit message doesn't
From: Joerg Roedel
The __apply_to_page_range() function is also used to change and/or
allocate page-table pages in the vmalloc area of the address space.
Make sure these changes get synchronized to other page-tables in the
system by calling arch_sync_kernel_mappings() when necessary.
Tested-by:
On Fri, Aug 21, 2020 at 1:50 AM Chris Wilson wrote:
>
> Since synchronising the PTE after assignment is a manual step, use the
> newly exported interface to flush the PTE after assigning via
> alloc_vm_area().
This commit message doesn't make much sense to me.
Are you talking about
On Fri, Aug 21, 2020 at 12:38:03PM +0100, Chris Wilson wrote:
> In the version I tested, I also had
>
> @@ -2216,7 +2216,7 @@ static int apply_to_pte_range(struct mm_struct *mm,
> pmd_t *pmd,
>
> if (create) {
> pte = (mm == _mm) ?
> -
Quoting Chris Wilson (2020-08-21 11:39:19)
> Quoting Joerg Roedel (2020-08-21 11:23:43)
> > On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote:
> > > We need to store the initial addr, as here addr == end [or earlier on
> > > earlier], so range is (start, addr).
> >
> > Right, I missed
== Series Details ==
Series: series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs
upon construction
URL : https://patchwork.freedesktop.org/series/80892/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8911_full -> Patchwork_18386_full
On Fri, Aug 21, 2020 at 12:09:02PM +0200, Joerg Roedel wrote:
> The __apply_to_page_range() function is also used to change and/or
> allocate page-table pages in the vmalloc area of the address space.
> Make sure these changes get synchronized to other page-tables in the
> system by calling
Quoting Joerg Roedel (2020-08-21 11:23:43)
> On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote:
> > We need to store the initial addr, as here addr == end [or earlier on
> > earlier], so range is (start, addr).
>
> Right, I missed that, thanks for pointing it out.
And with that
Quoting Joerg Roedel (2020-08-21 11:22:04)
> On Fri, Aug 21, 2020 at 10:54:22AM +0100, Chris Wilson wrote:
> > Ok. I thought it had to be after assigning the *ptep. If we apply the
> > sync first, do not have to worry about PGTBL_PTE_MODIFIED from the
> > *ptep?
>
> Hmm, if I understand the code
== Series Details ==
Series: series starting with mm: Track page table modifications in
__apply_to_page_range() construction (rev2)
URL : https://patchwork.freedesktop.org/series/80892/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
On Fri, Aug 21, 2020 at 11:13:36AM +0100, Chris Wilson wrote:
> We need to store the initial addr, as here addr == end [or earlier on
> earlier], so range is (start, addr).
Right, I missed that, thanks for pointing it out.
___
Intel-gfx mailing list
On Fri, Aug 21, 2020 at 10:54:22AM +0100, Chris Wilson wrote:
> Ok. I thought it had to be after assigning the *ptep. If we apply the
> sync first, do not have to worry about PGTBL_PTE_MODIFIED from the
> *ptep?
Hmm, if I understand the code correctly, you are re-implementing some
generic
On 16-07-2020 04:12, Manasi Navare wrote:
From: Maarten Lankhorst
When the clock is higher than the dotclock, try with 2 pipes enabled.
If we can enable 2, then we will go into big joiner mode, and steal
the adjacent crtc.
This only links the crtc's in software, no hardware or plane
Quoting Joerg Roedel (2020-08-21 11:09:02)
> @@ -2333,6 +2339,7 @@ static int __apply_to_page_range(struct mm_struct *mm,
> unsigned long addr,
> pgd_t *pgd;
> unsigned long next;
> unsigned long end = addr + size;
> + pgtbl_mod_mask mask = 0;
> int err = 0;
On Thu, 2020-08-20 at 16:51 +0200, Janusz Krzysztofik wrote:
> Clean up the test code, add some new basic subtests, then unblock
> unbind test variants.
Hi,
CI results show that i915 recovery after a failed healthcheck still
needs some work, so please hold on with your reviews. I'm going to
The __apply_to_page_range() function is also used to change and/or
allocate page-table pages in the vmalloc area of the address space.
Make sure these changes get synchronized to other page-tables in the
system by calling arch_sync_kernel_mappings() when necessary.
Signed-off-by: Joerg Roedel
Quoting Joerg Roedel (2020-08-21 10:51:29)
> On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote:
> > The alloc_vm_area() is another method for drivers to
> > vmap/map_kernel_range that uses apply_to_page_range() rather than the
> > direct vmalloc walkers. This is missing the page table
On Fri, Aug 21, 2020 at 09:50:08AM +0100, Chris Wilson wrote:
> The alloc_vm_area() is another method for drivers to
> vmap/map_kernel_range that uses apply_to_page_range() rather than the
> direct vmalloc walkers. This is missing the page table modification
> tracking, and the ability to
On 16-07-2020 04:12, Manasi Navare wrote:
From: Maarten Lankhorst
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
eDP does not support bigjoiner, so do not expose bigjoiner only
modes on the
== Series Details ==
Series: series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs
upon construction
URL : https://patchwork.freedesktop.org/series/80892/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8911 -> Patchwork_18386
On 2020-08-10 at 13:44:15 +0100, Chris Wilson wrote:
> Don't assume the kernel will emit a semaphore to synchronise between two
> engine, and emit the semaphore ourselves for the basis of our
> measurements. The purpose of the test is to try and ascertain the
> accuracy of the two sampling
On Thu 2020-08-20 09:16:18, Linus Torvalds wrote:
> On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote:
> >
> > Yes, it seems they make things work. (Chris asked for new patch to be
> > tested, so I am switching to his kernel, but it survived longer than
> > it usually does.)
>
> Ok, so at worst
== Series Details ==
Series: series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs
upon construction
URL : https://patchwork.freedesktop.org/series/80892/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit
== Series Details ==
Series: series starting with [1/4] mm: Export flush_vm_area() to sync the PTEs
upon construction
URL : https://patchwork.freedesktop.org/series/80892/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dc5a3f725528 mm: Export flush_vm_area() to sync the PTEs
Since synchronising the PTE after assignment is a manual step, use the
newly exported interface to flush the PTE after assigning via
alloc_vm_area().
Reported-by: Pavel Machek
References: 2ba3e6947aed ("mm/vmalloc: track which page-table levels were
modified")
Signed-off-by: Chris Wilson
Cc:
Use set_pte_at() to assign the PTE pointer returned by alloc_vm_area(),
rather than a direct assignment.
Fixes: 6056e50033d9 ("drm/i915/gem: Support discontiguous lmem object maps")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21
If we hit an error during construction of the reloc chain, we need to
replace the chain into the next batch with the terminator so that upon
flushing the relocations so far, we do not execute a hanging batch.
Reported-by: Pavel Machek
Fixes: 964a9b0f611e ("drm/i915/gem: Use chained reloc
The alloc_vm_area() is another method for drivers to
vmap/map_kernel_range that uses apply_to_page_range() rather than the
direct vmalloc walkers. This is missing the page table modification
tracking, and the ability to synchronize the PTE updates afterwards.
Provide flush_vm_area() for the users
On 21/08/2020 10:54, Petri Latvala wrote:
On Fri, Aug 21, 2020 at 12:45:23AM +0300, Lionel Landwerlin wrote:
On 20/08/2020 20:26, Chris Wilson wrote:
Use PRI[du]64 as necessary for 32bit builds.
Signed-off-by: Chris Wilson
Reviewed-by: Lionel Landwerlin
Was this for just 1/4 or the whole
On Fri, Aug 21, 2020 at 12:45:23AM +0300, Lionel Landwerlin wrote:
> On 20/08/2020 20:26, Chris Wilson wrote:
> > Use PRI[du]64 as necessary for 32bit builds.
> >
> > Signed-off-by: Chris Wilson
>
> Reviewed-by: Lionel Landwerlin
>
Was this for just 1/4 or the whole series?
This one is for
On Thu, Aug 20, 2020 at 08:32:51AM +0200, Jiri Slaby wrote:
> On 19. 08. 20, 15:24, Gerd Hoffmann wrote:
> > On Wed, Aug 19, 2020 at 02:43:28PM +0200, Jiri Slaby wrote:
> >> On 09. 07. 20, 14:33, Daniel Vetter wrote:
> >>> Exactly matches the one in the helpers.
> >>
> >> It's not that exact. The
70 matches
Mail list logo
