Hangcheck state accumulation has gained more steps
along the years, like head movement and more recently the
subunit inactivity check. As the subunit sampling is only
done if the previous state check showed inactivity, we
have added more stages (and time) to reach a hang verdict.
Asymmetric engine
If we have a bad client submitting unfavourably across different
contexts, creating new ones, the per context scoring of badness
doesn't remove the root cause, the offending client.
To counter, keep track of per client context bans. Deny access if
client is responsible for more than 3 context bans
Now when driver has per context scoring of 'hanging badness'
and also subsequent hangs during short windows are allowed,
if there is progress made in between, it does not make sense
to expose a ban timing window as a context parameter anymore.
Let the scoring be the sole indicator for ban policy a
Bannable property, banned status, guilty and active counts are
properties of i915_gem_context. Make them so.
v2: rebase
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h| 31 ++
drivers/gpu/drm/i915/i915_gem.c|
On 16/11/2016 15:27, Chris Wilson wrote:
Avoid requiring struct_mutex for exclusive access to the temporary
dfs_link inside the i915_dependency as not all callers may want to touch
struct_mutex. So rather than force them to take a highly contended
lock, introduce a local lock for the execlists s
== Series Details ==
Series: series starting with [1/2] HAX drm/i915: Enable guc submission (rev3)
URL : https://patchwork.freedesktop.org/series/15407/
State : failure
== Summary ==
Series 15407v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/15407/revisions/3/m
On Wed, Nov 16, 2016 at 03:54:23PM +, Tvrtko Ursulin wrote:
>
> On 16/11/2016 15:27, Chris Wilson wrote:
> >Avoid requiring struct_mutex for exclusive access to the temporary
> >dfs_link inside the i915_dependency as not all callers may want to touch
> >struct_mutex. So rather than force them
== Series Details ==
Series: series starting with [1/6] drm/i915: Split up hangcheck phases
URL : https://patchwork.freedesktop.org/series/15423/
State : warning
== Summary ==
Series 15423v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/15423/revisions/1/mbox/
T
== Series Details ==
Series: drm/i915/execlists: Use a local lock for dfs_link access
URL : https://patchwork.freedesktop.org/series/15425/
State : warning
== Summary ==
Series 15425v1 drm/i915/execlists: Use a local lock for dfs_link access
https://patchwork.freedesktop.org/api/1.0/series/154
On Wed, Nov 16, 2016 at 05:20:30PM +0200, Mika Kuoppala wrote:
> - ring_hung = engine->hangcheck.score >= HANGCHECK_SCORE_RING_HUNG;
> - if (engine->hangcheck.seqno != intel_engine_get_seqno(engine))
> + ring_hung = engine->hangcheck.stall;
> + if (engine->hangcheck.seqno != intel_e
On Wed, Nov 16, 2016 at 05:20:31PM +0200, Mika Kuoppala wrote:
> As hangcheck score was removed, the active decay of score
> was removed also. This removed feature for hangcheck to detect
> if the gpu client was accidentally or maliciously causing intermittent
> hangs. Reinstate the scoring as a pe
Hi Dave,
Another pile of misc:
- Explicit fencing for atomic! Big thanks to Gustavo, Sean, Rob 3x, Brian
and anyone else I've forgotten to make this happen.
- roll out fbdev helper ops to drivers (Stefan Christ)
- last bits of drm_crtc split-up&kerneldoc
- some drm_irq.c crtc functions cleanup
-
On Wed, Nov 16, 2016 at 05:20:33PM +0200, Mika Kuoppala wrote:
> If we have a bad client submitting unfavourably across different
> contexts, creating new ones, the per context scoring of badness
> doesn't remove the root cause, the offending client.
> To counter, keep track of per client context b
On Wed, Nov 16, 2016 at 05:20:34PM +0200, Mika Kuoppala wrote:
> Bannable property, banned status, guilty and active counts are
> properties of i915_gem_context. Make them so.
>
> v2: rebase
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
Been hesistating since the substruct might have hel
Jani/Ville , could you please review this patch?
Jani, you had mentioned it looks good and we were only waiting for
ACKs from DRM, so now from the DRM point of view all these patches
are ACKed and it looks good.
But I need r-b for these two i915 specific patches to get them merged.
Regards
Manasi
Jani/Ville could you please review this patch?
This has been ACKed by DRM and is good from DRM point fo view.
But I need r-b from either of you for this to get merged.
Regards
Manasi
On Mon, Nov 14, 2016 at 07:13:23PM -0800, Manasi Navare wrote:
> If link training at a link rate optimal for a par
I tried to avoid having to track the write for every VMA by only
tracking writes to the ggtt. However, for the purposes of frontbuffer
tracking this is insufficient as we need to invalidate around writes not
just to the the ggtt but all aliased ppgtt views of the framebuffer. By
moving the critical
We already have an i915_address_space_init, so for symmetry we should
also have a _fini, plus we already open code it twice. This then also
fixes a bug where we leak the timeline for the ggtt vm.
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 17 +
We need to clean up the global_timeline in i915_gem_load_cleanup.
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3fb5e66..c440e72 10064
== Series Details ==
Series: drm/i915: Move frontbuffer CS write tracking from ggtt vma to object
URL : https://patchwork.freedesktop.org/series/15435/
State : success
== Summary ==
Series 15435v1 drm/i915: Move frontbuffer CS write tracking from ggtt vma to
object
https://patchwork.freedeskt
Em Qua, 2016-11-16 às 19:07 +, Chris Wilson escreveu:
> I tried to avoid having to track the write for every VMA by only
> tracking writes to the ggtt. However, for the purposes of frontbuffer
> tracking this is insufficient as we need to invalidate around writes
> not
> just to the the ggtt bu
Hello all,
@Jani Nikula: I just tried the patches you linked and they work
*perfectly* on my notebook (Clevo P640RE). I also tried to suspend and
resume the laptop and it works like a charm!
I applied the patches against the Linux kernel v4.8.8 taken from
upstream.
Thanks again :)
Cheers,
Paolo
== Series Details ==
Series: drm/i915: add i915_address_space_fini
URL : https://patchwork.freedesktop.org/series/15437/
State : warning
== Summary ==
Series 15437v1 drm/i915: add i915_address_space_fini
https://patchwork.freedesktop.org/api/1.0/series/15437/revisions/1/mbox/
Test drv_module_
== Series Details ==
Series: drm/i915: don't leak global_timeline
URL : https://patchwork.freedesktop.org/series/15439/
State : warning
== Summary ==
Series 15439v1 drm/i915: don't leak global_timeline
https://patchwork.freedesktop.org/api/1.0/series/15439/revisions/1/mbox/
Test drv_module_re
On Wed, Nov 16, 2016 at 07:32:49PM +, Matthew Auld wrote:
> We need to clean up the global_timeline in i915_gem_load_cleanup.
>
> Cc: Chris Wilson
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/dr
On Wed, Nov 16, 2016 at 07:25:17PM +, Matthew Auld wrote:
> We already have an i915_address_space_init, so for symmetry we should
> also have a _fini, plus we already open code it twice. This then also
> fixes a bug where we leak the timeline for the ggtt vm.
>
> Cc: Chris Wilson
> Signed-off
On Wed, Nov 16, 2016 at 05:52:43PM -0200, Paulo Zanoni wrote:
> Em Qua, 2016-11-16 às 19:07 +, Chris Wilson escreveu:
> > I tried to avoid having to track the write for every VMA by only
> > tracking writes to the ggtt. However, for the purposes of frontbuffer
> > tracking this is insufficient
>-Original Message-
>From: Mcgee, Jeff
>Sent: Tuesday, November 15, 2016 2:46 PM
>To: Srivatsa, Anusha
>Cc: Tvrtko Ursulin ; Ursulin, Tvrtko
>; intel-gfx@lists.freedesktop.org; Vivi, Rodrigo
>
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/GuC: Combine the two kernel
>parameter into one
>
>O
On 2016.11.16 12:13:59 +0200, Jani Nikula wrote:
> We no longer cater for pre-production revisions of Skylake.
>
> Fixes: d4362225e8cb ("drm/i915/gvt: update misc ctl regs base on stepping
> info")
> Cc: Ping Gao
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> Cc:
> Signed-off-by: Jani Nikula
> ---
appl
Hi,
On Wed, Nov 16, 2016 at 09:14:28PM +0100, Paolo Stivanin wrote:
> Hello all,
> @Jani Nikula: I just tried the patches you linked and they work
> *perfectly* on my notebook (Clevo P640RE). I also tried to suspend and
> resume the laptop and it works like a charm!
> I applied the patches against
On Fri, 2016-11-11 at 23:05 +0200, Ville Syrjälä wrote:
> On Fri, Nov 11, 2016 at 08:43:53PM +, Pandiyan, Dhinakaran wrote:
> > On Tue, 2016-11-08 at 13:04 +0200, Ville Syrjälä wrote:
> > > On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> > > > Hotplugging a monitor in DP
On Sun, 2016-11-13 at 11:39 +0100, Daniel Vetter wrote:
> On Fri, Nov 11, 2016 at 10:21:39PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> > > Hotplugging a monitor in DP MST configuration triggers short pulses.
> > > Although the short pulse
Hi all,
Could anyone help review the patches? Thanks.
Regards,
Libin
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Yang, Libin
> Sent: Monday, November 14, 2016 1:41 PM
> To: intel-gfx@lists.freedesktop.org; jani.nik...@linux.inte
On 2016.11.16 22:05:04 +0800, Min He wrote:
> For a singl_port_submission context, it can only be submitted to port 0,
> and there shouldn't be any other context in port 1 at the same time. This
> is required by GVT-g context to have an opportunity to save/restore some
> non-hw context render regis
On 2016.11.16 15:50:27 +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Please pull current GVT-g device model fixes.
>
Sorry, pls hold on this as found a possible conflict, as this is
supposed to be last pull before 4.10 merge window, like to include
the fix for that, will send update later.
> Thanks.
>
On Fri, Oct 28, 2016 at 10:10:50AM +0200, Daniel Vetter wrote:
> Looking at the ioctl permission checks I noticed that it's impossible
> to import gem buffers into a control nodes, and fd2handle/handle2fd
> also don't work, so no joy with dma-bufs.
>
> The only way to do anything with a control no
Since the submit/execute split in commit d55ac5bf97c6 ("drm/i915: Defer
transfer onto execution timeline to actual hw submission") the
global seqno advance was deferred until the submit_request callback.
After wedging the GPU, we were installing a nop_submit_request handler
(to avoid waking up the
On Thu, Nov 17, 2016 at 01:53:31AM +, Pandiyan, Dhinakaran wrote:
> On Sun, 2016-11-13 at 11:39 +0100, Daniel Vetter wrote:
> > On Fri, Nov 11, 2016 at 10:21:39PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 07, 2016 at 04:27:30PM -0800, Dhinakaran Pandiyan wrote:
> > > > Hotplugging a monitor
On Thu, Nov 17, 2016 at 02:51:28PM +0800, Zhenyu Wang wrote:
>
> On 2016.11.16 15:50:27 +0800, Zhenyu Wang wrote:
> >
> > Hi,
> >
> > Please pull current GVT-g device model fixes.
> >
>
> Sorry, pls hold on this as found a possible conflict, as this is
> supposed to be last pull before 4.10 mer
101 - 139 of 139 matches
Mail list logo
