I already tried a similar patch as well, without any more noticeable crashes. But going to give this another round with your patch and openarena.
Thanks, Christian. Am 27.05.2014 23:55, schrieb Marek Ol??k: > Hi Christian, > > I test on Bonaire (ChipID = 0x665c). Unfortunately, the hangs are not > fixed yet. They are very rare and very random. Therefore, I have come > up with a patch which evicts page tables between IBs. See the > attachment. With that patch applied, the system starts fine, compiz > and glxgears work, but once I start playing openarena, it locks up > pretty quickly. > > The patch shouldn't do anything in theory, because pages are moved > back to VRAM immediately after that. However, the VRAM address of page > tables may end up being different from before, which might be the root > cause. > > Marek > > On Wed, May 14, 2014 at 2:11 PM, Christian K?nig > <deathsimple at vodafone.de> wrote: >> Crap, any chance you can narrow it down a bit more? >> >> I've just tried a piglit quick test on my Bonaire and it seems to work >> perfectly fine. >> >> What hw do you test on? >> >> Regards, >> Christian. >> >> Am 13.05.2014 23:21, schrieb Marek Ol??k: >> >>> Hi Christian, >>> >>> Even though some regressions are fixed by these patches: >>> >>> drm/radeon: fix page directory update size estimation >>> drm/radeon: fix buffer placement under memory pressure v2 >>> >>> and indeed, the texelFetch tests no longer hang, there is one more >>> hang which needs to be fixed. :( All I know is the exact same commit >>> causes it and it can only be reproduced by running whole piglit with >>> concurrency enabled. >>> >>> My kernel git log: >>> >>> * 2ba22c8 - drm/radeon: fix buffer placement under memory pressure v2 >>> (10 hours ago) <Christian K?nig> >>> * 3af91e5 - drm/radeon: fix page directory update size estimation (21 >>> hours ago) <Christian K?nig> >>> * 6d2f294 - drm/radeon: use normal BOs for the page tables v4 (2 >>> months ago) <Christian K?nig> >>> * fa68834 - drm/radeon: further cleanup vm flushing & fencing (2 >>> months ago) <Christian K?nig> >>> >>> fa68834 doesn't hang, but 2ba22c8 hangs, which means 6d2f294 or either >>> of the two fixes is the first bad commit. >>> >>> Marek >>> >>> On Fri, May 9, 2014 at 8:03 PM, Marek Ol??k <maraeo at gmail.com> wrote: >>>> Hi Christian, >>>> >>>> This commit which first appeared in 3.15-rc1 causes hangs on Bonaire: >>>> >>>> commit 6d2f2944e95e504a7d33385eeeb9bb7fcca72592 >>>> Author: Christian K?nig <christian.koenig at amd.com> >>>> Date: Thu Feb 20 13:42:17 2014 +0100 >>>> >>>> drm/radeon: use normal BOs for the page tables v4 >>>> >>>> No need to make it more complicated than necessary, >>>> just allocate the page tables as normal BO and >>>> flush whenever the address change. >>>> >>>> v2: update comments and function name >>>> v3: squash bug fixes, page directory and tables patch >>>> v4: rebased on Mareks changes >>>> >>>> Signed-off-by: Christian K?nig <christian.koenig at amd.com> >>>> >>>> >>>> Reverting the commit gives me a lot of merge conflicts. >>>> >>>> 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. >>>> >>>> Any idea what is wrong with it? >>>> >>>> Thanks, >>>> >>>> Marek >>
