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