I've been trying to wrap my head around ttm and gem these last couple of
weeks. I found the nice 'drm_mm_dump_table' function and ran it on the
mgag200 drm_mm struct. Instant BUG in include/drm/drm_mm.h line 100.
static inline unsigned long drm_mm_hole_node_start(struct drm_mm_node *hole_node)
{
BUG_ON(!hole_node->hole_follows);
return __drm_mm_hole_node_start(hole_node);
}
where drm_mm_hole_node_start is called from drm_mm_dump_table like so:
int drm_mm_dump_table(struct seq_file *m, struct drm_mm *mm)
{
struct drm_mm_node *entry;
unsigned long total_used = 0, total_free = 0, total = 0;
unsigned long hole_start, hole_end, hole_size;
hole_start = drm_mm_hole_node_start(&mm->head_node);
...
...
...
as far as I can tell the head_node is a list of page offsets that point
to free memory chunks. It seems drm_mm_dump_table expects a free chunk
at the beginning of the list. What if all the memory is used? How can we
ALWAYS expect a free chunk at the first element? Is this a bug in
drm_mm_dump_table? Can't we just remove the first print and let the loop
do all the work that comes right after? They look the same to me.
This all started from me trying to figure out where ttm/gem is putting
buffer objects in VRAM. All the variables in a ttm_buffer_object that
looks like they hold variables either have address outside of the total
VRAM size, or 0.
When I removed the first print in drm_mm_dump_table I get the following
output:
0x00100000-0x001007e9: 0x000007e9: used
0x001007e9-0x10100000: 0x0ffff817: free
total: 268435456, used 2025 free 268433431
The board only has 16M of VRAM.
thanks,
Chris
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
