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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
