From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
LKML <linux-kernel@vger.kernel.org>,
Dave Airlie <airlied@gmail.com>,
Chris Wilson <chris@chris-wilson.co.uk>,
stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: disable cpu relocs on ilk and earlier
Date: Thu, 18 Oct 2012 09:34:41 +0200 [thread overview]
Message-ID: <CAKMK7uEH=XNcjSzaTwpHPpAmdDHNo7aQmeobvQoRi6N94+08Zw@mail.gmail.com> (raw)
In-Reply-To: <20121015151119.GB30606@kroah.com>
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
next prev parent reply other threads:[~2012-10-18 7:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-15 8:11 [PATCH] drm/i915: disable cpu relocs on ilk and earlier Daniel Vetter
2012-10-15 8:11 ` Daniel Vetter
2012-10-15 15:11 ` Greg KH
2012-10-15 17:16 ` Daniel Vetter
2012-10-15 17:34 ` Greg KH
2012-10-18 7:34 ` Daniel Vetter [this message]
-- strict thread matches above, loose matches on Subject: below --
2012-10-10 8:06 Daniel Vetter
2012-10-10 9:13 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKMK7uEH=XNcjSzaTwpHPpAmdDHNo7aQmeobvQoRi6N94+08Zw@mail.gmail.com' \
--to=daniel.vetter@ffwll.ch \
--cc=airlied@gmail.com \
--cc=chris@chris-wilson.co.uk \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.