Re: ttm_bo_move_accel_cleanup unreserve bug ?
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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20607] FlightGear asserts and aborts in r300_mipmap_tree.c: calculate_miptree_layout
http://bugs.freedesktop.org/show_bug.cgi?id=20607 smrad...@gmail.com changed: What|Removed |Added CC|smrad...@gmail.com | --- Comment #5 from smrad...@gmail.com 2009-04-10 06:11:21 PST --- (In reply to comment #4) I forgot to say: compiz is off; my video card is ATI mobility radeon x1400. I also tried flightgear with the proprietary driver and it works without problems then. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ttm_bo_move_accel_cleanup unreserve bug ?
On Fri, 2009-04-10 at 10:14 +0200, Thomas Hellström wrote:
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
I have no more list corruption but my tree have few other fixes
it would be nice if you could check if my not missunderstanding
vm code (patch attached).
Also i was reviewing the bo move code and i think we should only
call ttm_tt_bind if mem_type is TTM_TT, right now you call bind
if mem_type != SYSTEM, so far i never saw somethings else than
TTM_TT being bind but better be safe than sorry.
A related question is what does ttm do when moving a bo from
vram to system ? My understanding is that it creates a tt object
and bind it but can the driver move callback ever get
old_memtype = VRAM new_memtype=SYSTEM ?
Btw i try to isolate all my ttm stuff in my drm-next-ttm branch
on fdo:
http://cgit.freedesktop.org/~glisse/drm-next/
Cheers,
Jerome
Only in /home/glisse/fdo/linux/drivers/gpu/drm/ttm/: built-in.o
Only in /home/glisse/fdo/linux/drivers/gpu/drm/ttm/: .built-in.o.cmd
Only in /home/glisse/fdo/linux/drivers/gpu/drm/ttm/: Makefile
Only in ttm/: Makefile.am
Only in /home/glisse/fdo/linux/drivers/gpu/drm/ttm/: modules.order
diff -u ttm/ttm_agp_backend.c /home/glisse/fdo/linux/drivers/gpu/drm/ttm/ttm_agp_backend.c
--- ttm/ttm_agp_backend.c 2009-04-07 22:22:48.0 +0200
+++ /home/glisse/fdo/linux/drivers/gpu/drm/ttm/ttm_agp_backend.c 2009-04-08 19:22:08.0 +0200
@@ -35,6 +35,7 @@
#ifdef TTM_HAS_AGP
#include ttm/ttm_placement_common.h
#include linux/agp_backend.h
+#include linux/module.h
#include asm/agp.h
#include asm/io.h
@@ -145,5 +146,6 @@
agp_be-backend.bdev = bdev;
return agp_be-backend;
}
+EXPORT_SYMBOL(ttm_agp_backend_init);
#endif
Only in /home/glisse/fdo/linux/drivers/gpu/drm/ttm/: ttm_agp_backend.o
Only in /home/glisse/fdo/linux/drivers/gpu/drm/ttm/: .ttm_agp_backend.o.cmd
Only in ttm/: ttm_bo_api.h
diff -u ttm/ttm_bo.c /home/glisse/fdo/linux/drivers/gpu/drm/ttm/ttm_bo.c
--- ttm/ttm_bo.c 2009-04-08 17:20:36.0 +0200
+++ /home/glisse/fdo/linux/drivers/gpu/drm/ttm/ttm_bo.c 2009-04-10 16:14:31.0 +0200
@@ -37,6 +37,7 @@
#include linux/sched.h
#include linux/mm.h
#include linux/file.h
+#include linux/module.h
#define TTM_ASSERT_LOCKED(param)
#define TTM_DEBUG(fmt, arg...)
@@ -63,6 +64,7 @@
BUG_ON(bo-sync_obj != NULL);
BUG_ON(bo-mem.mm_node != NULL);
BUG_ON(!list_empty(bo-lru));
+ BUG_ON(!list_empty(bo-swap));
BUG_ON(!list_empty(bo-ddestroy));
if (bo-ttm)
@@ -171,6 +173,7 @@
return 0;
}
+EXPORT_SYMBOL(ttm_bo_reserve);
static void ttm_bo_ref_bug(struct kref *list_kref)
{
@@ -208,6 +211,7 @@
wake_up_all(bo-event_queue);
spin_unlock(bdev-lru_lock);
}
+EXPORT_SYMBOL(ttm_bo_unreserve);
/*
* Call bo-mutex locked.
@@ -535,6 +539,7 @@
kref_put(bo-kref, ttm_bo_release);
write_unlock(bdev-vm_lock);
}
+EXPORT_SYMBOL(ttm_bo_unref);
static int ttm_bo_evict(struct ttm_buffer_object *bo, unsigned mem_type,
bool interruptible, bool no_wait)
@@ -813,6 +818,7 @@
ret = (has_eagain) ? -ERESTART : -ENOMEM;
return ret;
}
+EXPORT_SYMBOL(ttm_bo_mem_space);
/*
* Call bo-mutex locked.
@@ -916,6 +922,36 @@
return 1;
}
+static void ttm_bo_device_print_free_tt_size(struct ttm_bo_device *bdev)
+{
+ unsigned max_size = 0;
+ unsigned free_size = 0;
+ struct drm_mm_node *entry;
+ struct list_head *list;
+ struct list_head *free_stack;
+
+ if (!bdev-man[TTM_PL_TT].has_type || !bdev-man[TTM_PL_TT].use_type) {
+
[Bug 20954] mesa/drm(git): kernel panic with radeon driver (Radeon 9500 Pro )
http://bugs.freedesktop.org/show_bug.cgi?id=20954 Rafael Antonio Porras Samaniego sp...@distrobit.net changed: What|Removed |Added Attachment #24374|0 |1 is obsolete|| --- Comment #3 from Rafael Antonio Porras Samaniego sp...@distrobit.net 2009-04-10 08:17:18 PST --- Created an attachment (id=24695) -- (http://bugs.freedesktop.org/attachment.cgi?id=24695) Kernel panic complete message Here is the complete panic message. I've used objdump with the radeon.ko module to locate the specific line that causes the error. It seems to be this: radeon_get_vblank_counter(radeon_irq.c:307) return RADEON_READ(RADEON_CRTC2_CRNT_FRAME); de10: 8b 80 e0 00 00 00 mov0xe0(%eax),%eax de16: 8b 40 10mov0x10(%eax),%eax de19: 05 14 02 00 00 add$0x214,%eax de1e: 8b 00 mov(%eax),%eax de20: 83 c4 0cadd$0xc,%esp de23: c3 ret The problem is 0xde16(radeon_get_vblank_counter+0x76) operating with eax = NULL as you can see in the photo. I guess that dev_priv-mmio is NULL and that triggers the oops. I've tested this hypothesis adding a check: if (dev_priv-mmio == NULL) return -EINVAL; This avoids the panic. Well, this is the information I've been able to gather but I'm not an expert so I'm sorry if I've erroneously brought more darkness than light :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.9
Aka, the kick jbarnes release. Not only did I push the broken speedup patch but I flubbed the version bump, so we get to go from 2.4.7 to 2.4.9. Yay for me. Available from http://people.freedesktop.org/~jbarnes/libdrm-2.4.9.tar.* until someone in the dri group copies it over. Thanks, Jesse Jesse Barnes (3): Revert libdrm: speed up connector mode fetching Bump version to 2.4.8 Bump version to 2.4.9 git tag: libdrm-2.4.9 http://dri.freedesktop.org/libdrm/libdrm-2.4.9.tar.bz2 MD5: a7eacf9d4532391c7a53709da8f34495 libdrm-2.4.9.tar.bz2 SHA1: 75e6e198efbd0eb207fa5c5a41c73dbdf8d11976 libdrm-2.4.9.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.9.tar.gz MD5: 789eeb30da183f407664b4b3c492df4f libdrm-2.4.9.tar.gz SHA1: ca40ef9fe1cfbfd2538631d449a68bf5247bc285 libdrm-2.4.9.tar.gz -- Jesse Barnes, Intel Open Source Technology Center -- 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21067] Xorg can't enable DRI and can' t load drm anymore with the new kernel 2.6.29
http://bugs.freedesktop.org/show_bug.cgi?id=21067 TeF tefi...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
