CIK hangs with kernel 3.15, bisected

Alex Deucher alexdeucher at gmail.com
Tue May 13 06:22:54 PDT 2014


On Mon, May 12, 2014 at 7:38 PM, Grigori Goronzy <greg at chown.ath.cx> wrote:
> I can confirm this fixes it for me, too.
>
> 3.15 with these fixes and the large PTE patches actually ends up being
> noticeably slower than earlier kernels with Xonotic, though. I wonder what's
> going on.

Allocation overhead?


>
> Grigori
>
>
> On 12.05.2014 14:50, Christian König wrote:
>>
>> I could reproduce the problem with xonotic and I think I've found the
>> issue.
>>
>> Please test the attached patch.
>>
>> Thanks,
>> Christian.
>>
>> Am 11.05.2014 11:06, schrieb Christian König:
>>>>
>>>> I have tested it and it doesn't fix the hangs.
>>>
>>> Yeah, thought so. Well it was just a guess.
>>>
>>>> (Also, I don't like the patch, because it reverts the behavior I added
>>>> for userspace buffers.)
>>>
>>> Actually it shouldn't affect that. The alternative domain always
>>> contains GART even when userspace only specified VRAM as placement (as
>>> long as it is technical possible to do so).
>>>
>>> So what should happen is that TTM sees the current placement, matches
>>> that with the desired placement and should find that it doesn't need
>>> to move the buffer (we should just test if this behavior really works
>>> as expected).
>>>
>>> Christian.
>>>
>>> Am 10.05.2014 23:38, schrieb Marek Olšák:
>>>>
>>>> Hi Christian,
>>>>
>>>> I have tested it and it doesn't fix the hangs.
>>>>
>>>> (Also, I don't like the patch, because it reverts the behavior I added
>>>> for userspace buffers.)
>>>>
>>>> Marek
>>>>
>>>>
>>>>
>>>> On Sat, May 10, 2014 at 6:34 PM, Christian König
>>>> <deathsimple at vodafone.de> wrote:
>>>>>
>>>>> Couldn't reproduce the issue so far. So the attached patch is just a
>>>>> complete shoot into the dark found by rereading the code, but it might
>>>>> actually be the problem.
>>>>>
>>>>> Please give it a try.
>>>>>
>>>>> Going to keep testing in the meantime,
>>>>> Christian.
>>>>>
>>>>> Am 10.05.2014 10:23, schrieb Christian König:
>>>>>
>>>>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if
>>>>>>> I boot
>>>>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high
>>>>>>> settings.
>>>>>>> I haven't had a chance to bisect it yet, but it might be a similar
>>>>>>> problem.
>>>>>>
>>>>>> Sounds like the same issue to me. Thx for the good test case.
>>>>>>
>>>>>>> Any idea what is wrong with it?
>>>>>>
>>>>>> Actually I already wondered that it went so smooth without any
>>>>>> regression
>>>>>> so far, didn't noticed the bug in bugzilla.kernel.org yet.
>>>>>>
>>>>>>> Some of the tests allocate a lot of MSAA textures and the tests also
>>>>>>> run in parallel, which creates a lot of memory pressure and probably
>>>>>>> causes buffer evictions.
>>>>>>
>>>>>> Sounds like the underlying problem to me. We probably evict some
>>>>>> part of a
>>>>>> page table without updating the page directory. Going to dig into
>>>>>> it today,
>>>>>> it's probably just a one liner missing somewhere in the VM code.
>>>>>>
>>>>>> Christian.
>>>>>>
>>>>>> Am 09.05.2014 23:39, schrieb Grigori Goronzy:
>>>>>>>
>>>>>>> On 09.05.2014 20:03, Marek Olšák wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> This commit which first appeared in 3.15-rc1 causes hangs on
>>>>>>>> Bonaire:
>>>>>>>> [...]
>>>>>>>>
>>>>>>>> The simplest way to reproduce the hangs is to run piglit with these
>>>>>>>> parameters:
>>>>>>>> -t texelFetch.fs
>>>>>>>>
>>>>>>>> Some of the tests allocate a lot of MSAA textures and the tests also
>>>>>>>> run in parallel, which creates a lot of memory pressure and probably
>>>>>>>> causes buffer evictions.
>>>>>>>>
>>>>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if
>>>>>>> I boot
>>>>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high
>>>>>>> settings.
>>>>>>> I haven't had a chance to bisect it yet, but it might be a similar
>>>>>>> problem.
>>>>>>>
>>>>>>> Grigori
>>>>>>
>>>>>>
>>>
>>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel


More information about the dri-devel mailing list