On Fri, Mar 15, 2013 at 10:06:19PM +, Chris Wilson wrote:
> On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote:
> > On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> > > That's what I thought too. Looking at the stack trace, the empirical
> > > evidence is that we need t
On Fri, Mar 15, 2013 at 09:36:07AM -0700, Ben Widawsky wrote:
> On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> > That's what I thought too. Looking at the stack trace, the empirical
> > evidence is that we need the check.
> > -Chris
>
> I think we need to investigate the issue mor
On Wed, Mar 06, 2013 at 08:03:22PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> To avoid this:
> [ 256.798060] [drm] capturing error event; look for more information
> in/sys/kernel/debug/dri/0/i915_error_state
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Ben Widawsky
You may want to
On Wed, Mar 06, 2013 at 08:03:21PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This fixes "unclaimed register" messages when the power well is
> disabled and there's a GPU hang.
This is really beginning to smell like we need special display register
reads which can do the check below.
>
On Wed, Mar 06, 2013 at 08:03:20PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because the register does not exist on LPT. The interesting fact is
> that reading/writing PCH_LVDS on LPT does *not* give us "unclaimed
> register" messages, but the register value is always 0.
>
> Signed-off
On Wed, Mar 06, 2013 at 08:03:19PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Now it returns false for all platforms unless they're explicitly
> listed on the function. There should be no real difference, except for
> the fact that it now returns false on Haswell.
>
> Signed-off-by: Pau
On Wed, Mar 06, 2013 at 08:03:17PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This solves many "unclaimed register" messages when the power well is
> down and we get a GPU hang.
>
> Also print the power well register and each pipe's CPU transcoder on
> the error state to allow proper in
On Wed, Mar 06, 2013 at 08:03:15PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> I couldn't find any evidence that this register exists on Gen2+. On
> Gen 2/3/4 documents this register is listed as reserved and read-only.
> On the newer Gens this register is not even documented.
>
> Also a
On Wed, Mar 06, 2013 at 08:03:14PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> So don't read it when we hang the GPU. This solves "unclaimed
> register" messages.
>
> Signed-off-by: Paulo Zanoni
It would be nice if you could make this a bit more future proof, but
looks correct to me:
Re
On Fri, Mar 15, 2013 at 12:04:11PM -0700, Ben Widawsky wrote:
> On Thu, Mar 07, 2013 at 11:38:24AM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 06, 2013 at 08:03:13PM -0300, Paulo Zanoni wrote:
> > > From: Paulo Zanoni
> > >
> > > So don't read it when capturing the error state. This solves some
>
On Thu, Mar 07, 2013 at 11:38:24AM +0200, Ville Syrjälä wrote:
> On Wed, Mar 06, 2013 at 08:03:13PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > So don't read it when capturing the error state. This solves some
> > "unclaimed register" messages on Haswell when we hang the GPU.
>
> Y
On Thu, Mar 07, 2013 at 11:34:08AM +0200, Ville Syrjälä wrote:
> On Wed, Mar 06, 2013 at 08:03:12PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > This solves some "unclaimed register" messages when there's a GPU hang
> > on Haswell.
> >
> > Signed-off-by: Paulo Zanoni
> > ---
> > d
On Thu, Mar 07, 2013 at 12:28:32AM +0100, Daniel Vetter wrote:
> On Wed, Mar 06, 2013 at 08:03:11PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > This solves some "unclaimed register" messages when booting the
> > machine with eDP attached.
> >
> > Signed-off-by: Paulo Zanoni
> > --
On Thu, Mar 07, 2013 at 12:26:23AM +0100, Daniel Vetter wrote:
> On Wed, Mar 06, 2013 at 08:03:10PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > It returns true if we're not supposed to touch the registers on the
> > power down well.
> >
> > For now there's just one caller, but I'm
On Wed, Mar 06, 2013 at 08:03:09PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Our mode set sequence documentation says audio must be disabled before
> the backlight.
>
> Signed-off-by: Paulo Zanoni
At least what I see it says, Audio must be disabled, "first." So I'd
recommend modifyin
Recommended by Chris.
v2: Make it GEN7_FEATURES, and use it for vlv and hsw also (Ben)
Cc: Chris Wilson
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 60 -
1 file changed, 23 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/dr
FIXME: This is based on some HW being used for a demo. We should
probably wait until we have confirmation on the IDs before upstreaming
this patch.
v2: Use GEN7_FEATURES (Chris)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 19 ++-
1 file changed, 18 insertio
Set up PCH_NOP when we match a certain platform.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8ff83e9..a63abd7 100644
--- a/drivers/gpu/drm/
More registers we can't write.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_suspend.c | 57 ++---
1 file changed, 41 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index c1e02b0.
BIOS should be setting this, but in case it doesn't...
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1417fc6..e
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
v2: Move check to the top (Chris)
Add BUG_ON for !ivybridge, since it's all we support for now (Ben)
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_pm.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915
GEN supports a fusing option which subtracts the PCH display (making the
CPU display also useless). In this configuration MMIO which gets decoded
to a certain range will hang the CPU.
For us, this is sort of the equivalent of having no pipes, and we can
easily modify some code to not do certain th
Given certain fusing options discussed in the previous patch, it's
possible to end up with platforms that normally have PCH but that PCH
doesn't actually exist. In many cases, this is easily remedied with
setting 0 pipes. This covers the other corners.
Requiring this is a symptom of improper code
Requested by Daniel.
v2: Fix incorrect num_pipe settings. (Chris)
Cc: Daniel Vetter
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_dma.c | 9 +--
drivers/gpu/drm/i915/i915_drv.c | 48 ++--
drivers/gpu/drm/i915/i915_drv.h | 4 +--
This adds a test to make sure that the execbuffer validation routine is
checking for invalid addresses, single entry overflow, and multi-entry
wrapping overflow.
Signed-off-by: Kees Cook
---
tests/.gitignore |1 +
tests/Makefile.am |1 +
tests/gem_reloc_overflow.c | 1
And if we've had to delay booting due to not being able to set the
interface, fess up.
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/x
If other processes have had drm open previously, xserver may attempt to
open the device too early and fail, with xserver error exit "Cannot
run in framebuffer mode" or Xorg.0.log messages about "setversion 1.4
failed".
In this situation, we're receiving back -EACCES from libdrm. To address
this w
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index bb76d90..3386b67 100644
--- a/hw/xfree86/os-supp
It has been suggested that the kernel may pass EAGAIN when the device is
unavailable. This hasn't been seen in practice, and examination of the
function definition in libdrm suggests EAGAIN is handled internally so
would not be seen by the xserver when making this call. So, this patch
is probably
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index 3ae2db1..c4d128e 100644
--- a/hw/xfr
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index 69a5b8c..6ee219a 100644
--- a/hw/xfree86/o
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index 6ee219a..3ae2db1 100644
--- a/hw/xfree86/os-suppo
Signed-off-by: Bryce Harrington
---
hw/xfree86/os-support/linux/lnx_platform.c |1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xfree86/os-support/linux/lnx_platform.c
b/hw/xfree86/os-support/linux/lnx_platform.c
index 76f5583..69a5b8c 100644
--- a/hw/xfree86/os-support/linux/lnx_platfo
When starting up (on Ubuntu), X can hit an error trying to set the
version on the drm device. We believe this is a race with plymouth (or
the kernel), since adding some delay to the boot results in a
functioning session for affected users.
So far we have not found a reliable way to reproduce the
On Fri, Mar 15, 2013 at 08:24:03AM +, Chris Wilson wrote:
> On Thu, Mar 14, 2013 at 09:50:04PM -0700, Ben Widawsky wrote:
> > 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
On Thu, Mar 14, 2013 at 12:32:00PM -0700, Kees Cook wrote:
> 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
On Thu, Mar 14, 2013 at 05:52:17PM +0200, Mika Kuoppala wrote:
> 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
> ++
On Thu, Mar 14, 2013 at 05:52:12PM +0200, Mika Kuoppala wrote:
> 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
On Thu, Mar 14, 2013 at 05:52:11PM +0200, Mika Kuoppala wrote:
> 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.
Being really picky, but can we device a better name than reset_state.
On Thu, Mar 14, 2013 at 05:52:07PM +0200, Mika Kuoppala wrote:
> index d66208c..9599c56 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -137,6 +137,8 @@ struct intel_ring_buffer {
> struct i915_hw_context *default_context;
> s
On Thu, Mar 14, 2013 at 05:52:04PM +0200, Mika Kuoppala wrote:
> @@ -2101,6 +2107,10 @@ static void i915_gem_reset_ring_lists(struct
> drm_i915_private *dev_priv,
>
> list_del(&request->list);
> i915_gem_request_remove_from_client(request);
> +
> + if (req
On Thu, Mar 14, 2013 at 05:52:03PM +0200, Mika Kuoppala wrote:
> Only execbuffer needs all the parameters. Cleanup everything
> else behind macro.
I'd prefer _i915_add_request over i915_do_add_request.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
On Fri, Mar 15, 2013 at 12:29 AM, Jani Nikula
wrote:
> Fun. The BIOS seems to ask for zero backlight. Maybe it means something
> else for Windows 8. White is the new black or something.
I did some experiment, I go to intel_backlight directory.
It show brightness is 4648, but actual_brightness is
On Fri, Mar 15, 2013 at 12:29 AM, Jani Nikula
wrote:
> I've never used the acpi_osi= kernel parameter, but it looks like you
> could workaround this with acpi_osi="!Windows 2012". Please check that
> running the "bad" kernel.
That did not work for me. Still have black screen on the tip of git.
I
On Thu, Mar 14, 2013 at 09:50:04PM -0700, Ben Widawsky wrote:
> 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: T
On Thu, 14 Mar 2013, Chris Li wrote:
> Hi, I attach the two demsg and with and without the bad commit
> on the intel nightly branch. Without the bad commit it actually works.
> However, on the tip of intel nightly. the moeset work around does not work
> there any more.
Hi Chris, thanks for the dm
47 matches
Mail list logo
