[PATCH] drm/i915: disable cpu relocs on ilk and earlier

[PATCH] drm/i915: disable cpu relocs on ilk and earlier

[Daniel Vetter]

They seem to be implicated in render corruptions. And up to now no one
really seems to understand the issue, so let's just disable them for
now. Most of the machines exhibiting this issue have only a 128 gtt
mmio window, so increased pressure on the mappable part (and so higher
chance for cpu relocs) seems to be the key.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=852210
Cc: Dave Airlie <airlied@gmail.com>
Cc: stable@vger.kernel.org
[Note for stable, there's a minor conflict in the context since we've
tuned cpu relocs on gen6+ a bit in 3.7.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6a2f3e5..4052ac5 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -95,6 +95,12 @@ eb_destroy(struct eb_objects *eb)
 
 static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
 {
+	/* cpu relocs are implicated in some not-yet-understood render
+	 * corruptions on at least ilk, but probably also gm45. Until we know
+	 * what's going on, just disable them. */
+	if (INTEL_INFO(obj->base.dev)->gen < 6)
+		return false;
+
 	return (obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
 		!obj->map_and_fenceable ||
 		obj->cache_level != I915_CACHE_NONE);
-- 
1.7.10.4

Re: [PATCH] drm/i915: disable cpu relocs on ilk and earlier

[Chris Wilson]

On Wed, 10 Oct 2012 10:06:40 +0200, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> They seem to be implicated in render corruptions. And up to now no one
> really seems to understand the issue, so let's just disable them for
> now. Most of the machines exhibiting this issue have only a 128 gtt
> mmio window, so increased pressure on the mappable part (and so higher
> chance for cpu relocs) seems to be the key.
> 
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=852210
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55112
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: stable@vger.kernel.org
> [Note for stable, there's a minor conflict in the context since we've
> tuned cpu relocs on gen6+ a bit in 3.7.]
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

My only query is that the fdo reporter said that "kernel 3.6 + drm-next"
didn't trigger the error. So I'd like some confirmation that this patch
is indeed needed for 3.7, but meh. (If only because that might give some
insight as to what the root cause is.)

Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH] drm/i915: disable cpu relocs on ilk and earlier

[Daniel Vetter]

Hi Greg&stable-team,

The below patch papers over a graphics corruption issue in 3.5/3.6. The
regression happened due to pwrite tunings in 3.5, which made cpu relocations
much more likely.

The issue seems to have disappeared in 3.7-rc1, but it takes a few days to test
a patch, so we haven't figured out what exactly fixed things. Now users are
taking out their pitchforks already, so instead of wasting more days (maybe
weeks?) to fully understand the bug before backporting the fix, we've opted for
the below disable patch, which should have minimal impact (at most it undoes the
tuning improvements in 3.5).

Patch is tested by reporters & acked by all relevant ppl, please apply to
3.5/3.6 series kernels.

Thanks, Daniel

---

They seem to be implicated in render corruptions. And up to now no one
really seems to understand the issue, so let's just disable them for
now. Most of the machines exhibiting this issue have only a 128 gtt
mmio window, so increased pressure on the mappable part (and so higher
chance for cpu relocs) seems to be the key.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=852210
Tested-by: Dave Airlie <airlied@gmail.com>
Cc: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ff2819e..682156a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -268,6 +268,12 @@ eb_destroy(struct eb_objects *eb)
 
 static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
 {
+	/* cpu relocs are implicated in some not-yet-understood render
+	 * corruptions on at least ilk, but probably also gm45. Until we know
+	 * what's going on, just disable them. */
+	if (INTEL_INFO(obj->base.dev)->gen < 6)
+		return false;
+
 	return (obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
 		obj->cache_level != I915_CACHE_NONE);
 }
-- 
1.7.10.4

Re: [PATCH] drm/i915: disable cpu relocs on ilk and earlier

[Greg KH]

On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
> Hi Greg&stable-team,
> 
> The below patch papers over a graphics corruption issue in 3.5/3.6. The
> regression happened due to pwrite tunings in 3.5, which made cpu relocations
> much more likely.
> 
> The issue seems to have disappeared in 3.7-rc1, but it takes a few days to test
> a patch, so we haven't figured out what exactly fixed things. Now users are
> taking out their pitchforks already, so instead of wasting more days (maybe
> weeks?) to fully understand the bug before backporting the fix, we've opted for
> the below disable patch, which should have minimal impact (at most it undoes the
> tuning improvements in 3.5).
> 
> Patch is tested by reporters & acked by all relevant ppl, please apply to
> 3.5/3.6 series kernels.

No, I'd really like to wait until you figure out what is happening in
3.7-rc1 right now before applying the patch.  We have the rule, "it must
be in Linus's tree first" for a very good reason :)

So, I'll hold onto this until you say what's up with 3.7-rc1, ok?

thanks,

greg k-h

Re: [PATCH] drm/i915: disable cpu relocs on ilk and earlier

[Daniel Vetter]

On Mon, Oct 15, 2012 at 5:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
>> Hi Greg&stable-team,
>>
>> The below patch papers over a graphics corruption issue in 3.5/3.6. The
>> regression happened due to pwrite tunings in 3.5, which made cpu relocations
>> much more likely.
>>
>> The issue seems to have disappeared in 3.7-rc1, but it takes a few days to test
>> a patch, so we haven't figured out what exactly fixed things. Now users are
>> taking out their pitchforks already, so instead of wasting more days (maybe
>> weeks?) to fully understand the bug before backporting the fix, we've opted for
>> the below disable patch, which should have minimal impact (at most it undoes the
>> tuning improvements in 3.5).
>>
>> Patch is tested by reporters & acked by all relevant ppl, please apply to
>> 3.5/3.6 series kernels.
>
> No, I'd really like to wait until you figure out what is happening in
> 3.7-rc1 right now before applying the patch.  We have the rule, "it must
> be in Linus's tree first" for a very good reason :)
>
> So, I'll hold onto this until you say what's up with 3.7-rc1, ok?

Can do, might send a few pitchforks I collect your way though ;-)

While I have your attention (and now that -rc1 is out), can you please
pick up my two console_lock patches into your tty tree for 3.8?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH] drm/i915: disable cpu relocs on ilk and earlier

[Greg KH]

On Mon, Oct 15, 2012 at 07:16:26PM +0200, Daniel Vetter wrote:
> On Mon, Oct 15, 2012 at 5:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
> >> Hi Greg&stable-team,
> >>
> >> The below patch papers over a graphics corruption issue in 3.5/3.6. The
> >> regression happened due to pwrite tunings in 3.5, which made cpu relocations
> >> much more likely.
> >>
> >> The issue seems to have disappeared in 3.7-rc1, but it takes a few days to test
> >> a patch, so we haven't figured out what exactly fixed things. Now users are
> >> taking out their pitchforks already, so instead of wasting more days (maybe
> >> weeks?) to fully understand the bug before backporting the fix, we've opted for
> >> the below disable patch, which should have minimal impact (at most it undoes the
> >> tuning improvements in 3.5).
> >>
> >> Patch is tested by reporters & acked by all relevant ppl, please apply to
> >> 3.5/3.6 series kernels.
> >
> > No, I'd really like to wait until you figure out what is happening in
> > 3.7-rc1 right now before applying the patch.  We have the rule, "it must
> > be in Linus's tree first" for a very good reason :)
> >
> > So, I'll hold onto this until you say what's up with 3.7-rc1, ok?
> 
> Can do, might send a few pitchforks I collect your way though ;-)

No problem at all, I can handle them :)

> While I have your attention (and now that -rc1 is out), can you please
> pick up my two console_lock patches into your tty tree for 3.8?

Let me catch up on my 3.7 patches first please, I'm still on the road
traveling to conferences on different continents, and am in a conference
this week as well.  The fact that I'm waking up at the right time is
amazing...

greg k-h

Re: [PATCH] drm/i915: disable cpu relocs on ilk and earlier

[Daniel Vetter]

On Mon, Oct 15, 2012 at 5:11 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
>> Hi Greg&stable-team,
>>
>> The below patch papers over a graphics corruption issue in 3.5/3.6. The
>> regression happened due to pwrite tunings in 3.5, which made cpu relocations
>> much more likely.
>>
>> The issue seems to have disappeared in 3.7-rc1, but it takes a few days to test
>> a patch, so we haven't figured out what exactly fixed things. Now users are
>> taking out their pitchforks already, so instead of wasting more days (maybe
>> weeks?) to fully understand the bug before backporting the fix, we've opted for
>> the below disable patch, which should have minimal impact (at most it undoes the
>> tuning improvements in 3.5).
>>
>> Patch is tested by reporters & acked by all relevant ppl, please apply to
>> 3.5/3.6 series kernels.
>
> No, I'd really like to wait until you figure out what is happening in
> 3.7-rc1 right now before applying the patch.  We have the rule, "it must
> be in Linus's tree first" for a very good reason :)

Ok, the verdict is in (thanks a lot Dave for testing all these
different patches) and it seems like

commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Aug 23 13:12:52 2012 +0100

    drm/i915: Use cpu relocations if the object is in the GTT but not mappable

from upstream nicely papers over the issues. Please apply to 3.5/3.6
stable series (earlier kernels don't exhibit the problem).

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=852210
Tested-by: Dave Airlie <airlied@gmail.com>

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch