https://bugs.freedesktop.org/show_bug.cgi?id=28402

--- Comment #93 from Da Fox da_fox@mad.scientist.com 2010-10-29 05:55:39 PDT --- (In reply to comment #87)

(In reply to comment #85)

...

Created an attachment (id=39651)

View: https://bugs.freedesktop.org/attachment.cgi?id=39651 Review: https://bugs.freedesktop.org/review?bug=28402&attachment=39651

...

Make sure MC vram map is >= pci aperture size

Ok, I think I found the root cause in this bug. The vram map in the memory controller needs to be >= the pci aperture size. For the systems here, the vram size is 64 MB and the aperture size is 128 MB so the vram map in the mc needs to be at least 128 MB. However, it's getting set to 64 MB.

I've tested the patch from Comment 79 for over a week now, without any issues (as expected). The patch from Comment 82 is quite similar so I assume that would work too. I'm going to test this patch now on a fresh 2.6.36.

Ok, I've tested the patch from Comment #85 for the better part of a week now, and I haven't experienced a single freeze yet. VRAM is still placed directly after GTT: ---8<--------- Oct 29 08:47:38 localhost kernel: radeon 0000:01:00.0: GTT: 256M 0xD0000000 - 0xDFFFFFFF Oct 29 08:47:38 localhost kernel: radeon 0000:01:00.0: VRAM: 128M 0xE0000000 - 0xE7FFFFFF (64M used) Oct 29 08:47:38 localhost kernel: [drm] Detected VRAM RAM=128M, BAR=128M Oct 29 08:47:38 localhost kernel: [drm] radeon: 64M of VRAM memory ready Oct 29 08:47:38 localhost kernel: [drm] radeon: 256M of GTT memory ready. Oct 29 08:47:38 localhost kernel: [drm] vram apper at 0xE0000000 Oct 29 10:42:30 localhost kernel: radeon 0000:01:00.0: GTT: 256M 0xD0000000 - 0xDFFFFFFF --->8--------- And the VRAM sizes are still a bit confusing (it's listed as 128M with 64M 'used'?)

So I can confirm that this patch indeed fixes the issue. Job well done!