search for: ttm_bo_move_buffer

...7>] mutex_lock_nested+0x56/0x3bb [<ffffffffa0346b66>] nouveau_bo_move_m2mf.isra.13+0x4d/0x130 [nouveau] [<ffffffffa034745f>] nouveau_bo_move+0xb9/0x3cb [nouveau] [<ffffffffa01979e3>] ttm_bo_handle_move_mem+0x24e/0x6b0 [ttm] [<ffffffffa0198da4>] ttm_bo_move_buffer+0x157/0x164 [ttm] [<ffffffffa0198e51>] ttm_bo_validate+0xa0/0x129 [ttm] [<ffffffffa0347c80>] nouveau_bo_validate+0x1c/0x1e [nouveau] [<ffffffffa0347d52>] nouveau_ttm_fault_reserve_notify+0xd0/0xd7 [nouveau] [<ffffffffa019abad>] ttm_bo_vm_fault+0x6...

ttm_bo_validate() calls ttm_bo_move_buffer() which calls ttm_bo_handle_move_mem() which calls bdev->driver->move() which calls nouveau_bo_move_m2mf(), which doesn't ensure synchronization (nowait == false) if the bo is moved on another channel (which is common for nv50). I suspect this to be the source of some corruption problems....

...ct_mem.mm_node = NULL; evict_mem.bus.io_reserved_vm = false; evict_mem.bus.io_reserved_count = 0; + evict_mem.bus.base = 0; + evict_mem.bus.offset = 0; + evict_mem.bus.addr = NULL; ret = ttm_bo_mem_space(bo, &placement, &evict_mem, ctx); if (ret) { @@ -1084,6 +1087,9 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object *bo, mem.page_alignment = bo->mem.page_alignment; mem.bus.io_reserved_vm = false; mem.bus.io_reserved_count = 0; + mem.bus.base = 0; + mem.bus.offset = 0; + mem.bus.addr = NULL; mem.mm_node = NULL; /* @@ -1243,6 +1249,9 @@ int ttm_bo_init_reserved(struct ttm_...

...>] nouveau_bo_wr32+0x6a7/0x735 [nouveau] [ 14.072621] [<f81a092c>] ? ttm_bo_mem_space+0x16b/0x840 [ttm] [ 14.072649] [<f8217588>] ? nouveau_bo_wr32+0x3ab/0x735 [nouveau] [ 14.072660] [<f819fe80>] ttm_bo_unmap_virtual+0x1ec/0x45f [ttm] [ 14.072672] [<f81a13a6>] ttm_bo_move_buffer+0x9b/0xd5 [ttm] [ 14.072683] [<f81a1465>] ttm_bo_validate+0x85/0xc6 [ttm] [ 14.072695] [<f81a1736>] ttm_bo_init+0x290/0x2bb [ttm] [ 14.072722] [<f8217e40>] nouveau_bo_new+0x29a/0x396 [nouveau] [ 14.072749] [<f8217ea5>] ? nouveau_bo_new+0x2ff/0x396 [nouveau] [ 1...

...ol interruptible, struct ttm_placement placement; int ret = 0; - spin_lock(&bdev->fence_lock); ret = ttm_bo_wait(bo, false, interruptible, no_wait_gpu); - spin_unlock(&bdev->fence_lock); if (unlikely(ret != 0)) { if (ret != -ERESTARTSYS) { @@ -963,7 +953,6 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object *bo, { int ret = 0; struct ttm_mem_reg mem; - struct ttm_bo_device *bdev = bo->bdev; lockdep_assert_held(&bo->resv->lock.base); @@ -972,9 +961,7 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object *bo, * Have the driver move function wait fo...

...interrupt+0x95/0xd0 Jun 11 15:08:00 myhost kernel: [ 8670.323511] [<f84bcff0>] ? nouveau_bo_move+0x0/0x410 [nouveau] Jun 11 15:08:00 myhost kernel: [ 8670.323519] [<f840b3d7>] ? ttm_bo_handle_move_mem+0xf7/0x330 [ttm] Jun 11 15:08:00 myhost kernel: [ 8670.323527] [<f840d01d>] ? ttm_bo_move_buffer+0xfd/0x120 [ttm] Jun 11 15:08:00 myhost kernel: [ 8670.323535] [<f840d0ce>] ? ttm_bo_validate+0x8e/0x120 [ttm] Jun 11 15:08:00 myhost kernel: [ 8670.323547] [<f84bd9a5>] ? validate_list+0xa5/0x280 [nouveau] Jun 11 15:08:00 myhost kernel: [ 8670.323561] [<f84be6a0>] ? nouveau_ge...

https://bugs.freedesktop.org/show_bug.cgi?id=70927 Priority: medium Bug ID: 70927 Assignee: nouveau at lists.freedesktop.org Summary: nv50_instobj_wr32 kernel panic Severity: normal Classification: Unclassified OS: Linux (All) Reporter: antoniovazquezblanco at gmail.com Hardware: x86-64 (AMD64)

Hi guys, so I got some hardware and tested this and after hammering out tons of typos it now seems to work fine. Could you give it more testing? Thanks in advance, Christian

...c int ttm_bo_evict(struct ttm_buffer_object *bo, evict_mem = bo->mem; evict_mem.mm_node = NULL; - evict_mem.bus.io_reserved_vm = false; - evict_mem.bus.io_reserved_count = 0; evict_mem.bus.base = 0; evict_mem.bus.offset = 0; evict_mem.bus.addr = NULL; @@ -1085,8 +1076,6 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object *bo, mem.num_pages = bo->num_pages; mem.size = mem.num_pages << PAGE_SHIFT; mem.page_alignment = bo->mem.page_alignment; - mem.bus.io_reserved_vm = false; - mem.bus.io_reserved_count = 0; mem.bus.base = 0; mem.bus.offset = 0; mem.bus.addr = NULL; @@...

http://bugs.freedesktop.org/show_bug.cgi?id=26521 Summary: Bug in kernel module - ttm_bo_pci_offset Product: xorg Version: 7.4 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

https://bugs.freedesktop.org/show_bug.cgi?id=64774 Priority: medium Bug ID: 64774 Assignee: nouveau at lists.freedesktop.org Summary: nouveau GF108 kernel crash in optimus mode when enabling external display output QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified

Just a gentle ping on this. Already got the Acked-by from Daniel, but I need some of the nouveau guys to test this since I can only compile test it. Regards, Christian.

...ithium kernel: [<f89e2db1>] ? ttm_bo_mem_space +0x7a3/0x88b [ttm] May 1 08:37:16 lithium kernel: [<c1022a7f>] ? select_task_rq_fair +0x4c8/0x81d May 1 08:37:16 lithium kernel: [<f89e29a8>] ? ttm_bo_mem_space +0x39a/0x88b [ttm] May 1 08:37:16 lithium kernel: [<f89e31f2>] ? ttm_bo_move_buffer +0x84/0xda [ttm] May 1 08:37:16 lithium kernel: [<f89e32c7>] ? ttm_bo_validate+0x7f/0xc1 [ttm] May 1 08:37:16 lithium kernel: [<f8bc78b0>] ? nouveau_gem_ioctl_cpu_prep+0x23f/0x42c [nouveau] May 1 08:37:16 lithium kernel: [<f8bc8654>] ? nouveau_gem_ioctl_pushbuf +0xbb7/0xbd2 [no...

While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. The patch should be functional correct, but is only compile tested! Signed-off-by: Christian König <christian.koenig at

Hi guys, I've already send this out in September last year, but only got a response from Daniel. Could you guys please test this and tell me what you think about it? Basically I'm trying to remove all driver specific features from TTM which don't need to be inside the framework. Thanks, Christian.

https://bugs.freedesktop.org/show_bug.cgi?id=28763 Summary: Kernel Oops when displaying a large image Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau at lists.freedesktop.org

This series depends on the previously posted reservation api patches. 2 of them are not yet in for-next-fences branch of git://git.linaro.org/people/sumit.semwal/linux-3.x.git The missing patches are still in my vmwgfx_wip branch at git://people.freedesktop.org/~mlankhorst/linux All ttm drivers are converted to the fence api, fence_lock is removed and rcu is used in its place. qxl is the first

fence_is_signaled callback should support being run in atomic context, but not in irq context. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- include/linux/fence.h | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux/fence.h b/include/linux/fence.h index d174585b874b..c1a4519ba2f5 100644 ---

This series applies on top of the driver-core-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git Before converting ttm to the new fence interface I had to fix some drivers to require a reservation before poking with fence_obj. After flipping the switch RCU becomes available instead, and the extra reservations can be dropped again. :-) I've done at least basic