From: Christopher Harvey <charvey@matrox.com>
To: dri-devel@lists.freedesktop.org
Cc: Mathieu Larouche <mathieu.larouche@matrox.com>
Subject: confused about a BUG_ON in drm_mm_dump_table
Date: Fri, 19 Apr 2013 13:58:05 -0400 [thread overview]
Message-ID: <8761zifln6.fsf@matrox.com> (raw)
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
next reply other threads:[~2013-04-19 17:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-19 17:58 Christopher Harvey [this message]
2013-04-20 10:08 ` [PATCH] drm/mm: fix dump table BUG Daniel Vetter
2013-04-20 10:11 ` Chris Wilson
2013-04-20 11:28 ` Daniel Vetter
2013-04-20 15:54 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8761zifln6.fsf@matrox.com \
--to=charvey@matrox.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=mathieu.larouche@matrox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).