From: Thomas H. <th...@sh...> - 2009-04-10 08:14:19
|
Jerome Glisse wrote: > On Wed, 2009-04-08 at 16:47 +0200, Thomas Hellstrom wrote: > >> Jerome Glisse wrote: >> >>> Hi Thomas, >>> >>> I think we should not ttm_bo_unreserve the bo in >>> ttm_bo_move_accel_cleanup i am seeing double unreserve >>> which likely lead to kernel list corruption and i >>> think it's due to that one (i am checking through >>> printk but the log is enormous and my script is not >>> yet done with parsing it) >>> >>> I checked code path in via using ttm_bo_move_accel_cleanup >>> and none seems to reserve the buffer before calling >>> ttm_bo_move_accel_cleanup. >>> >>> >>> >> Jerome, >> >> All buffers that are touched by the move code need to be reserved. >> What happens in the above case is that the buffer is copied in its >> reserved state, >> and thus there will be an unreserve for each copy. >> >> Please make sure, however, that you got all of the >> buffer_object_transfer fixes from the newttm branch, >> in particular the one where we clear the fbo->swap list head. >> >> /Thomas >> > > There is a bug in cleanup: > if (!(man->flags & TTM_MEMTYPE_FLAG_FIXED)) > ghost_obj->ttm = NULL; > else > ghost_obj = NULL; > Used to be > if (!(man->flags & TTM_MEMTYPE_FLAG_FIXED)) > ghost_obj->ttm = NULL; > else > bo->ttm = NULL; > > And i think it's the correct one. Note that current one lead > to oups because then you unreserve a NULL ptr. > > Jerome, You're right. Does that fix your list corruption? /Thomas > Cheers, > Jerome > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |