Am 28.02.2014 17:52, schrieb Lauri Kasanen: > On Fri, 28 Feb 2014 16:43:54 +0100 > Christian K?nig <deathsimple at vodafone.de> wrote: > >>>>> Am 27.02.2014 22:38, schrieb Lauri Kasanen: >>>>>> Without this, a bo may get created in the cpu-inaccessible vram. >>>>>> Before the CP engines get setup, all copies are done via cpu memcpy. >>>>>> >>>>>> This means that the cpu tries to read from inaccessible memory, fails, >>>>>> and the radeon module proceeds to disable acceleration. >>>>>> >>>>>> Doing this has no downsides, as the real VRAM size gets set as soon as >>>>>> the >>>>>> CP engines get init. >>>>>> >>>>>> This is a candidate for 3.14 fixes. >>>>> This should be unnecessary, since TTM gets initialized only seeing the >>>>> visible VRAM and later on radeon_ttm_set_active_vram_size gets called to >>>>> increase the limit. >>>>> >>>>> If this isn't the case any more we should figure out why instead of >>>>> working around it like this. >>>> Negative, TTM gets initialized with real_vram just a few lines above >>>> this patch, not visible_vram. >>> git blame shows 7a50f01a from 2009, "drm/radeon/kms: vram sizing on >>> certain r100 chips needs workaround." by Dave Airlie. >>> >>> So the TTM VRAM init has been wrong for five years, and only worked by >>> accident because until now all allocations were done bottom-up. >> Yeah, just came to the same conclusion. We probably never hit the case >> in the last five years because we don't really access the memory before >> we start the copy ring. >> >> Please fix ttm_bo_init_mm to use rdev->mc.visible_vram_size instead. >> >> That allocations are made bottom-up is relied upon in a couple of other >> cases as well, the stolen VGA memory and the UVD firmware handling for >> example. > I initially did that, but it caused some issues. I didn't investigage > it further, but I guess it has to be init to the maximum size, and then > only the size lowered, so that the change only affects lpfn.
Fair enough, probably something gets allocated on init or something like that. Please document that with a comment and resend the patch. Christian. > > - Lauri