On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> In order to prevent a potential NULL deference with hostile userspace,
> we need to check whether the ioctl was passed an invalid args pointer.
>
> Reported-by: Tommi Rantala
> Link:
> http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpu
On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote:
> In order to prevent a potential NULL deference with hostile userspace,
> we need to check whether the ioctl was passed an invalid args pointer.
>
> Reported-by: Tommi Rantala
> Link:
> http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpu
On Wed, 13 Mar 2013 14:08:28 -0700
Ben Widawsky wrote:
> Recommended by Chris.
>
> Cc: Chris Wilson
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_drv.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i
Summary
We finished a new round of kernel testing. Generally, in this circle, 4 new
bugs are filed, 21 bugs are still opened, 3 bugs are closed.
3 bugs out of 4 new ones are related to eDP display.
Test Environment
Kernel: (drm-intel-testing) d08a6eb2690b1ac6f0582feb41c2ccbea945285f
Author:
On Mon, Mar 11, 2013 at 6:16 AM, Jani Nikula
wrote:
> Interesting snippets from your dmesgs:
>
> 1) good
>
> [0.00] Linux version 3.6.0-rc6+ (chr...@ideapad.lan) (gcc version
> 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #25 SMP Wed Feb 20 12:55:06 PST 2013
> ...
> [5.341431] [drm:intel_
On Thu, Mar 14, 2013 at 9:57 AM, Daniel Vetter wrote:
> On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter wrote:
>> On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote:
>>> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
>>> > It is possible to wrap the counter used to allocate t
On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter wrote:
> On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote:
>> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote:
>> > It is possible to wrap the counter used to allocate the buffer for
>> > relocation copies. This could lead to hea
On Thu, Mar 14, 2013 at 08:56:41AM +, Chris Wilson wrote:
> I was hoping for something a little more magical. I couldn't spot any
> mistakes - the only thing missing is a hint as to why these are useful.
>
> Acked-by: Chris Wilson
> -Chris
I'm pretty sure you asked for magic the last time se
Interrupts, clock gating, and GMBUS are all within the, "this will hang
the CPU" range when we have PCH_NOP.
There is a bit of a hack in init clock gating. We want to do most of the
clock gating, but the part we skip will hang the system. It could
probably be abstracted a bit better, but I don't f
If context has recently submitted a faulty batchbuffers guilty of
gpu hang and decides to keep submitting more crap, ban it permanently.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.c| 23 ++-
drivers/gpu/drm/i915/i915_drv.h|1 +
Instead of relying in acthd, track ring seqno progression
to detect if ring has hung.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h |2 --
drivers/gpu/drm/i915/i915_irq.c | 30 +-
drivers/gpu/drm/i915/intel_ringbuffer.h |2
In order to track down a batch buffer and context which
caused the ring to hang, store reference to bo and context
into the request struct. Request can also cause gpu to hang
after the batch in the flush section in the ring. To detect this
add start of the flush portion offset into the request.
Si
From: Chris Wilson
Once we thought we got semaphores working, we disabled kicking the ring
if hangcheck fired whilst waiting upon a ring as it was doing more harm
than good:
commit 4e0e90dcb8a7df1229c69e30abebb59b0b3c2a1f
Author: Daniel Vetter
Date: Wed Dec 14 13:56:58 2011 +0100
drm/i91
Only execbuffer needs all the parameters. Cleanup everything
else behind macro.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h|8 +---
drivers/gpu/drm/i915/i915_gem.c| 10 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers
For arb-robustness, every context needs to have it's own
reset state tracking. Default context will be handled in a identical
way as the no-context case in further down in the patch set.
For no-context case, the reset state will be stored in
the file_priv part.
v2: handle default context inside ge
In preparation for next commit, pass seqno as a parameter
to i915_hangcheck_ring_idle as it will be used inside
i915_hangcheck_elapsed.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
After hang check timer has declared gpu to be hang,
rings are reset. In ring reset, when clearing
request list, do post mortem analysis to find out
the guilty batch buffer.
Select requests for further analysis by inspecting
the completed sequence number which has been updated
into the HWS page. If
Hi,
Reworked patchset for guilty context detection.
Main changes since the last posting:
- i915_add_request cleanup
- i915_switch_context returns ERR_PTR
- 3 seconds to declare hang regardless if guilty was found
- semaphore kicking for hung rings (from Chris)
- test case for the new interface
- i
This ioctl returns context reset status for specified context.
Signed-off-by: Mika Kuoppala
CC: i...@freedesktop.org
---
drivers/gpu/drm/i915/i915_dma.c |1 +
drivers/gpu/drm/i915/i915_drv.c | 61 +++
drivers/gpu/drm/i915/i915_drv.h |2 ++
include/ua
For guilty batchbuffer analysis later on on ring resets,
mark all waiting rings so that we can skip them when
trying to find a true culprit for the gpu hang.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c |3 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
2 f
To count context losses, add struct ctx_reset_state for
both i915_hw_context and drm_i915_file_private.
drm_i915_file_private is used when there is no context.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_dma.c |4 +++-
drivers/gpu/drm/i915/i915_drv.h | 19 +++
Add per ring score of possible culprit for gpu hang. If
ring is busy and not waiting, it will get the highest score
across calls to i915_hangcheck_elapsed. This way we are
most likely to find the ring that caused the hang among
the waiting ones.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i
Rework of per ring hangcheck made this obsolete.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_irq.c | 21 -
2 files changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv
In preparation to track per ring progress in hangcheck,
add i915_hangcheck_ring_hung.
v2: omit dev parameter (Ben Widawsky)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_irq.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/driv
In preparation for the next commit, return context that
was switched to from i915_switch_context().
v2: context in return value instead of param. (Ben Widawsky)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h|5 +++--
drivers/gpu/drm/i915/i915_gem.c|
In preparation to do analysis of which context was
guilty of gpu hung, store kreffed context pointer
into request struct.
This allows us to inspect contexts when gpu is reset
even if those contexts would already be released
by userspace.
v2: track i915_hw_context pointers instead of using ctx_ids
Hi,
I noticed that a Haswell desktop machine with eDP gets only the blank
screen on the latest Linus tree. It works fine with 3.8, so it's a
regression since 3.9-rc1. Actually, it's not a regression. It's
three regressions in a shot! (I had to do painful bisections three
times...)
c464b2a17c59
In order to prevent a potential NULL deference with hostile userspace,
we need to check whether the ioctl was passed an invalid args pointer.
Reported-by: Tommi Rantala
Link:
http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com
Signed-off-by: Chris Wilson
On Wed, 13 Mar 2013, Ben Widawsky wrote:
> Interrupts, clock gating, and gmbus are all within the, "this will hang
> the CPU" range when we have PCH_NOP.
>
> There is a bit of a hack in init clock gating. We want to do most of the
> block gating, but the part we skip will hang the system. It could
I was hoping for something a little more magical. I couldn't spot any
mistakes - the only thing missing is a hint as to why these are useful.
Acked-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
30 matches
Mail list logo
