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.
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 >>>>> >> >
