orresponding function "seq_puts".
debugfs / seq_file is not performance critical. Familiar idiomatic code is
much preferred over continually switching between seq_printf and seq_puts.
And don't even start on converting seq_printf / seq_puts to seq_putc...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
uot;.
debugfs / seq_file is not performance critical. Familiar idiomatic code is
much preferred over continually switching between seq_printf and seq_puts.
And don't even start on converting seq_printf / seq_puts to seq_putc...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Wed, May 03, 2017 at 05:07:03PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> > On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> > >> On Tue, May 02, 2
On Wed, May 03, 2017 at 05:07:03PM +0200, Daniel Vetter wrote:
> On Wed, May 03, 2017 at 07:40:51AM -0700, Laura Abbott wrote:
> > On 05/03/2017 12:39 AM, Daniel Vetter wrote:
> > > On Tue, May 02, 2017 at 09:22:13PM +0100, Chris Wilson wrote:
> > >> On Tue, May 02, 2
ate function to attach using a platform device associated
> with drm_device.
>
> Cc: intel-...@lists.freedesktop.org
> Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Signed-off-by: Laura Abbott <labb...@redhat.com>
> ---
> v3: Rebase to drm-misc-next. Prototype
ate function to attach using a platform device associated
> with drm_device.
>
> Cc: intel-...@lists.freedesktop.org
> Reviewed-by: Chris Wilson
> Signed-off-by: Laura Abbott
> ---
> v3: Rebase to drm-misc-next. Prototype moved to a new header file. Comments
> added for n
; +++ b/drivers/gpu/drm/i915/gvt/dmabuf.h
> @@ -0,0 +1,50 @@
> +/*
> + * Copyright(c) 2017 Intel Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE
> + * SOFTWARE.
> + *
> + */
> +
> +#ifndef _GVT_DMABUF_H_
> +#define _GVT_DMABUF_H_
> +
> +#define INTEL_VGPU_QUERY_DMABUF 0
> +#define INTEL_VGPU_GENERATE_DMABUF 1
> +
> +struct intel_vgpu_dmabuf {
This looks to be uapi. What's it doing here?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
c) 2017 Intel Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE
> + * SOFTWARE.
> + *
> + */
> +
> +#ifndef _GVT_DMABUF_H_
> +#define _GVT_DMABUF_H_
> +
> +#define INTEL_VGPU_QUERY_DMABUF 0
> +#define INTEL_VGPU_GENERATE_DMABUF 1
> +
> +struct intel_vgpu_dmabuf {
This looks to be uapi. What's it doing here?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
rged your for-next/pstore branch (which included this patch,
so I hope I chose correctly ;) into our CI. That should exercise it on
the machines that we originally found the lockdep splat.
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
rged your for-next/pstore branch (which included this patch,
so I hope I chose correctly ;) into our CI. That should exercise it on
the machines that we originally found the lockdep splat.
Thanks,
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ffer be resident in memory.
>
> I'm still marking this as RFC as I haven't had a chance to finish
> a userspace test that can be integrated into igt.
Note, that it will be good to cc:intel-gfx@ so that our CI does run it
over the existing vgem tests.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ffer be resident in memory.
>
> I'm still marking this as RFC as I haven't had a chance to finish
> a userspace test that can be integrated into igt.
Note, that it will be good to cc:intel-gfx@ so that our CI does run it
over the existing vgem tests.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
bj->pages)
> + drm_free_large(vgem_obj->pages);
Just drm_free_large(vgem_obj->pages); NULL -> kfree() which is NULL safe.
The series lgtm, doesn't compromise on any of the existing tests.
All 3,
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
drm_free_large(vgem_obj->pages);
Just drm_free_large(vgem_obj->pages); NULL -> kfree() which is NULL safe.
The series lgtm, doesn't compromise on any of the existing tests.
All 3,
Reviewed-by: Chris Wilson
You could always get Joonas to nitpick over style...
> +
> +
p is attached in case it is useful.
There are lots of very similar GPU hangs for mesa across a wide range of
kernels, with several reports noting a correlation with libreoffice.
At first glance, I would say you were just unlucky to hit it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
p is attached in case it is useful.
There are lots of very similar GPU hangs for mesa across a wide range of
kernels, with several reports noting a correlation with libreoffice.
At first glance, I would say you were just unlucky to hit it.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
273.951528] ret_from_fork+0x31/0x40
> [ 273.956974] Code: 45 10 75 0b e8 e5 db e1 ff 4d 89 65 10 eb 17 e8 da db e1
> ff 4d 89 65 08 eb 0c e8 cf db e1 ff 4c 89 25 e7 ca 3b 04 e8 c3 db e1 ff <4d>
> 85 e4 74 0e e8 b9 db e1 ff 4d 89 34 24 e9 4e 01 00 00 e8 ab
It looks like (summary + trace) that we have moved the timeout from the
ww_mutex stress test to the rbtree tests.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
273.951528] ret_from_fork+0x31/0x40
> [ 273.956974] Code: 45 10 75 0b e8 e5 db e1 ff 4d 89 65 10 eb 17 e8 da db e1
> ff 4d 89 65 08 eb 0c e8 cf db e1 ff 4c 89 25 e7 ca 3b 04 e8 c3 db e1 ff <4d>
> 85 e4 74 0e e8 b9 db e1 ff 4d 89 34 24 e9 4e 01 00 00 e8 ab
It looks like (summary + trace) that we have moved the timeout from the
ww_mutex stress test to the rbtree tests.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
; ---
> +static void vc4_fence_release(struct dma_fence *fence)
> +{
> + struct vc4_fence *f = to_vc4_fence(fence);
> +
> + kfree_rcu(f, base.rcu);
> +}
Unless you have a plan to do more here, looks like you can just use
the default dma_fence_free as the release callback.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
ce)
> +{
> + struct vc4_fence *f = to_vc4_fence(fence);
> +
> + kfree_rcu(f, base.rcu);
> +}
Unless you have a plan to do more here, looks like you can just use
the default dma_fence_free as the release callback.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Apr 07, 2017 at 06:48:58PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote:
> > Not getting hangs is a good sign, but lockdep doesn't like it:
> >
> > [ 460.684901] WARNING: CPU: 1 PID: 172 at ke
On Fri, Apr 07, 2017 at 06:48:58PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 04:30:11PM +0100, Chris Wilson wrote:
> > Not getting hangs is a good sign, but lockdep doesn't like it:
> >
> > [ 460.684901] WARNING: CPU: 1 PID: 172 at ke
m unrelated to the GPU
hang and date back to ~4.9. Both reported issues have been fixed, with
the earlier report already in mainline but Andrea's fix is not yet in a
PR.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
m unrelated to the GPU
hang and date back to ~4.9. Both reported issues have been fixed, with
the earlier report already in mainline but Andrea's fix is not yet in a
PR.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Apr 07, 2017 at 09:18:30AM -0700, Laura Abbott wrote:
> On 04/07/2017 12:39 AM, Chris Wilson wrote:
> > On Thu, Apr 06, 2017 at 04:18:33PM -0700, Laura Abbott wrote:
> >>
> >> Enable the GEM dma-buf import interfaces in addition to the export
> >>
On Fri, Apr 07, 2017 at 09:18:30AM -0700, Laura Abbott wrote:
> On 04/07/2017 12:39 AM, Chris Wilson wrote:
> > On Thu, Apr 06, 2017 at 04:18:33PM -0700, Laura Abbott wrote:
> >>
> >> Enable the GEM dma-buf import interfaces in addition to the export
> >>
On Fri, Apr 07, 2017 at 03:06:00PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> > On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > > Waiting a RCU grace period only guarantees the work gets queued, but
On Fri, Apr 07, 2017 at 03:06:00PM +0200, Andrea Arcangeli wrote:
> On Fri, Apr 07, 2017 at 11:02:11AM +0100, Chris Wilson wrote:
> > On Fri, Apr 07, 2017 at 01:23:44AM +0200, Andrea Arcangeli wrote:
> > > Waiting a RCU grace period only guarantees the work gets queued, but
On Fri, Apr 07, 2017 at 01:23:45AM +0200, Andrea Arcangeli wrote:
> Just in case the llist model changes and NULL isn't valid
> initialization.
>
> Signed-off-by: Andrea Arcangeli <aarca...@redhat.com>
Applied, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Apr 07, 2017 at 01:23:45AM +0200, Andrea Arcangeli wrote:
> Just in case the llist model changes and NULL isn't valid
> initialization.
>
> Signed-off-by: Andrea Arcangeli
Applied, thanks.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
the reclaim code in addition of waiting a RCU grace
> period to pass.
We are not allowed to call flush_work() from the shrinker, the workqueue
doesn't have and can't have the right reclaim flags.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
the reclaim code in addition of waiting a RCU grace
> period to pass.
We are not allowed to call flush_work() from the shrinker, the workqueue
doesn't have and can't have the right reclaim flags.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
the
changes? I'm also not particularly happy in losing testing of a virtual
platform device from our CI.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
the
changes? I'm also not particularly happy in losing testing of a virtual
platform device from our CI.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Commit-ID: 57dd924e541a98219bf3a508623db2e0c07e75a7
Gitweb: http://git.kernel.org/tip/57dd924e541a98219bf3a508623db2e0c07e75a7
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Fri, 10 Mar 2017 10:57:33 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate:
Commit-ID: 57dd924e541a98219bf3a508623db2e0c07e75a7
Gitweb: http://git.kernel.org/tip/57dd924e541a98219bf3a508623db2e0c07e75a7
Author: Chris Wilson
AuthorDate: Fri, 10 Mar 2017 10:57:33 +
Committer: Ingo Molnar
CommitDate: Thu, 30 Mar 2017 09:49:47 +0200
locking/ww-mutex: Limit
.x, whereas my problem did not appear until 4.11.
Close. Actually that patch touches code you are not using (oa-perf and
gvt), the real culprit was e8a9c58fcd9a ("drm/i915: Unify active context
tracking between legacy/execlists/guc").
The fix
commit 5d4bac5503fcc67dd7999571e243cee49371aef7
.x, whereas my problem did not appear until 4.11.
Close. Actually that patch touches code you are not using (oa-perf and
gvt), the real culprit was e8a9c58fcd9a ("drm/i915: Unify active context
tracking between legacy/execlists/guc").
The fix
commit 5d4bac5503fcc67dd7999571e243cee49371aef
nce. If info is null, then the error message being
> printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> use a null vpgu as the macro has a sanity check to see if vpgu is null,
> so this is OK.
It is never NULL, it gets checked by its only caller.
-Chris
--
Chris Wilson
r message being
> printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> use a null vpgu as the macro has a sanity check to see if vpgu is null,
> so this is OK.
It is never NULL, it gets checked by its only caller.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Mar 21, 2017 at 02:58:48PM +0900, Namhyung Kim wrote:
> Hello,
>
> On Mon, Mar 20, 2017 at 10:49:16AM -0700, Kees Cook wrote:
> > On Fri, Mar 17, 2017 at 2:52 AM, Chris Wilson <ch...@chris-wilson.co.uk>
> > wrote:
> > > In order to prevent a cycl
On Tue, Mar 21, 2017 at 02:58:48PM +0900, Namhyung Kim wrote:
> Hello,
>
> On Mon, Mar 20, 2017 at 10:49:16AM -0700, Kees Cook wrote:
> > On Fri, Mar 17, 2017 at 2:52 AM, Chris Wilson
> > wrote:
> > > In order to prevent a cyclic recursion between psi->read_m
On Tue, Mar 21, 2017 at 09:56:52AM +, Chris Wilson wrote:
> On Mon, Mar 20, 2017 at 10:40:28AM +0100, Arnd Bergmann wrote:
> > We get a warning with gcc-7 about a pointless comparison when
> > using a linear memmap:
> >
> > drivers/gpu/drm/i915/selftests
On Tue, Mar 21, 2017 at 09:56:52AM +, Chris Wilson wrote:
> On Mon, Mar 20, 2017 at 10:40:28AM +0100, Arnd Bergmann wrote:
> > We get a warning with gcc-7 about a pointless comparison when
> > using a linear memmap:
> >
> > drivers/gpu/drm/i915/selftests
t this approach is that we leak the unwanted
inode/file. We only want the drm_file here and any access to above that
inside i915.ko is fubar.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
*file;
> int err;
>
> - err = drm_open(, );
> + err = drm_open(, filp);
> if (unlikely(err))
> return ERR_PTR(err);
>
> - file = filp.private_data;
> + file = filp->private_data;
What I don't like about this approach is that
e
consistently, but I agree the helper is good documentation.
> Fixes: 935a2f776aa5 ("drm/i915: Add some selftests for sg_table manipulation")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
Reviewed-by: Chris Wilson <ch...@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
e
consistently, but I agree the helper is good documentation.
> Fixes: 935a2f776aa5 ("drm/i915: Add some selftests for sg_table manipulation")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
0b08a44 ("pstore: Protect unlink with read_mutex")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100234
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tomi Sarvela <tomi.p.sarv...@intel.com>
Cc: Kees Cook <keesc...@chromium.org>
Cc: Anton Vorontsov <an..
t unlink with read_mutex")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100234
Signed-off-by: Chris Wilson
Cc: Tomi Sarvela
Cc: Kees Cook
Cc: Anton Vorontsov
Cc: Colin Cross
Cc: Tony Luck
Cc: Stefan Hajnoczi
Cc: Namhyung Kim
Cc: # v4.10+
---
fs/pstore/inode.c| 37 ++
by the worker, and only accessed by the parent
after the flush_work() barrier.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
by the worker, and only accessed by the parent
after the flush_work() barrier.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
her possiblity for a mmap_sem recursion in the ggtt fault
handler.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
her possiblity for a mmap_sem recursion in the ggtt fault
handler.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
AT which throws out a few objects using this interface.
> Not stress test or thrashing needed at all.
>
> v2: Need to EXPORT_SYMBOL_GPL to make it compile as a module.
>
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Peter Zijlstra <pet...@infradead.org>
> Cc:
AT which throws out a few objects using this interface.
> Not stress test or thrashing needed at all.
>
> v2: Need to EXPORT_SYMBOL_GPL to make it compile as a module.
>
> Cc: Chris Wilson
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: linux-kernel@vger.kernel.org
> R
Use a timeout rather than a fixed number of loops to avoid running for
very long periods, such as under the kbuilder VMs.
Reported-by: kernel test robot <xiaolong...@intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Boqun Feng <boqun.f...@gmail.com>
Cc: P
Use a timeout rather than a fixed number of loops to avoid running for
very long periods, such as under the kbuilder VMs.
Reported-by: kernel test robot
Signed-off-by: Chris Wilson
Cc: Boqun Feng
Cc: Peter Zijlstra
---
kernel/locking/test-ww_mutex.c | 18 +-
1 file changed, 9
on_interruptible() would stop the hung task check? That
leaves NMI watchdog to check if we hit a deadlock between the workers.
And add a timeout to the stress test.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
on_interruptible() would stop the hung task check? That
leaves NMI watchdog to check if we hit a deadlock between the workers.
And add a timeout to the stress test.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote:
> On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > mplayer stopped working after a while. Dmes
On Mon, Mar 06, 2017 at 01:10:48PM +0100, Pavel Machek wrote:
> On Mon 2017-03-06 11:15:28, Chris Wilson wrote:
> > On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > mplayer stopped working after a while. Dmes
On Mon, Mar 06, 2017 at 11:15:28AM +, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > mplayer stopped working after a while. Dmesg says:
> > > >
> > > > [ 3000.266533] cdc_ether 2-1.2
On Mon, Mar 06, 2017 at 11:15:28AM +, Chris Wilson wrote:
> On Mon, Mar 06, 2017 at 12:01:51AM +0100, Pavel Machek wrote:
> > Hi!
> >
> > > > mplayer stopped working after a while. Dmesg says:
> > > >
> > > > [ 3000.266533] cdc_ether 2-1.2
15;
- i915_gem_request_submit(request);
-
GEM_BUG_ON(!IS_ALIGNED(request->tail, 8));
I915_WRITE_TAIL(request->engine, request->tail);
+
+ i915_gem_request_submit(request);
}
static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req, u32 *cs)
--
Chris Wilson, Intel Open Source Technology Centre
15;
- i915_gem_request_submit(request);
-
GEM_BUG_ON(!IS_ALIGNED(request->tail, 8));
I915_WRITE_TAIL(request->engine, request->tail);
+
+ i915_gem_request_submit(request);
}
static void i9xx_emit_breadcrumb(struct drm_i915_gem_request *req, u32 *cs)
--
Chris Wilson, Intel Open Source Technology Centre
Commit-ID: 2b232e0c3b3a09f3e33750aa20e314f1b80e5361
Gitweb: http://git.kernel.org/tip/2b232e0c3b3a09f3e33750aa20e314f1b80e5361
Author: Chris Wilson <ch...@chris-wilson.co.uk>
AuthorDate: Tue, 28 Feb 2017 09:40:11 +
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Thu
Commit-ID: 2b232e0c3b3a09f3e33750aa20e314f1b80e5361
Gitweb: http://git.kernel.org/tip/2b232e0c3b3a09f3e33750aa20e314f1b80e5361
Author: Chris Wilson
AuthorDate: Tue, 28 Feb 2017 09:40:11 +
Committer: Ingo Molnar
CommitDate: Thu, 2 Mar 2017 09:00:38 +0100
locking/ww_mutex: Replace
On Wed, Mar 01, 2017 at 04:11:48PM +, Chris Wilson wrote:
> On Wed, Mar 01, 2017 at 04:54:14PM +0100, Peter Zijlstra wrote:
> > On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote:
> > > Thanks for the patch! I applied the patch on top of "locking/ww_mute
On Wed, Mar 01, 2017 at 04:11:48PM +, Chris Wilson wrote:
> On Wed, Mar 01, 2017 at 04:54:14PM +0100, Peter Zijlstra wrote:
> > On Wed, Mar 01, 2017 at 11:40:43PM +0800, Fengguang Wu wrote:
> > > Thanks for the patch! I applied the patch on top of "locking/ww_mute
ads was
immaterial - with each test doing a different sequence of locks and each
being identical in behaviour, it would not matter which had priority,
there would have be some shuffling no matter waht. However, for the
purpose of testing, having each iteration be a new locking instance does
make it
ads was
immaterial - with each test doing a different sequence of locks and each
being identical in behaviour, it would not matter which had priority,
there would have be some shuffling no matter waht. However, for the
purpose of testing, having each iteration be a new locking instance does
make it
like it
> contains quite a lot of data. If it contains actual framebuffer
> content, it may not be wise to post to mailing list
It contains command and register states. No pixel data unless userspace
got particularly creative with its memory corruption.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
like it
> contains quite a lot of data. If it contains actual framebuffer
> content, it may not be wise to post to mailing list
It contains command and register states. No pixel data unless userspace
got particularly creative with its memory corruption.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Feb 28, 2017 at 01:43:02PM +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 03:06:35PM +, Matt Fleming wrote:
> > On Fri, 24 Feb, at 05:19:03PM, Dave Jones wrote:
> > > Looks like fallout from cb42c9a3e23448c3f9a25417fae6309b1a92
> > >
> > >
On Tue, Feb 28, 2017 at 01:43:02PM +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 03:06:35PM +, Matt Fleming wrote:
> > On Fri, 24 Feb, at 05:19:03PM, Dave Jones wrote:
> > > Looks like fallout from cb42c9a3e23448c3f9a25417fae6309b1a92
> > >
> > >
eng Li <wanpeng...@hotmail.com>
Date: Tue Feb 21 23:52:55 2017 -0800
sched/fair: Update rq clock before changing a task's CPU affinity
to our CI, and we still see the splat
https://intel-gfx-ci.01.org/CI/CI_DRM_2251/fi-byt-n2820/igt@gem_exec_susp...@basic-s3.html
Anything else in that branch that might be the fix?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
eng Li
Date: Tue Feb 21 23:52:55 2017 -0800
sched/fair: Update rq clock before changing a task's CPU affinity
to our CI, and we still see the splat
https://intel-gfx-ci.01.org/CI/CI_DRM_2251/fi-byt-n2820/igt@gem_exec_susp...@basic-s3.html
Anything else in that branch that might be the fix?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Feb 28, 2017 at 10:48:53AM +0100, Peter Zijlstra wrote:
> On Tue, Feb 28, 2017 at 09:40:11AM +0000, Chris Wilson wrote:
> > When busy-spinning on a ww_mutex_trylock(), we depend upon the other
> > thread advancing and releasing the lock. This can not happen on a single
&g
On Tue, Feb 28, 2017 at 10:48:53AM +0100, Peter Zijlstra wrote:
> On Tue, Feb 28, 2017 at 09:40:11AM +0000, Chris Wilson wrote:
> > When busy-spinning on a ww_mutex_trylock(), we depend upon the other
> > thread advancing and releasing the lock. This can not happen on a single
&g
c3 55 89 e5 50 9d 8d 74 26 00 5d c3 55
89 e5 9c 58 8d 74 26 00 89 c1 fa 90 8d 74 26 00 89 c8 5d c3 55 89 e5 57 <56> 89
c6 53 83 ec 18 8b 1e a1 8c 24 79 81 89 45 ec 89 45 f0 89
Fixes: f2a5fec17395 ("locking/ww_mutex: Begin kselftests for ww_mutex")
Reported-by: Fengguang Wu <f
c3 55 89 e5 50 9d 8d 74 26 00 5d c3 55
89 e5 9c 58 8d 74 26 00 89 c1 fa 90 8d 74 26 00 89 c8 5d c3 55 89 e5 57 <56> 89
c6 53 83 ec 18 8b 1e a1 8c 24 79 81 89 45 ec 89 45 f0 89
Fixes: f2a5fec17395 ("locking/ww_mutex: Begin kselftests for ww_mutex")
Reported-by: Fengguang Wu
() should become cond_resched()?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
() should become cond_resched()?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Thu, Feb 23, 2017 at 12:07:17AM +, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> trivial fix to spelling mistake in pr_err message
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Reviewed-by: Chris Wilson <ch...@chris-w
On Thu, Feb 23, 2017 at 12:07:17AM +, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to spelling mistake in pr_err message
>
> Signed-off-by: Colin Ian King
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Sun, Feb 12, 2017 at 03:46:09PM +, Chris Wilson wrote:
> +void tasklet_enable(struct tasklet_struct *t)
> +{
> + if (!atomic_dec_and_test(>count))
> + return;
> +
> + if (test_bit(TASKLET_STATE_SCHED, >state))
> + raise_softirq(H
On Sun, Feb 12, 2017 at 03:46:09PM +, Chris Wilson wrote:
> +void tasklet_enable(struct tasklet_struct *t)
> +{
> + if (!atomic_dec_and_test(>count))
> + return;
> +
> + if (test_bit(TASKLET_STATE_SCHED, >state))
> + raise_softirq(H
modules.
v3: Restore the looping over a failed tasklet_trylock()
Reported-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Hannes
modules.
v3: Restore the looping over a failed tasklet_trylock()
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Thomas Gleixner
Cc: Hannes Reinecke
Cc: Jens Axboe
Cc: Bjorn Helgaas
Cc: Alexander Potapenko
Cc: Chen Fan
Cc: Ingo Molnar
Cc: "Peter Zijlstr
h modules.
Reported-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Hannes Reinecke <h...@suse.com>
Cc: Jens Axboe <ax...@
h modules.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Thomas Gleixner
Cc: Hannes Reinecke
Cc: Jens Axboe
Cc: Bjorn Helgaas
Cc: Alexander Potapenko
Cc: Chen Fan
Cc: Ingo Molnar
Cc: "Peter Zijlstra (Intel)"
Cc: Sebastian Andrzej Siewior
Cc:
On Sun, Feb 12, 2017 at 02:00:19PM +, Chris Wilson wrote:
> Disabling a tasklet causes it not to run during tasklet_action, but is
> put back onto the runnable tasklet list, and a new softirq raised. As
> the softirq is raised from within __do_softirq() this causing
> __do_softi
On Sun, Feb 12, 2017 at 02:00:19PM +, Chris Wilson wrote:
> Disabling a tasklet causes it not to run during tasklet_action, but is
> put back onto the runnable tasklet list, and a new softirq raised. As
> the softirq is raised from within __do_softirq() this causing
> __do_softi
su...@intel.com>
Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Hannes Reinecke <h...@suse.com>
Cc: Jens Axboe <ax...@kernel.dk>
Cc: Bjorn Helgaas <bhelg...@googl
until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")
Reported-by: Tvrtko Ursulin
Signed-off-
Don't build test-drm_mm as a builtin? Or set a limit to the number of
tests to run, e.g. test-drm_mm.max_iterations=16 test-drm_mm.max_primes=16.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Don't build test-drm_mm as a builtin? Or set a limit to the number of
tests to run, e.g. test-drm_mm.max_iterations=16 test-drm_mm.max_primes=16.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
401 - 500 of 1356 matches
Mail list logo
