On Tue, Jul 02, 2013 at 09:13:34AM +0100, Chris Wilson wrote: > On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote: > > On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: > > > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > > > > Every other place properly checks whether we've managed to set > > > > up the stolen allocator at boot-up properly, with the exception > > > > of the cleanup code. Which results in an ugly > > > > > > > > *ERROR* Memory manager not clean. Delaying takedown > > > > > > > > at module unload time since the drm_mm isn't initialized at all. > > > > > > > > v2: While at it check whether the stolen drm_mm is initialized instead > > > > of the more obscure stolen_base == 0 check. > > > > > > > > v3: Fix up the logic. Also we need to keep the stolen_base check in > > > > i915_gem_object_create_stolen_for_preallocated since that can be > > > > called before stolen memory is fully set up. Spotted by Chris Wilson. > > > > > > Can you grab a backtrace for stolen_base && !initialized(stolen)? Since > > > preallocated touches the stolen mm, it should be setup by that point. > > > > I haven't seen it blow up at runtime, but we have special code in > > i915_gem_object_create_stolen_for_preallocated which handles the > > !drm_mm_initialized case. So I've figured we need this. Iirc it's to allow > > us to wrap the vbios framebuffer. > > That's a different drm_mm for the ggtt. We still need the stolen mm setup > in order to allocate our memory (as we don't have the same dance to > reconstruct the reserved blocks upon initialisation of stolen). Oh right, I'll update the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
