Lockdep splat in nouveau, 2.6.37-rc1+
Complete dmesg attached, but the highlight is:
[ 6100.827158] [ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
[ 6100.827158] 2.6.37-rc1-00027-gff8b16d #1
[ 6100.827158] --
[ 6100.827158] kwin_opengl_tes/8245 [HC0[0]:SC0[0]:HE0:SE1] is trying to
acquire:
[ 6100.827158] (&(&dev_priv->ramin_lock)->rlock){+.+...}, at:
[] nouveau_gpuobj_del+0x6f/0x150
[ 6100.827158]
[ 6100.827158] and this task is already holding:
[ 6100.827158] (&(&dev_priv->context_switch_lock)->rlock){-.}, at:
[] nouveau_channel_free+0xf9/0x2c0
[ 6100.827158] which would create a new lock dependency:
[ 6100.827158] (&(&dev_priv->context_switch_lock)->rlock){-.} ->
(&(&dev_priv->ramin_lock)->rlock){+.+...}
{snip /}
with a gpu lockup mixed in...
[ 6100.827158] [drm] nouveau :01:00.0: GPU lockup - switching to software
fbcon
[ 6100.827158] [] do_IRQ+0x73/0xf0
[ 6100.827158] [] ret_from_intr+0x0/0xf
[ 6100.827158] [] printk+0x41/0x43
[ 6100.827158] [] nouveau_channel_alloc+0x703/0x7a0
{snip /}
The chipset is an NV50, so I've been putting up with occasional lockups
anyways, but with v2.6.36-rc and above, they've become much more common
(minutes vs. hours). I can't tell for sure if they are the same kind of
lockup. I rebuilt my kernel with lockdep to try finding something useful.
One other note: this gpu lockup leaves the cursor functional for a short time,
during which I can use sysrq to blindly sync my drives and reboot. If I wait,
the cursor locks up too, and sysrq ceases to work.
I willing to take debug patches if anyone has any ideas.
Regards,
Phil Turmel
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: nouveau-lockup-2.6.37-rc1+.dmesg
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101104/b7f5fdf6/attachment-0001.asc>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: config-2.6.37-rc1-00027-gff8b16d
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20101104/b7f5fdf6/attachment-0001.txt>
[PATCH 10/49] drivers/gpu: Use vzalloc
Signed-off-by: Joe Perches --- drivers/gpu/drm/via/via_dmablit.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/via/via_dmablit.c b/drivers/gpu/drm/via/via_dmablit.c index 9b5b4d9..3e038a3 100644 --- a/drivers/gpu/drm/via/via_dmablit.c +++ b/drivers/gpu/drm/via/via_dmablit.c @@ -235,9 +235,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg, drm_via_dmablit_t *xfer) vsg->num_pages = VIA_PFN(xfer->mem_addr + (xfer->num_lines * xfer->mem_stride - 1)) - first_pfn + 1; - if (NULL == (vsg->pages = vmalloc(sizeof(struct page *) * vsg->num_pages))) + vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages); + if (NULL == vsg->pages) return -ENOMEM; - memset(vsg->pages, 0, sizeof(struct page *) * vsg->num_pages); down_read(¤t->mm->mmap_sem); ret = get_user_pages(current, current->mm, (unsigned long)xfer->mem_addr, -- 1.7.3.1.g432b3.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/49] drivers/gpu: Use vzalloc
Signed-off-by: Joe Perches --- drivers/gpu/drm/via/via_dmablit.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/via/via_dmablit.c b/drivers/gpu/drm/via/via_dmablit.c index 9b5b4d9..3e038a3 100644 --- a/drivers/gpu/drm/via/via_dmablit.c +++ b/drivers/gpu/drm/via/via_dmablit.c @@ -235,9 +235,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg, drm_via_dmablit_t *xfer) vsg->num_pages = VIA_PFN(xfer->mem_addr + (xfer->num_lines * xfer->mem_stride - 1)) - first_pfn + 1; - if (NULL == (vsg->pages = vmalloc(sizeof(struct page *) * vsg->num_pages))) + vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages); + if (NULL == vsg->pages) return -ENOMEM; - memset(vsg->pages, 0, sizeof(struct page *) * vsg->num_pages); down_read(¤t->mm->mmap_sem); ret = get_user_pages(current, current->mm, (unsigned long)xfer->mem_addr, -- 1.7.3.1.g432b3.dirty
[PATCH 00/49] Use vzalloc not vmalloc/kmemset
Converted vmalloc/memset and vmalloc_node/memset to vzalloc or vzalloc_node using a cocci script and some editing Reduces text a little bit. Compiled x86 only. There are still vmalloc_32 with memset calls still around. Broken out to multiple patches to cc appropriate maintainers. Joe Perches (49): arch/ia64: Use vzalloc arch/mips: Use vzalloc arch/powerpc: Use vzalloc arch/s390: Use vzalloc arch/x86: Use vzalloc crypto: Use vzalloc drivers/atm: Use vzalloc drivers/block: Use vzalloc drivers/char: Use vzalloc drivers/gpu: Use vzalloc drivers/hid: Use vzalloc drivers/infiniband: Use vzalloc drivers/isdn: Use vzalloc drivers/md: Use vzalloc drivers/media: Use vzalloc drivers/mtd: Use vzalloc drivers/net/cxgb3: Use vzalloc drivers/net/cxgb4: Use vzalloc drivers/net/e1000: Use vzalloc drivers/net/e1000e: Use vzalloc drivers/net/ehea: Use vzalloc drivers/net/igb: Use vzalloc drivers/net/igbvf: Use vzalloc drivers/net/ixgb: Use vzalloc drivers/net/ixgbe: Use vzalloc drivers/net/ixgbevf: Use vzalloc drivers/net/netxen: Use vzalloc drivers/net/pch_gbe: Use vzalloc drivers/net/qlcnic: Use vzalloc drivers/net/sfc: Use vzalloc drivers/net/vxge: Use vzalloc drivers/net/bnx2.c: Use vzalloc drivers/s390: Use vzalloc drivers/scsi: Use vzalloc drivers/staging: Use vzalloc drivers/video: Use vzalloc fs/ext4: Use vzalloc fs/jffs2: Use vzalloc fs/reiserfs: Use vzalloc fs/udf: Use vzalloc fs/xfs: Use vzalloc include/linux/coda_linux.h: Use vzalloc kernel: Use vzalloc mm: Use vzalloc net/core/pktgen.c: Use vzalloc net/netfilter: Use vzalloc net/rds: Use vzalloc sound/oss/dev_table.c: Use vzalloc virt/kvm/kvm_main.c: Use vzalloc arch/ia64/kernel/perfmon.c |3 +- arch/mips/sibyte/common/sb_tbprof.c |3 +- arch/powerpc/kvm/book3s.c |6 +-- arch/powerpc/platforms/cell/spufs/lscsa_alloc.c |3 +- arch/s390/hypfs/hypfs_diag.c|3 +- arch/x86/kernel/microcode_amd.c |3 +- arch/x86/kvm/x86.c |3 +- arch/x86/mm/pageattr-test.c |3 +- crypto/deflate.c|3 +- crypto/zlib.c |3 +- drivers/atm/idt77252.c | 11 --- drivers/atm/lanai.c |3 +- drivers/block/drbd/drbd_bitmap.c|5 +-- drivers/char/agp/backend.c |3 +- drivers/char/mspec.c|5 +-- drivers/gpu/drm/via/via_dmablit.c |4 +- drivers/hid/hid-core.c |3 +- drivers/infiniband/hw/amso1100/c2_rnic.c|5 +-- drivers/infiniband/hw/ehca/ipz_pt_fn.c |5 +-- drivers/infiniband/hw/ipath/ipath_driver.c |3 +- drivers/infiniband/hw/ipath/ipath_file_ops.c| 11 ++- drivers/infiniband/hw/ipath/ipath_init_chip.c |5 +-- drivers/infiniband/hw/qib/qib_init.c|7 +--- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 10 ++ drivers/infiniband/ulp/ipoib/ipoib_main.c |3 +- drivers/isdn/i4l/isdn_common.c |4 +- drivers/isdn/mISDN/dsp_core.c |3 +- drivers/isdn/mISDN/l1oip_codec.c|6 +-- drivers/md/dm-log.c |3 +- drivers/md/dm-snap-persistent.c |3 +- drivers/md/dm-table.c |4 +-- drivers/media/dvb/ngene/ngene-core.c|3 +- drivers/media/video/mx3_camera.c|3 +- drivers/media/video/pwc/pwc-if.c|3 +- drivers/media/video/videobuf-dma-sg.c |3 +- drivers/mtd/nand/nandsim.c |3 +- drivers/mtd/ubi/vtbl.c |6 +-- drivers/net/bnx2.c | 10 +- drivers/net/cxgb3/cxgb3_offload.c |7 ++-- drivers/net/cxgb4/cxgb4_main.c |7 ++-- drivers/net/e1000/e1000_main.c |6 +-- drivers/net/e1000e/netdev.c |6 +-- drivers/net/ehea/ehea_main.c|4 +-- drivers/net/igb/igb_main.c |6 +-- drivers/net/igbvf/netdev.c |6 +-- drivers/net/ixgb/ixgb_main.c|6 +-- drivers/net/ixgbe/ixgbe_main.c | 10 ++ drivers/net/ixgbevf/ixgbevf_main.c |6 +-- drivers/net/netxen/netxen_nic_init.c|7 +--- drivers/net/pch_gbe/pch_gbe_main.c |6 +-- drivers/net/qlcnic/qlcnic_init.c|7 +--- drivers/net/sfc/filter.c|3 +- drivers/net/vxge/vxge-config.c | 37 +- drivers/s390/cio/blacklist.c|3 +- drive
[PATCH 2/2] drm/ttm: track kmap io_reserve(), only unreserve on unmap where needed
Ben,
I had something like the attached in mind, although it might be more
beneficial to do the actual refcounting in drivers that needs it. Atomic
incs and decs are expensive, but I'm not sure how expensive relative to
function pointer calls.
Patch is only compile-tested
/Thomas
On 11/04/2010 02:08 PM, Thomas Hellstrom wrote:
> On 11/04/2010 01:03 AM, Ben Skeggs wrote:
>> From: Ben Skeggs
>>
>> If the driver kmaps an object userspace is expecting to be mapped, the
>> unmap would have called down into the drivers io_unreserve() function
>> and potentially unmapped the pages from its BARs (for example) and
>> they'd
>> no longer be accessible for the userspace mapping.
>>
>> Signed-off-by: Ben Skeggs
>> ---
>> drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
>> include/drm/ttm/ttm_bo_api.h |1 +
>> 2 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> index ff358ad..e9dbe8b 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
>> @@ -467,9 +467,12 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
>> if (num_pages> 1&& !DRM_SUSER(DRM_CURPROC))
>> return -EPERM;
>> #endif
>> -ret = ttm_mem_io_reserve(bo->bdev,&bo->mem);
>> -if (ret)
>> -return ret;
>> +if (!bo->mem.bus.io_reserved) {
>> +ret = ttm_mem_io_reserve(bo->bdev,&bo->mem);
>> +if (ret)
>> +return ret;
>> +map->io_reserved = true;
>> +}
>> if (!bo->mem.bus.is_iomem) {
>> return ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
>> } else {
>> @@ -487,7 +490,10 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
>> switch (map->bo_kmap_type) {
>> case ttm_bo_map_iomap:
>> iounmap(map->virtual);
>> -ttm_mem_io_free(map->bo->bdev,&map->bo->mem);
>> +if (map->io_reserved) {
>> +ttm_mem_io_free(map->bo->bdev,&map->bo->mem);
>> +map->io_reserved = false;
>> +}
>> break;
>> case ttm_bo_map_vmap:
>> vunmap(map->virtual);
>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>> index 5afa5b5..ce998ac 100644
>> --- a/include/drm/ttm/ttm_bo_api.h
>> +++ b/include/drm/ttm/ttm_bo_api.h
>> @@ -300,6 +300,7 @@ struct ttm_bo_kmap_obj {
>> ttm_bo_map_premapped= 4 | TTM_BO_MAP_IOMEM_MASK,
>> } bo_kmap_type;
>> struct ttm_buffer_object *bo;
>> +bool io_reserved;
>> };
>>
>> /**
>>
>
> This doesn't solve the problem unfortunately. Consider the sequence
>
> kmap->io_mem_reserve
> fault()->
> kunmap->io_mem_free
> user_space_access()-> Invalid.
>
> I think this needs to be fixed by us maintaining an
> mem:io_reserved_count, where all user-space triggered io_reserves
> count as 1. A mem::user_space_io_reserved flag could be protected by
> the bo::reserve lock, whereas a reserved_count can't, since strictly
> you're allowed to kmap a bo without reserving it, but only if it's pinned
>
> /Thomas
> .
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: Fix up io_mem_reserve / free
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
drivers/gpu/drm/ttm/ttm_bo_util.c | 34 --
drivers/gpu/drm/ttm/ttm_bo_vm.c |4 ++--
include/drm/ttm/ttm_bo_api.h |5 -
include/drm/ttm/ttm_bo_driver.h |8
mm/mmap.c |2 +-
6 files changed, 43 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index ce46457..040d51c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -442,6 +442,7 @@ static void ttm_bo_cleanup_memtype_use(struct
ttm_buffer_object *bo)
bo->ttm = NULL;
}
+ ttm_mem_io_free_vm(bo->bdev, &bo->mem);
ttm_bo_mem_put(bo, &bo->mem);
atomic_set(&bo->reserved, 0);
@@ -704,7 +705,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool
interruptible,
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
- evict_mem.bus.io_reserved = false;
+ evict_mem.bus.io_reserved_vm = false;
+ atomic_set(&evict_mem.bus.io_reserved_count, -1);
placement.fpfn = 0;
placement.lpfn = 0;
@@ -1041,7 +1043,8 @@ 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 = false;
+ mem.bus.io_reserved_vm = false;
+ atomic_set(&mem.bus.io_reserved_count, -1);
/*
* Determine where to move the buffer.
*/
@@ -1166,7 +1169,8 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo->mem.num_pages = bo->num_pages;
bo->mem.mm_node = NULL;
bo->mem.page_alignment = page_alignment;
- bo->mem.bus.io_reserved = false;
+ bo->mem.bus.io_reserved_vm = false;
+ atomic_set(&bo->mem.bus.io_reserved_count, -1);
bo->buffer_start = buffer_start & PAGE_MASK;
bo->priv_flags = 0;
bo->mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
@@ -1555,7 +1559,7 @@ void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
if (!bdev->dev_mapping)
return;
unmap_mapping_range(bdev->dev_mapping, offset, holelen, 1);
- ttm_mem_io_free(bdev, &bo->mem);
+ ttm_mem_io_free_vm(bdev, &bo->mem);
}
EXPORT_SYMBOL(ttm_bo_unmap_virtual);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ff358ad..ac2b2fa 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -75,26 +75,40 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_move_ttm);
-int ttm_mem_io_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
+static int ttm_mem_io_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg
*mem)
+{
+ if (bdev->driver->io_mem_reserve &&
+ atomic_inc_and_test(&mem->bus.io_reserved_count))
+ return bdev->driver->io_mem_reserve(bdev, mem);
+ return 0;
+}
+
+static void ttm_mem_io_free(struct ttm_bo_device *bdev, struct ttm_mem_reg
*mem)
+{
+ if (bdev->driver->io_mem_reserve &&
+ atomic_add_negative(-1, &mem->bus.io_reserved_count) &&
+ bdev->driver->io_mem_free)
+ bdev->driver->io_mem_free(bdev, mem);
+}
+
+int ttm_mem_io_reserve_vm(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
{
int ret;
- if (!mem->bus.io_reserved) {
- mem->bus.io_reserved = true;
- ret = bdev->driver->io_mem_reserve(bdev, mem);
+ if (!mem->bus.io_reserved_vm) {
+ ret = ttm_mem_io_reserve(bdev, mem);
if (unlikely(ret != 0))
return ret;
+ mem->bus.io_reserved_vm = true;
}
return 0;
}
-void ttm_mem_io_free(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
+void ttm_mem_io_free_vm(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)
{
- if (bdev->driver->io_mem_reserve) {
- if (mem->bus.io_reserved) {
- mem->bus.io_reserved = false;
- bdev->driver->io_mem_free(bdev, mem);
- }
+ if (mem->bus.io_reserved_vm) {
+ mem->bus.io_reserved_vm = false;
+ ttm_mem_io_free(bdev, mem);
}
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index fe6cb77..6383cc3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -131,8 +131,8 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
spin_unlock(&bo->lock);
- ret = ttm_mem_io_reserve(bdev, &bo->mem);
- if (ret) {
+ ret = ttm_mem_io_reserve_vm(bdev, &bo->mem);
+ if (unlikely(ret != 0)) {
retval = VM_FAULT_SIGBUS;
goto out_unlock;
}
diff --git a/include/drm/t
[Bug 31046] [r600g, tiling] visual errors and GPU resets
https://bugs.freedesktop.org/show_bug.cgi?id=31046 --- Comment #5 from Tobias Jakobi 2010-11-04 17:12:58 PDT --- Now tracking the new issue in bug #31400. I'm going to return to this bug when mipmaps are working again on mesa classic. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31046] [r600g, tiling] visual errors and GPU resets
https://bugs.freedesktop.org/show_bug.cgi?id=31046 --- Comment #5 from Tobias Jakobi 2010-11-04 17:12:58 PDT --- Now tracking the new issue in bug #31400. I'm going to return to this bug when mipmaps are working again on mesa classic. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31400] New: [RV740] Mipmapping broken in drm-radeon-next / drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=31400 Summary: [RV740] Mipmapping broken in drm-radeon-next / drm-next Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: liquid.a...@gmx.net Hey there, I already partially explained this in bug #31046. With a recent drm-radeon-next or also drm-next the mipmaps are broken with both r600c and r600g. My hardware: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 4770 [RV740] libdrm, xf86-video-ati and mesa are all git master tip. Today I found some time to bisect drm-next and this commit introduces the mipmap issue: 881fe6c1d06bf49f4ab7aef212cdaf66bd059614 drm/radeon/kms: properly compute group_size on 6xx/7xx Needed for tiled surfaces. --- Link: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=881fe6c1d06bf49f4ab7aef212cdaf66bd059614 Looks like tiling_group_size has to be 256 on my hardware. Greets, Tobias -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31400] New: [RV740] Mipmapping broken in drm-radeon-next / drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=31400 Summary: [RV740] Mipmapping broken in drm-radeon-next / drm-next Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: liquid.acid at gmx.net Hey there, I already partially explained this in bug #31046. With a recent drm-radeon-next or also drm-next the mipmaps are broken with both r600c and r600g. My hardware: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 4770 [RV740] libdrm, xf86-video-ati and mesa are all git master tip. Today I found some time to bisect drm-next and this commit introduces the mipmap issue: 881fe6c1d06bf49f4ab7aef212cdaf66bd059614 drm/radeon/kms: properly compute group_size on 6xx/7xx Needed for tiled surfaces. --- Link: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=881fe6c1d06bf49f4ab7aef212cdaf66bd059614 Looks like tiling_group_size has to be 256 on my hardware. Greets, Tobias -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/2] drm/ttm: track kmap io_reserve(), only unreserve on unmap where needed
On 11/04/2010 01:03 AM, Ben Skeggs wrote:
> From: Ben Skeggs
>
> If the driver kmaps an object userspace is expecting to be mapped, the
> unmap would have called down into the drivers io_unreserve() function
> and potentially unmapped the pages from its BARs (for example) and they'd
> no longer be accessible for the userspace mapping.
>
> Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
> include/drm/ttm/ttm_bo_api.h |1 +
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index ff358ad..e9dbe8b 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -467,9 +467,12 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
> if (num_pages> 1&& !DRM_SUSER(DRM_CURPROC))
> return -EPERM;
> #endif
> - ret = ttm_mem_io_reserve(bo->bdev,&bo->mem);
> - if (ret)
> - return ret;
> + if (!bo->mem.bus.io_reserved) {
> + ret = ttm_mem_io_reserve(bo->bdev,&bo->mem);
> + if (ret)
> + return ret;
> + map->io_reserved = true;
> + }
> if (!bo->mem.bus.is_iomem) {
> return ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
> } else {
> @@ -487,7 +490,10 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
> switch (map->bo_kmap_type) {
> case ttm_bo_map_iomap:
> iounmap(map->virtual);
> - ttm_mem_io_free(map->bo->bdev,&map->bo->mem);
> + if (map->io_reserved) {
> + ttm_mem_io_free(map->bo->bdev,&map->bo->mem);
> + map->io_reserved = false;
> + }
> break;
> case ttm_bo_map_vmap:
> vunmap(map->virtual);
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 5afa5b5..ce998ac 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -300,6 +300,7 @@ struct ttm_bo_kmap_obj {
> ttm_bo_map_premapped= 4 | TTM_BO_MAP_IOMEM_MASK,
> } bo_kmap_type;
> struct ttm_buffer_object *bo;
> + bool io_reserved;
> };
>
> /**
>
This doesn't solve the problem unfortunately. Consider the sequence
kmap->io_mem_reserve
fault()->
kunmap->io_mem_free
user_space_access()-> Invalid.
I think this needs to be fixed by us maintaining an
mem:io_reserved_count, where all user-space triggered io_reserves count
as 1. A mem::user_space_io_reserved flag could be protected by the
bo::reserve lock, whereas a reserved_count can't, since strictly you're
allowed to kmap a bo without reserving it, but only if it's pinned
/Thomas
.
[Bug 31391] New: Heroes of Newerth crashes with cs parser error
https://bugs.freedesktop.org/show_bug.cgi?id=31391 Summary: Heroes of Newerth crashes with cs parser error Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: step...@ehilb.de The game Heroes of Newerth (also referred to as HoN) crashes in certain circumstances with the following error message in dmesg: [ 1797.294324] [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 26607 [ 1797.294327] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser ! It's occuring during normal gameplay in situations with high graphic workload (as far as I can tell). I was up until recently using older libs for playing HoN with the r600 driver and thus noticed this bug as a regression. It is possible to reproduce the bug quite reliably by following these steps: 1. Start HoN 2. Create a practice game 3. Select a slot and start the game 4. Select any hero and wait for the countdown or skip the countdown by pressing ready 5. As the game starts, open the test-menu at the top left of the screen and press the “Spawn”-button right of where it reads “Creeps” multiple times (~20-30 times). There should be spawning many creeps at your base. 6. Pan the viewport to include as many creeps as possible. 7. Press the “Kill”-button right next to the “Spawn”-button. 8. 1-2 seconds later the game crashes. 9. You notice the error messages in dmesg Bisecting issued the following bad commit: e62e5b0922b6554431234a8a71c7aec7cff91864 is the first bad commit commit e62e5b0922b6554431234a8a71c7aec7cff91864 Author: Andre Maasikas Date: Wed Aug 11 14:30:18 2010 +0300 r600: add support for draw_elements_base_vertex use VTX_BASE_VTX_LOC for offset, last time using INDEX_OFFSET was probably a wrong register for this :04 04 2daa2236ba96c969c80cd62b1199d0eacb56ecce 376ee1345c8cbbb51c2b1c36cb7adafac276d5d6 Msrc I tried to the best of my ability to manually revert the commit and it proved to be the cause of the bug. I'm running mesa-git right now with that commit manually reverted and HoN is running fine. Note: This might be the same bug as described in this comment: https://bugs.freedesktop.org/show_bug.cgi?id=25114#c7 Let me know if there is any information missing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31391] New: Heroes of Newerth crashes with cs parser error
https://bugs.freedesktop.org/show_bug.cgi?id=31391 Summary: Heroes of Newerth crashes with cs parser error Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: stephan at ehilb.de The game Heroes of Newerth (also referred to as HoN) crashes in certain circumstances with the following error message in dmesg: [ 1797.294324] [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 26607 [ 1797.294327] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser ! It's occuring during normal gameplay in situations with high graphic workload (as far as I can tell). I was up until recently using older libs for playing HoN with the r600 driver and thus noticed this bug as a regression. It is possible to reproduce the bug quite reliably by following these steps: 1. Start HoN 2. Create a practice game 3. Select a slot and start the game 4. Select any hero and wait for the countdown or skip the countdown by pressing ready 5. As the game starts, open the test-menu at the top left of the screen and press the ?Spawn?-button right of where it reads ?Creeps? multiple times (~20-30 times). There should be spawning many creeps at your base. 6. Pan the viewport to include as many creeps as possible. 7. Press the ?Kill?-button right next to the ?Spawn?-button. 8. 1-2 seconds later the game crashes. 9. You notice the error messages in dmesg Bisecting issued the following bad commit: e62e5b0922b6554431234a8a71c7aec7cff91864 is the first bad commit commit e62e5b0922b6554431234a8a71c7aec7cff91864 Author: Andre Maasikas Date: Wed Aug 11 14:30:18 2010 +0300 r600: add support for draw_elements_base_vertex use VTX_BASE_VTX_LOC for offset, last time using INDEX_OFFSET was probably a wrong register for this :04 04 2daa2236ba96c969c80cd62b1199d0eacb56ecce 376ee1345c8cbbb51c2b1c36cb7adafac276d5d6 Msrc I tried to the best of my ability to manually revert the commit and it proved to be the cause of the bug. I'm running mesa-git right now with that commit manually reverted and HoN is running fine. Note: This might be the same bug as described in this comment: https://bugs.freedesktop.org/show_bug.cgi?id=25114#c7 Let me know if there is any information missing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 1/2] drm/ttm: ensure ttm_mem_io_free is called on bo destruction
On 11/04/2010 01:03 AM, Ben Skeggs wrote: > From: Ben Skeggs > > Nouveau will start to use ttm_mem_io_reserve to allocate BAR VM space > for VRAM mappings, and without this call GPU address space gets leaked. > > Signed-off-by: Ben Skeggs > --- > drivers/gpu/drm/ttm/ttm_bo.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c > index dfa163b..c373cf9 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo.c > +++ b/drivers/gpu/drm/ttm/ttm_bo.c > @@ -472,6 +472,7 @@ static void ttm_bo_cleanup_memtype_use(struct > ttm_buffer_object *bo) > wake_up_all(&bo->event_queue); > spin_unlock(&glob->lru_lock); > > + ttm_mem_io_free(bo->bdev,&tmp_mem); > ttm_bo_mem_put(bo,&tmp_mem); > } > > Ideally this should be done after the last VMA is closed, but since we don't count VMAs currently. This place is just as good. However, the mem members are strictly protected by bo::reserve, so we should place this before we unreserve in the same function, Please use drm-next where ttm_bo_mem_put() is placed just before the unreserve as well. /Thomas
[Bug 29703] demos crashing on rv710 r600g
https://bugs.freedesktop.org/show_bug.cgi?id=29703 Jerome Glisse changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #9 from Jerome Glisse 2010-11-04 12:20:11 PDT --- Fixed -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29703] demos crashing on rv710 r600g
https://bugs.freedesktop.org/show_bug.cgi?id=29703 Jerome Glisse changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #9 from Jerome Glisse 2010-11-04 12:20:11 PDT --- Fixed -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH 2/2] drm/ttm: track kmap io_reserve(), only unreserve on unmap where needed
Ben,
I had something like the attached in mind, although it might be more
beneficial to do the actual refcounting in drivers that needs it. Atomic
incs and decs are expensive, but I'm not sure how expensive relative to
function pointer calls.
Patch is only compile-tested
/Thomas
On 11/04/2010 02:08 PM, Thomas Hellstrom wrote:
On 11/04/2010 01:03 AM, Ben Skeggs wrote:
From: Ben Skeggs
If the driver kmaps an object userspace is expecting to be mapped, the
unmap would have called down into the drivers io_unreserve() function
and potentially unmapped the pages from its BARs (for example) and
they'd
no longer be accessible for the userspace mapping.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
include/drm/ttm/ttm_bo_api.h |1 +
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ff358ad..e9dbe8b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -467,9 +467,12 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
if (num_pages> 1&& !DRM_SUSER(DRM_CURPROC))
return -EPERM;
#endif
-ret = ttm_mem_io_reserve(bo->bdev,&bo->mem);
-if (ret)
-return ret;
+if (!bo->mem.bus.io_reserved) {
+ret = ttm_mem_io_reserve(bo->bdev,&bo->mem);
+if (ret)
+return ret;
+map->io_reserved = true;
+}
if (!bo->mem.bus.is_iomem) {
return ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
} else {
@@ -487,7 +490,10 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
switch (map->bo_kmap_type) {
case ttm_bo_map_iomap:
iounmap(map->virtual);
-ttm_mem_io_free(map->bo->bdev,&map->bo->mem);
+if (map->io_reserved) {
+ttm_mem_io_free(map->bo->bdev,&map->bo->mem);
+map->io_reserved = false;
+}
break;
case ttm_bo_map_vmap:
vunmap(map->virtual);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 5afa5b5..ce998ac 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -300,6 +300,7 @@ struct ttm_bo_kmap_obj {
ttm_bo_map_premapped= 4 | TTM_BO_MAP_IOMEM_MASK,
} bo_kmap_type;
struct ttm_buffer_object *bo;
+bool io_reserved;
};
/**
This doesn't solve the problem unfortunately. Consider the sequence
kmap->io_mem_reserve
fault()->
kunmap->io_mem_free
user_space_access()-> Invalid.
I think this needs to be fixed by us maintaining an
mem:io_reserved_count, where all user-space triggered io_reserves
count as 1. A mem::user_space_io_reserved flag could be protected by
the bo::reserve lock, whereas a reserved_count can't, since strictly
you're allowed to kmap a bo without reserving it, but only if it's pinned
/Thomas
.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
>From 7fc680ed912c2f9f230d4d14eec47e34c83b3816 Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom
Date: Thu, 4 Nov 2010 19:27:51 +0100
Subject: [PATCH] drm/ttm: Fix up io_mem_reserve / free
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
drivers/gpu/drm/ttm/ttm_bo_util.c | 34 --
drivers/gpu/drm/ttm/ttm_bo_vm.c |4 ++--
include/drm/ttm/ttm_bo_api.h |5 -
include/drm/ttm/ttm_bo_driver.h |8
mm/mmap.c |2 +-
6 files changed, 43 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index ce46457..040d51c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -442,6 +442,7 @@ static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo)
bo->ttm = NULL;
}
+ ttm_mem_io_free_vm(bo->bdev, &bo->mem);
ttm_bo_mem_put(bo, &bo->mem);
atomic_set(&bo->reserved, 0);
@@ -704,7 +705,8 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool interruptible,
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
- evict_mem.bus.io_reserved = false;
+ evict_mem.bus.io_reserved_vm = false;
+ atomic_set(&evict_mem.bus.io_reserved_count, -1);
placement.fpfn = 0;
placement.lpfn = 0;
@@ -1041,7 +1043,8 @@ 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 = false;
+ mem.bus.io_reserved_vm = false;
+ atomic_set(&mem.bus.io_reserved_count, -1);
/*
* Determine where to move the buffer.
*/
@@ -1166,7 +1169,8 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo->mem.num_pages = bo->num_pages;
bo->mem.mm_node = NULL;
bo->mem.page_alignment = page_alignment;
- bo->mem.bus.io_reserved = false;
+ bo->mem.bus.io_reserved_vm = false;
+ atomic_set(&bo->
[PATCH] drm: idr_find (drm_gem_object_lookup) needs only rcu read locks
... other mutation of the handle idr is still serialised using spin
locks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ea1c4b0..ce63a14 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -184,7 +184,6 @@ EXPORT_SYMBOL(drm_gem_object_alloc);
static int
drm_gem_handle_delete(struct drm_file *filp, u32 handle)
{
- struct drm_device *dev;
struct drm_gem_object *obj;
/* This is gross. The idr system doesn't let us try a delete and
@@ -204,12 +203,13 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
spin_unlock(&filp->table_lock);
return -EINVAL;
}
- dev = obj->dev;
/* Release reference and decrement refcount. */
idr_remove(&filp->object_idr, handle);
spin_unlock(&filp->table_lock);
+ synchronize_rcu();
+
drm_gem_object_handle_unreference_unlocked(obj);
return 0;
@@ -257,18 +257,14 @@ drm_gem_object_lookup(struct drm_device *dev, struct
drm_file *filp,
{
struct drm_gem_object *obj;
- spin_lock(&filp->table_lock);
+ rcu_read_lock();
/* Check if we currently have a reference on the object */
obj = idr_find(&filp->object_idr, handle);
- if (obj == NULL) {
- spin_unlock(&filp->table_lock);
- return NULL;
- }
-
- drm_gem_object_reference(obj);
+ if (obj)
+ drm_gem_object_reference(obj);
- spin_unlock(&filp->table_lock);
+ rcu_read_unlock();
return obj;
}
@@ -363,11 +359,11 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
if (!(dev->driver->driver_features & DRIVER_GEM))
return -ENODEV;
- spin_lock(&dev->object_name_lock);
+ rcu_read_lock();
obj = idr_find(&dev->object_name_idr, (int) args->name);
if (obj)
drm_gem_object_reference(obj);
- spin_unlock(&dev->object_name_lock);
+ rcu_read_unlock();
if (!obj)
return -ENOENT;
--
1.7.2.3
[PATCH 2/2] drm/ttm: track kmap io_reserve(), only unreserve on unmap where needed
From: Ben Skeggs
If the driver kmaps an object userspace is expecting to be mapped, the
unmap would have called down into the drivers io_unreserve() function
and potentially unmapped the pages from its BARs (for example) and they'd
no longer be accessible for the userspace mapping.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
include/drm/ttm/ttm_bo_api.h |1 +
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ff358ad..e9dbe8b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -467,9 +467,12 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
if (num_pages > 1 && !DRM_SUSER(DRM_CURPROC))
return -EPERM;
#endif
- ret = ttm_mem_io_reserve(bo->bdev, &bo->mem);
- if (ret)
- return ret;
+ if (!bo->mem.bus.io_reserved) {
+ ret = ttm_mem_io_reserve(bo->bdev, &bo->mem);
+ if (ret)
+ return ret;
+ map->io_reserved = true;
+ }
if (!bo->mem.bus.is_iomem) {
return ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
} else {
@@ -487,7 +490,10 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
switch (map->bo_kmap_type) {
case ttm_bo_map_iomap:
iounmap(map->virtual);
- ttm_mem_io_free(map->bo->bdev, &map->bo->mem);
+ if (map->io_reserved) {
+ ttm_mem_io_free(map->bo->bdev, &map->bo->mem);
+ map->io_reserved = false;
+ }
break;
case ttm_bo_map_vmap:
vunmap(map->virtual);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 5afa5b5..ce998ac 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -300,6 +300,7 @@ struct ttm_bo_kmap_obj {
ttm_bo_map_premapped= 4 | TTM_BO_MAP_IOMEM_MASK,
} bo_kmap_type;
struct ttm_buffer_object *bo;
+ bool io_reserved;
};
/**
--
1.7.3.1
[PATCH 1/2] drm/ttm: ensure ttm_mem_io_free is called on bo destruction
From: Ben Skeggs Nouveau will start to use ttm_mem_io_reserve to allocate BAR VM space for VRAM mappings, and without this call GPU address space gets leaked. Signed-off-by: Ben Skeggs --- drivers/gpu/drm/ttm/ttm_bo.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index dfa163b..c373cf9 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -472,6 +472,7 @@ static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo) wake_up_all(&bo->event_queue); spin_unlock(&glob->lru_lock); + ttm_mem_io_free(bo->bdev, &tmp_mem); ttm_bo_mem_put(bo, &tmp_mem); } -- 1.7.3.1
[Bug 31037] [r300g] Unwanted checkerboard effect on sprites / textures
https://bugs.freedesktop.org/show_bug.cgi?id=31037 --- Comment #9 from Gerwin 2010-11-04 10:00:12 PDT --- I also added the log of the issue in webgl (see the ogg file) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31037] [r300g] Unwanted checkerboard effect on sprites / textures
https://bugs.freedesktop.org/show_bug.cgi?id=31037 --- Comment #8 from Gerwin 2010-11-04 09:59:37 PDT --- Created an attachment (id=40048) --> (https://bugs.freedesktop.org/attachment.cgi?id=40048) log of the issue in webgl -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31037] [r300g] Unwanted checkerboard effect on sprites / textures
https://bugs.freedesktop.org/show_bug.cgi?id=31037 --- Comment #9 from Gerwin 2010-11-04 10:00:12 PDT --- I also added the log of the issue in webgl (see the ogg file) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31037] [r300g] Unwanted checkerboard effect on sprites / textures
https://bugs.freedesktop.org/show_bug.cgi?id=31037 --- Comment #8 from Gerwin 2010-11-04 09:59:37 PDT --- Created an attachment (id=40048) --> (https://bugs.freedesktop.org/attachment.cgi?id=40048) log of the issue in webgl -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31383] [r600g] crash when using xeglthreads
https://bugs.freedesktop.org/show_bug.cgi?id=31383 --- Comment #2 from Kevin DeKorte 2010-11-04 09:46:17 PDT --- with glthreads you need to press the arrow keys to make it happen -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31383] [r600g] crash when using xeglthreads
https://bugs.freedesktop.org/show_bug.cgi?id=31383 --- Comment #2 from Kevin DeKorte 2010-11-04 09:46:17 PDT --- with glthreads you need to press the arrow keys to make it happen -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31383] [r600g] crash when using xeglthreads
https://bugs.freedesktop.org/show_bug.cgi?id=31383 --- Comment #1 from Kevin DeKorte 2010-11-04 09:45:01 PDT --- Seems to also happen with this command ./glthreads -n 3 -t glthreads: No explict locking. glthreads: Single display connection. XInitThreads() returned 1 (success) glthreads: creating windows glthreads: creating threads glthreads: Created thread 0x7f83360d3700 glthreads: Created thread 0x7f83358d2700 glthreads: Created thread 0x7f8327fff700 glthreads: 1: GL_RENDERER = Gallium 0.4 on RV635 glthreads: 0: GL_RENDERER = Gallium 0.4 on RV635 glthreads: 2: GL_RENDERER = Gallium 0.4 on RV635 glthreads: r600_priv.h:184: radeon_bo_unmap: Assertion `bo->map_count >= 0' failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31383] [r600g] crash when using xeglthreads
https://bugs.freedesktop.org/show_bug.cgi?id=31383 --- Comment #1 from Kevin DeKorte 2010-11-04 09:45:01 PDT --- Seems to also happen with this command ./glthreads -n 3 -t glthreads: No explict locking. glthreads: Single display connection. XInitThreads() returned 1 (success) glthreads: creating windows glthreads: creating threads glthreads: Created thread 0x7f83360d3700 glthreads: Created thread 0x7f83358d2700 glthreads: Created thread 0x7f8327fff700 glthreads: 1: GL_RENDERER = Gallium 0.4 on RV635 glthreads: 0: GL_RENDERER = Gallium 0.4 on RV635 glthreads: 2: GL_RENDERER = Gallium 0.4 on RV635 glthreads: r600_priv.h:184: radeon_bo_unmap: Assertion `bo->map_count >= 0' failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31383] New: [r600g] crash when using xeglthreads
https://bugs.freedesktop.org/show_bug.cgi?id=31383 Summary: [r600g] crash when using xeglthreads Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: kdeko...@yahoo.com Using mesa git e7f5d19a1106351f2db8f62f59f51be86eaa93df kernel 2.6.36 (kernel-2.6.35.6-37.fc13.x86_64) libdrm git xf86-video-ati git I'm able to duplicate a crash in r600g pretty reliably with this command ./xeglthreads -n 6 -t -l it gives an error: r600_priv.h:184: radeon_bo_unmap: Assertion `bo->map_count >= 0' failed. works ok with -n values < 6, but real performance drop between 4 & 5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31383] New: [r600g] crash when using xeglthreads
https://bugs.freedesktop.org/show_bug.cgi?id=31383 Summary: [r600g] crash when using xeglthreads Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: kdekorte at yahoo.com Using mesa git e7f5d19a1106351f2db8f62f59f51be86eaa93df kernel 2.6.36 (kernel-2.6.35.6-37.fc13.x86_64) libdrm git xf86-video-ati git I'm able to duplicate a crash in r600g pretty reliably with this command ./xeglthreads -n 6 -t -l it gives an error: r600_priv.h:184: radeon_bo_unmap: Assertion `bo->map_count >= 0' failed. works ok with -n values < 6, but real performance drop between 4 & 5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH 2/2] drm/ttm: track kmap io_reserve(), only unreserve on unmap where needed
On 11/04/2010 01:03 AM, Ben Skeggs wrote:
From: Ben Skeggs
If the driver kmaps an object userspace is expecting to be mapped, the
unmap would have called down into the drivers io_unreserve() function
and potentially unmapped the pages from its BARs (for example) and they'd
no longer be accessible for the userspace mapping.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 14 ++
include/drm/ttm/ttm_bo_api.h |1 +
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ff358ad..e9dbe8b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -467,9 +467,12 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
if (num_pages> 1&& !DRM_SUSER(DRM_CURPROC))
return -EPERM;
#endif
- ret = ttm_mem_io_reserve(bo->bdev,&bo->mem);
- if (ret)
- return ret;
+ if (!bo->mem.bus.io_reserved) {
+ ret = ttm_mem_io_reserve(bo->bdev,&bo->mem);
+ if (ret)
+ return ret;
+ map->io_reserved = true;
+ }
if (!bo->mem.bus.is_iomem) {
return ttm_bo_kmap_ttm(bo, start_page, num_pages, map);
} else {
@@ -487,7 +490,10 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
switch (map->bo_kmap_type) {
case ttm_bo_map_iomap:
iounmap(map->virtual);
- ttm_mem_io_free(map->bo->bdev,&map->bo->mem);
+ if (map->io_reserved) {
+ ttm_mem_io_free(map->bo->bdev,&map->bo->mem);
+ map->io_reserved = false;
+ }
break;
case ttm_bo_map_vmap:
vunmap(map->virtual);
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 5afa5b5..ce998ac 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -300,6 +300,7 @@ struct ttm_bo_kmap_obj {
ttm_bo_map_premapped= 4 | TTM_BO_MAP_IOMEM_MASK,
} bo_kmap_type;
struct ttm_buffer_object *bo;
+ bool io_reserved;
};
/**
This doesn't solve the problem unfortunately. Consider the sequence
kmap->io_mem_reserve
fault()->
kunmap->io_mem_free
user_space_access()-> Invalid.
I think this needs to be fixed by us maintaining an
mem:io_reserved_count, where all user-space triggered io_reserves count
as 1. A mem::user_space_io_reserved flag could be protected by the
bo::reserve lock, whereas a reserved_count can't, since strictly you're
allowed to kmap a bo without reserving it, but only if it's pinned
/Thomas
.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: ensure ttm_mem_io_free is called on bo destruction
On 11/04/2010 01:03 AM, Ben Skeggs wrote: From: Ben Skeggs Nouveau will start to use ttm_mem_io_reserve to allocate BAR VM space for VRAM mappings, and without this call GPU address space gets leaked. Signed-off-by: Ben Skeggs --- drivers/gpu/drm/ttm/ttm_bo.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index dfa163b..c373cf9 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -472,6 +472,7 @@ static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo) wake_up_all(&bo->event_queue); spin_unlock(&glob->lru_lock); + ttm_mem_io_free(bo->bdev,&tmp_mem); ttm_bo_mem_put(bo,&tmp_mem); } Ideally this should be done after the last VMA is closed, but since we don't count VMAs currently. This place is just as good. However, the mem members are strictly protected by bo::reserve, so we should place this before we unreserve in the same function, Please use drm-next where ttm_bo_mem_put() is placed just before the unreserve as well. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31364] [r300g] CS section size missmatch start at (../../src/radeon_textured_videofuncs.c, R300PrepareTexturedVideoCP, 2184) 66 vs 62
https://bugs.freedesktop.org/show_bug.cgi?id=31364 Michel Dänzer changed: What|Removed |Added Product|Mesa|xorg Component|Drivers/Gallium/r300|Driver/Radeon AssignedTo|dri-de...@lists.freedesktop |xorg-driver-...@lists.x.org |.org| QAContact||xorg-t...@lists.x.org --- Comment #4 from Michel Dänzer 2010-11-04 03:40:37 PDT --- This is an X driver XVideo bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31364] [r300g] CS section size missmatch start at (../../src/radeon_textured_videofuncs.c, R300PrepareTexturedVideoCP, 2184) 66 vs 62
https://bugs.freedesktop.org/show_bug.cgi?id=31364 Michel D?nzer changed: What|Removed |Added Product|Mesa|xorg Component|Drivers/Gallium/r300|Driver/Radeon AssignedTo|dri-devel at lists.freedesktop |xorg-driver-ati at lists.x.org |.org| QAContact||xorg-team at lists.x.org --- Comment #4 from Michel D?nzer 2010-11-04 03:40:37 PDT --- This is an X driver XVideo bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31364] [r300g] CS section size missmatch start at (../../src/radeon_textured_videofuncs.c, R300PrepareTexturedVideoCP, 2184) 66 vs 62
https://bugs.freedesktop.org/show_bug.cgi?id=31364 Michel Dänzer changed: What|Removed |Added Attachment #40023|text/x-log |text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31364] [r300g] CS section size missmatch start at (../../src/radeon_textured_videofuncs.c, R300PrepareTexturedVideoCP, 2184) 66 vs 62
https://bugs.freedesktop.org/show_bug.cgi?id=31364 Michel D?nzer changed: What|Removed |Added Attachment #40023|text/x-log |text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm: idr_find (drm_gem_object_lookup) needs only rcu read locks
... other mutation of the handle idr is still serialised using spin
locks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 20
1 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ea1c4b0..ce63a14 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -184,7 +184,6 @@ EXPORT_SYMBOL(drm_gem_object_alloc);
static int
drm_gem_handle_delete(struct drm_file *filp, u32 handle)
{
- struct drm_device *dev;
struct drm_gem_object *obj;
/* This is gross. The idr system doesn't let us try a delete and
@@ -204,12 +203,13 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
spin_unlock(&filp->table_lock);
return -EINVAL;
}
- dev = obj->dev;
/* Release reference and decrement refcount. */
idr_remove(&filp->object_idr, handle);
spin_unlock(&filp->table_lock);
+ synchronize_rcu();
+
drm_gem_object_handle_unreference_unlocked(obj);
return 0;
@@ -257,18 +257,14 @@ drm_gem_object_lookup(struct drm_device *dev, struct
drm_file *filp,
{
struct drm_gem_object *obj;
- spin_lock(&filp->table_lock);
+ rcu_read_lock();
/* Check if we currently have a reference on the object */
obj = idr_find(&filp->object_idr, handle);
- if (obj == NULL) {
- spin_unlock(&filp->table_lock);
- return NULL;
- }
-
- drm_gem_object_reference(obj);
+ if (obj)
+ drm_gem_object_reference(obj);
- spin_unlock(&filp->table_lock);
+ rcu_read_unlock();
return obj;
}
@@ -363,11 +359,11 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
if (!(dev->driver->driver_features & DRIVER_GEM))
return -ENODEV;
- spin_lock(&dev->object_name_lock);
+ rcu_read_lock();
obj = idr_find(&dev->object_name_idr, (int) args->name);
if (obj)
drm_gem_object_reference(obj);
- spin_unlock(&dev->object_name_lock);
+ rcu_read_unlock();
if (!obj)
return -ENOENT;
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i915: reprogram power monitoring registers on resume
From: Kyle McMartin
Fixes issue where i915_gfx_val was reporting values several
orders of magnitude higher than physically possible (without
leaving scorch marks on my thighs at least.)
Signed-off-by: Kyle McMartin
Reviewed-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_suspend.c |4 +++-
drivers/gpu/drm/i915/intel_drv.h|1 +
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 989c19d..454c064 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -862,8 +862,10 @@ int i915_restore_state(struct drm_device *dev)
/* Clock gating state */
intel_init_clock_gating(dev);
- if (HAS_PCH_SPLIT(dev))
+ if (HAS_PCH_SPLIT(dev)) {
ironlake_enable_drps(dev);
+ intel_init_emon(dev);
+ }
/* Cache mode state */
I915_WRITE (CACHE_MODE_0, dev_priv->saveCACHE_MODE_0 | 0x);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9af9f86..21551fe 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -296,6 +296,7 @@ extern void intel_crtc_fb_gamma_get(struct drm_crtc *crtc,
u16 *red, u16 *green,
extern void intel_init_clock_gating(struct drm_device *dev);
extern void ironlake_enable_drps(struct drm_device *dev);
extern void ironlake_disable_drps(struct drm_device *dev);
+extern void intel_init_emon(struct drm_device *dev);
extern int intel_pin_and_fence_fb_obj(struct drm_device *dev,
struct drm_gem_object *obj,
--
1.7.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
