I think the prime issue is that dma_direct_alloc respects the dma
mask. Which we don't need if actually using the iommu. This would
be mostly harmless exept for the the SEV bit high in the address that
makes the checks fail.
For now I'd say revert this commit for 4.17/4.18-rc and I'll look into
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 :
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00 Gabri
Am 06.06.2018 um 14:08 schrieb Gabriel C:
2018-06-06 13:33 GMT+02:00 Christian König :
Am 06.06.2018 um 13:28 schrieb Gabriel C:
2018-04-11 7:02 GMT+02:00 Gabriel C :
2018-04-11 6:00 GMT+02:00 Gabriel C :
2018-04-09 11:42 GMT+02:00 Christian König
:
Am 07.04.2018 um 00:00 schrieb Jean-Marc Va
On 2018-04-20 09:40 PM, Felix Kuehling wrote:
> On 2018-04-20 10:47 AM, Michel Dänzer wrote:
>> On 2018-04-11 11:37 AM, Christian König wrote:
>>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
2018-04-09 11:42 GMT+02:00 Christian König
:
> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
>
[+Philip]
On 2018-04-20 10:47 AM, Michel Dänzer wrote:
> On 2018-04-11 11:37 AM, Christian König wrote:
>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>>> 2018-04-09 11:42 GMT+02:00 Christian König
>>> :
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
> Hi Christian,
>
> Thanks for
On 2018-04-11 11:37 AM, Christian König wrote:
> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>> 2018-04-09 11:42 GMT+02:00 Christian König
>> :
>>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
h
2018-04-12 0:20 GMT+02:00 Gabriel C :
> 2018-04-11 20:35 GMT+02:00 Jean-Marc Valin :
>> On 04/11/2018 05:37 AM, Christian König wrote:
With your patches my EPYC box is unusable with 4.15++ kernels.
The whole Desktop is acting weird. This one is using
an Cape Verde PRO [Radeon HD 77
2018-04-11 20:35 GMT+02:00 Jean-Marc Valin :
> On 04/11/2018 05:37 AM, Christian König wrote:
>>> With your patches my EPYC box is unusable with 4.15++ kernels.
>>> The whole Desktop is acting weird. This one is using
>>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.
>>>
>>> Box is 2 *
On 04/11/2018 05:37 AM, Christian König wrote:
>> With your patches my EPYC box is unusable with 4.15++ kernels.
>> The whole Desktop is acting weird. This one is using
>> an Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] GPU.
>>
>> Box is 2 * EPYC 7281 with 128 GB ECC RAM
>>
>> Also a 14C Xeon
2018-04-11 16:26 GMT+02:00 Gabriel C :
> 2018-04-11 11:37 GMT+02:00 Christian König :
>> Am 11.04.2018 um 06:00 schrieb Gabriel C:
...
>>
>> Please test Alex's amd-staging-drm-next branch from
>> git://people.freedesktop.org/~agd5f/linux.
>
> I'm on it just the connection to freedesktop.org is slo
2018-04-11 11:37 GMT+02:00 Christian König :
> Am 11.04.2018 um 06:00 schrieb Gabriel C:
>>
>> 2018-04-09 11:42 GMT+02:00 Christian König
>> :
>>>
>>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that
Am 11.04.2018 um 06:00 schrieb Gabriel C:
2018-04-09 11:42 GMT+02:00 Christian König :
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment s
>2018-04-11 6:00 GMT+02:00 Gabriel C :
> 2018-04-09 11:42 GMT+02:00 Christian König :
>> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
...
> I can help testing code for 4.17/++ if you wish but that is *different*
> storry.
>
Quick tested an 4.16.0-11490-gb284d4d5a678 , amdgpu and radeon driver
2018-04-09 11:42 GMT+02:00 Christian König :
> Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
>>
>> Hi Christian,
>>
>> Thanks for the info. FYI, I've also opened a Firefox bug for that at:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
>> Feel free to comment since you have a better unde
Am 09.04.2018 um 17:17 schrieb Jean-Marc Valin:
On 04/09/2018 05:42 AM, Christian König wrote:
Backporting all the detection logic is to invasive, but you could just
go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the
other code path.
Just look out for "#ifdef CONFIG_SWIOTLB"
On 04/09/2018 05:42 AM, Christian König wrote:
> Backporting all the detection logic is to invasive, but you could just
> go into drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c and forcefull use the
> other code path.
>
> Just look out for "#ifdef CONFIG_SWIOTLB" checks and disable those.
Do you mean ju
Am 07.04.2018 um 00:00 schrieb Jean-Marc Valin:
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.
One last question: right now I'
Hi Christian,
Thanks for the info. FYI, I've also opened a Firefox bug for that at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1448778
Feel free to comment since you have a better understanding of what's
going on.
One last question: right now I'm running 4.15.0 with the "offending"
patch revert
Am 06.04.2018 um 18:42 schrieb Jean-Marc Valin:
Hi Christian,
On 04/09/2018 07:48 AM, Christian König wrote:
Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time?
Only at compile time by not setting CONFIG_TRANSPARENT
Hi Christian,
On 04/09/2018 07:48 AM, Christian König wrote:
> Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
>> Hi Christian,
>>
>> Is there a way to turn off these huge pages at boot-time/run-time?
>
> Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
Any reason why
echo never
Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time?
Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
Alternatively you can avoid enabling CONFIG_SWIOTLB which will avoid the
slow DMA path as well.
Hi Christian,
Is there a way to turn off these huge pages at boot-time/run-time? Right
now the recent kernels are making Firefox pretty much unusable for me.
I've been able to revert the patch from 4.15 but it's not really a
long-term solution.
You mention that the purpose of the patch is to impr
Hi Jean,
found the bug reports.
Here is the original bug report from the kernel:
https://bugzilla.kernel.org/show_bug.cgi?id=198511
And here is an fdo bug report where we tried to investigate the root
cause, but didn't had time for that yet:
https://bugs.freedesktop.org/show_bug.cgi?id=1050
Hi Jean,
yeah, that is a known problem. Using huge pages improves the performance
because of better TLB usage, but for the cost of higher allocation overhead.
What we found is that firefox is doing something rather strange by
allocating large textures and then just trowing them away again imm
Hi,
I noticed a serious graphics performance regression between 4.14 and
4.15. It is most noticeable with Firefox (tried FF57 through FF60) and
causes scrolling to be really choppy/sluggish. I've confirmed that the
problem is also there on 4.16, while 4.13 works fine.
After a bisection, I've narr
25 matches
Mail list logo
