From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: [PATCH 1/3] drm/radeon: stop poisoning the GART TLB Date: Fri, 27 Jun 2014 10:26:32 +0200 Message-ID: <53AD2AB8.4080902@amd.com> References: <1401888598-1961-1-git-send-email-deathsimple@vodafone.de> <5398218A.4040104@vodafone.de> <53998D99.6050008@vodafone.de> <539B1CA0.6010600@vodafone.de> <539D9601.8090308@vodafone.de> <53A2415D.6020808@daenzer.net> <53A2B155.4000001@vodafone.de> <53A7E21E.1000000@daenzer.net> <53A7F9E1.8080700@amd.com> <53A91F89.7090504@daenzer.net> <53A94F94.6040603@amd.com> <53AA4913.10401@daenzer.net> <53ACD78C.6090102@daenzer.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) by gabe.freedesktop.org (Postfix) with ESMTP id 7DE366E3CA for ; Fri, 27 Jun 2014 01:26:40 -0700 (PDT) In-Reply-To: <53ACD78C.6090102@daenzer.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?ISO-8859-1?Q?Michel_D=E4nzer?= , Alex Deucher Cc: dri-devel List-Id: dri-devel@lists.freedesktop.org Am 27.06.2014 04:31, schrieb Michel D=E4nzer: > On 25.06.2014 12:59, Michel D=E4nzer wrote: >> On 24.06.2014 19:14, Christian K=F6nig wrote: >>> Am 24.06.2014 08:49, schrieb Michel D=E4nzer: >>>> On 23.06.2014 18:56, Christian K=F6nig wrote: >>>>> Am 23.06.2014 10:15, schrieb Michel D=E4nzer: >>>>>> On 19.06.2014 18:45, Christian K=F6nig wrote: >>>>>> >>>>>>> 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 kno= wn >>>>>> more stable state. It seems like we've maneuvered ourselves to a rat= her >>>>>> uncomfortable position from there, with no clear way to a better pla= ce. >>>>>> 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. >>>>> Yeah agree, especially on the uncomfortable position. >>>>> >>>>> Please try with the two attached patches applied on top of 3.15 and >>>>> retest. They should revert back to the old implementation. >>>> Unfortunately, X fails to start with these, see the attached excerpt >>>> from dmesg. >>> My fault, incorrectly solved a merge conflict and then failed to test >>> the right kernel. >>> >>> [...] >>> >>> Please try attached patches instead, >> With these patches, 3.15 just survived two piglit runs on my Bonaire, >> one with the GART poisoning fix and one without. It never survived a >> single run before. >> >> Acked-and-Tested-by: Michel D=E4nzer > So, are these patches going to 3.16 and 3.15? We could send them in for 3.15, but for 3.16 we have some new features = that depend on the new code. We could backport them to the old code, but I really want to work on = figuring out what's wrong with the new approach instead. Going to prepare a branch for you to test over the weekend, would be = nice if you could give it a try on Monday and see if that fixes the = issues as well. Thanks, Christian.