[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Christian König]

> FWIW, I've also had successful runs with the first three of the split
> changes, and with all of them.
Ok I've just pushed a branch testing-3.15-v3 to fdo which moves all page 
table allocation to the end of VRAM. Please try with this memory layout, 
it should give us a good idea if it's indeed a memory corruption or 
something else.

Apart from that please try to lockup your system with 
radeon.lockup_timeout=0 on the kernel commandline and then try to get a 
dump of the vm page tables with the script I've send to you in one of 
the mails.

Thanks for the help,
Christian.

Am 02.07.2014 08:57, schrieb Michel Dänzer:
> On 01.07.2014 21:16, Christian König wrote:
>> Am 01.07.2014 08:48, schrieb Michel Dänzer:
>>> On 30.06.2014 16:43, Christian König wrote:
>>>> Am 30.06.2014 08:10, schrieb Michel Dänzer:
>>>>> On 29.06.2014 19:34, Christian König wrote:
>>>>>> I've just pushed the branch testing-3.15 to
>>>>>> git://people.freedesktop.org/~deathsimple/linux. It's based on 3.15.2
>>>>>> and contains the "stop poisoning the GART TLB" patch backported to
>>>>>> 3.15
>>>>>> and a couple of things that I would like to try.
>>>>> Running that branch, my Bonaire just survived a piglit run without
>>>>> lockup. I hope that's an interesting result. :)
>>>> That's indeed an interesting result. Can you try to figure out which of
>>>> the patches on the branch did the trick for you?
>>> The winner is 'drm/radeon: completely over allocate PD and PTs'. That
>>> patch alone on top of 3.15.2 makes piglit survive on my Bonaire.
>> Sounds like we either need to align the buffers a bit more, accidentally
>> overwrite parts of them or indeed messed up their size calculation
>> somewhere.
>>
>> I've just pushed a new branch testing-3.15-v2 to
>> git://people.freedesktop.org/~deathsimple/linux. It only contains the
>> two patches already submitted for 3.15 inclusion and the "drm/radeon:
>> completely over allocate PD and PTs" patch split into four separate
>> changes.
>>
>> Please retest and if it still works try once more which change fixed it.
> It's hard to say, I'm afraid. I had a successful run with only the first
> two of the split up changes, but then after both of them failing by
> themselves, another run with both of them failed as well. So it seems
> like both of those are required, but maybe not sufficient.
>
> FWIW, I've also had successful runs with the first three of the split
> changes, and with all of them.