All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: "Christian König" <deathsimple@vodafone.de>,
	"Alex Deucher" <alexdeucher@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/3] drm/radeon: stop poisoning the GART TLB
Date: Mon, 23 Jun 2014 17:15:26 +0900	[thread overview]
Message-ID: <53A7E21E.1000000@daenzer.net> (raw)
In-Reply-To: <53A2B155.4000001@vodafone.de>

On 19.06.2014 18:45, Christian König wrote:
> Am 19.06.2014 03:48, schrieb Michel Dänzer:
>> On 15.06.2014 21:48, Christian König wrote:
>>>
>>> No idea what goes wrong when Marek runs piglit, but 3.15.0+"stop
>>> poisoning the GART TLB"+"force_gtt" is rock solid here.
>> FWIW, 3.15 doesn't survive piglit on my Bonaire either, but 3.14 is
>> fine. 3.15 seems stable on Kaveri though, but I haven't tried the
>> force_gtt patch on that yet.
> 
> Yeah, I think it's just me who has a stable system with 3.15 and that
> annoys me quite a bit.

FWIW though, my Kaveri doesn't always survive piglit either, e.g. this
morning it didn't once again, then did after a reboot. (That's using
SDMA; Kaveri was never switched back to CPDMA)


> No idea what's the difference. What versions of LLVM/Mesa/Piglit are you
> using for the test?

Current Git of everything.


>> There have also been a number of bug reports about stability regressions
>> in 3.15 on various SI and CIK cards. It seems likely that at least some
>> of those are related to this issue as well.
>>
>> If we can't figure out the problem soon, we probably need to revert the
>> 'Use normal BOs for page tables' and dependent changes at least for
>> 3.15.y?
> 
> I thought about this for the whole 3.15 release cycle, but decided
> against it. But what we could do is applying the attached trivial patch,
> it pins down the page tables and so pretty much reverts to the old
> behavior.

This patch applied on top of 3.15 + stop poisoning the GART TLB doesn't
seem to help on my Bonaire, unfortunately.


> I think even when we revert to the old code we have a couple of unsolved
> problems with the VM support or in the driver in general where we should
> try to understand the underlying reason for it instead of applying more
> workarounds.

I'm not suggesting applying more workarounds but going back to a known
more stable state. It seems like we've maneuvered ourselves to a rather
uncomfortable position from there, with no clear way to a better place.
But if we basically started from the 3.14 state again, we have a few
known hurdles like mine and Marek's Bonaire etc. which we know any
further improvements will have to pass before they can be considered for
general consumption.


-- 
Earthling Michel Dänzer            |                  http://www.amd.com
Libre software enthusiast          |                Mesa and X developer

  reply	other threads:[~2014-06-23  8:15 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-04 13:29 [PATCH 1/3] drm/radeon: stop poisoning the GART TLB Christian König
2014-06-04 13:29 ` [PATCH 2/3] drm/radeon: remove range check from *_gart_set_page Christian König
2014-06-04 13:29 ` [PATCH 3/3] drm/radeon: use the SDMA on for buffer moves on CIK again Christian König
2014-06-04 13:46 ` [PATCH 1/3] drm/radeon: stop poisoning the GART TLB Alex Deucher
2014-06-04 13:50   ` Christian König
2014-06-10 23:30 ` Marek Olšák
2014-06-11  9:29   ` Christian König
2014-06-11 10:56     ` Marek Olšák
2014-06-12 11:23       ` Christian König
2014-06-13 13:19         ` Marek Olšák
2014-06-13 15:45           ` Christian König
2014-06-13 21:31             ` Alex Deucher
2014-06-15 12:48               ` Christian König
2014-06-19  1:48                 ` Michel Dänzer
2014-06-19  9:45                   ` Christian König
2014-06-23  8:15                     ` Michel Dänzer [this message]
2014-06-23  9:56                       ` Christian König
2014-06-24  6:49                         ` Michel Dänzer
2014-06-24 10:14                           ` Christian König
2014-06-25  3:59                             ` Michel Dänzer
2014-06-26 12:25                               ` Dieter Nützel
2014-06-27  2:31                               ` Michel Dänzer
2014-06-27  8:26                                 ` Christian König
2014-06-27  8:59                                   ` Michel Dänzer
2014-06-29 10:34                                     ` Christian König
2014-06-30  6:10                                       ` Michel Dänzer
2014-06-30  7:43                                         ` Christian König
2014-07-01  6:48                                           ` Michel Dänzer
2014-07-01 12:16                                             ` Christian König
2014-07-02  6:57                                               ` Michel Dänzer
2014-07-02 19:31                                                 ` Christian König
2014-07-03  3:48                                                   ` Michel Dänzer
2014-07-03  6:36                                                     ` Christian König
2014-06-19 10:20                   ` Marek Olšák
2014-06-19 10:25                     ` Christian König
2014-06-20  1:10                     ` Michel Dänzer

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=53A7E21E.1000000@daenzer.net \
    --to=michel@daenzer.net \
    --cc=alexdeucher@gmail.com \
    --cc=deathsimple@vodafone.de \
    --cc=dri-devel@lists.freedesktop.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.