Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: Kernel and ADM hardware roulette ( was AMD graphics performance
 regression in 4.15 and later )
To:     =?UTF-8?Q?Michel_D=c3=a4nzer?= <michel.daenzer@amd.com>,
        Gabriel C <nix.or.die@gmail.com>
Cc:     Jean-Marc Valin <jmvalin@mozilla.com>,
        Dave Airlie <airlied@linux.ie>, alexander.deucher@amd.com,
        Felix Kuehling <Felix.Kuehling@amd.com>,
        Laura Abbott <labbott@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        dri-devel@lists.freedesktop.org,
        LKML <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
References: <CAEJqkgiNVDzboDK1vsn9rYP0G=Q_mGDrkx1VVB8TUkm35Rs9fA@mail.gmail.com>
 <516cddbe-73c2-01f3-a552-0d9fd75ce63a@amd.com>
From:   =?UTF-8?Q?Christian_K=c3=b6nig?= <christian.koenig@amd.com>
Message-ID: <8f7d00f9-992f-cc07-6bd0-b1b47c5d2ccf@amd.com>
Date:   Wed, 6 Jun 2018 16:44:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <516cddbe-73c2-01f3-a552-0d9fd75ce63a@amd.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Received-SPF: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2018 14:44:38.6105 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c077c82-f8e4-4870-34ca-08d5cbbc08f0
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1724
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Am 06.06.2018 um 16:12 schrieb Michel Dänzer:
> On 2018-06-06 03:33 PM, Gabriel C wrote:
>> 2018-06-06 14:19 GMT+02:00 Christian König <christian.koenig@amd.com>:
>>> Am 06.06.2018 um 14:08 schrieb Gabriel C:
>>>> 2018-06-06 13:33 GMT+02:00 Christian König <christian.koenig@amd.com>:
>>>>> Am 06.06.2018 um 13:28 schrieb Gabriel C:
>>>>>> 2018-04-11 7:02 GMT+02:00 Gabriel C <nix.or.die@gmail.com>:
>>>>>>>
>>>>>>> [    6.337838] [drm] PCIE GART of 2048M enabled (table at
>>>>>>> 0x00000000001D6000).
>>>>>>> [    6.338210] radeon 0000:21:00.0: (-12) create WB bo failed
>>>>>>> [    6.338214] radeon 0000:21:00.0: disabling GPU acceleration
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>> I have the same Issue now on final 4.17.
>
> Please file a bug report, and ideally bisect which commit(s) 
> introduced the issue(s).
>
>
>>>> http://ftp.frugalware.org/pub/other/people/crazy/radeon/dmesg-iommu-sr-iov-off.txt 
>>>>
>>>>
>>>> http://ftp.frugalware.org/pub/other/people/crazy/radeon/dmesg-iommu-sr-iov-on.txt 
>>>>
>>>>
>>>> Also nothing else changed in that setup just testing kernel 4.17.
>>>
>>>
>>> That has nothing TODO with the driver nor the original bug you 
>>> reported. The
>>> problem is that SME is active and that is currently not supported at 
>>> all
>>> with a that hardware.
>>
>> Ok .. so are we playing now kernel an AMD Hardware roulette on each 
>> release ?
>>
>> SME was like this in kernel 4.16.x here and all worked.
>
> If that is true, again please bisect which commit broke it.
>
> All the reports I've seen before this indicated that at least amdgpu 
> has never worked with SME (which BTW doesn't mean it's never going to 
> work or that we don't want to support it, just that as far as we know 
> it's currently not working).

At least in theory it should work when we use the coherent DMA allocator.

When that really worked before, so the most likely commit which broke 
this is:

commit fd5fd480dd8fe4910546e7b080b3ae345e57fe9f
Author: Chunming Zhou <david1.zhou@amd.com>
Date:   Fri Feb 9 10:44:09 2018 +0800

     drm/amdgpu: only enable swiotlb alloc when need v2

     get the max io mapping address of system memory to see if it is over
     our card accessing range.
     v2: move checking later

     Signed-off-by: Chunming Zhou <david1.zhou@amd.com>
     Reviewed-by: Monk Liu <monk.liu@amd.com>
     Reviewed-by: Christian König <christian.koenig@amd.com>
     Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Currently looking into how we could somehow improve this detection.

Regards,
Christian.