dri-devel June 2013

dri-devel@lists.freedesktop.org

132 participants
727 discussions

[Bug 64913] New: [r600] KSP 0.20 crashes when entering settings / starting new game.
by bugzilla-daemon＠freedesktop.org 19 Aug '13

19 Aug '13

https://bugs.freedesktop.org/show_bug.cgi?id=64913 Priority: medium Bug ID: 64913 Assignee: dri-devel(a)lists.freedesktop.org Summary: [r600] KSP 0.20 crashes when entering settings / starting new game. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: knut.tidemann(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 79702 --> https://bugs.freedesktop.org/attachment.cgi?id=79702&action=edit Backtrace of crash from gdb I tested Kerbal Space Program today (after the new 0.20 updated) and it crashes when entering 'Settings' or starting the actual game from the menu. I've attached a backtrace, and the crash seems to be the same in both cases. Atleast the same function is involved. I was running mesa from git. Last commit was: 7bfb4bea6562b2e69d0376f15224c3811da42167 Running kernel 3.8.8. The last version of the game (0.19.1) works without problems. -- You are receiving this mail because: You are the assignee for the bug.

1 24

[RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework
by Inki Dae 12 Aug '13

12 Aug '13

This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-sync&id=4030bdee9bab5841ad32faade528d04cc0c5fc94 https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-sync&id=6ca548e9ea9e865592719ef6b1cde58366af9f5c The framework performs cache operation based on the previous and current access types to the dmabufs after the locks to all dmabufs are taken: Call dma_buf_begin_cpu_access() to invalidate cache if, previous access type is DMA_BUF_ACCESS_WRITE | DMA and current access type is DMA_BUF_ACCESS_READ Call dma_buf_end_cpu_access() to clean cache if, previous access type is DMA_BUF_ACCESS_WRITE and current access type is DMA_BUF_ACCESS_READ | DMA Such cache operations are invoked via dma-buf interfaces so the dma buf exporter should implement dmabuf->ops->begin_cpu_access/end_cpu_access callbacks. [1] http://lwn.net/Articles/470339/ [2] http://lwn.net/Articles/532616/ [3] https://patchwork-mail1.kernel.org/patch/2625321/ Signed-off-by: Inki Dae <inki.dae(a)samsung.com> --- Documentation/dma-buf-sync.txt | 246 ++++++++++++++++++ drivers/base/Kconfig | 7 + drivers/base/Makefile | 1 + drivers/base/dmabuf-sync.c | 555 ++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 5 + include/linux/dmabuf-sync.h | 115 +++++++++ include/linux/reservation.h | 7 + 7 files changed, 936 insertions(+), 0 deletions(-) create mode 100644 Documentation/dma-buf-sync.txt create mode 100644 drivers/base/dmabuf-sync.c create mode 100644 include/linux/dmabuf-sync.h diff --git a/Documentation/dma-buf-sync.txt b/Documentation/dma-buf-sync.txt new file mode 100644 index 0000000..e71b6f4 --- /dev/null +++ b/Documentation/dma-buf-sync.txt @@ -0,0 +1,246 @@ + DMA Buffer Synchronization Framework + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + Inki Dae + <inki dot dae at samsung dot com> + <daeinki at gmail dot com> + +This document is a guide for device-driver writers describing the DMA buffer +synchronization API. This document also describes how to use the API to +use buffer synchronization between CPU and CPU, CPU and DMA, and DMA and DMA. + +The DMA Buffer synchronization API provides buffer synchronization mechanism; +i.e., buffer access control to CPU and DMA, cache operations, and easy-to-use +interfaces for device drivers and potentially user application +(not implemented for user applications, yet). And this API can be used for all +dma devices using system memory as dma buffer, especially for most ARM based +SoCs. + + +Motivation +---------- + +Sharing a buffer, a device cannot be aware of when the other device will access +the shared buffer: a device may access a buffer containing wrong data if +the device accesses the shared buffer while another device is still accessing +the shared buffer. Therefore, a user process should have waited for +the completion of DMA access by another device before a device tries to access +the shared buffer. + +Besides, there is the same issue when CPU and DMA are sharing a buffer; i.e., +a user process should consider that when the user process have to send a buffer +to a device driver for the device driver to access the buffer as input. +This means that a user process needs to understand how the device driver is +worked. Hence, the conventional mechanism not only makes user application +complicated but also incurs performance overhead because the conventional +mechanism cannot control devices precisely without additional and complex +implemantations. + +In addition, in case of ARM based SoCs, most devices have no hardware cache +consistency mechanisms between CPU and DMA devices because they do not use ACP +(Accelerator Coherency Port). ACP can be connected to DMA engine or similar +devices in order to keep cache coherency between CPU cache and DMA device. +Thus, we need additional cache operations to have the devices operate properly; +i.e., user applications should request cache operations to kernel before DMA +accesses the buffer and after the completion of buffer access by CPU, or vise +versa. + + buffer access by CPU -> cache clean -> buffer access by DMA + +Or, + buffer access by DMA -> cache invalidate -> buffer access by CPU + +The below shows why cache operations should be requested by user +process, + (Presume that CPU and DMA share a buffer and the buffer is mapped + with user space as cachable) + + handle = drm_gem_alloc(size); + ... + va1 = drm_gem_mmap(handle1); + va2 = malloc(size); + ... + + while(conditions) { + memcpy(va1, some data, size); + ... + drm_xxx_set_dma_buffer(handle, ...); + ... + + /* user need to request cache clean at here. */ + + /* blocked until dma operation is completed. */ + drm_xxx_start_dma(...); + ... + + /* user need to request cache invalidate at here. */ + + memcpy(va2, va1, size); + } + +The issue arises: user processes may incur cache operations: user processes may +request unnecessary cache operations to kernel. Besides, kernel cannot prevent +user processes from requesting such cache operations. Therefore, we need to +prevent such excessive and unnecessary cache operations from user processes. + + +Basic concept +------------- + +The mechanism of this framework has the following steps, + 1. Register dmabufs to a sync object - A task gets a new sync object and + can add one or more dmabufs that the task wants to access. + This registering should be performed when a device context or an event + context such as a page flip event is created or before CPU accesses a shared + buffer. + + dma_buf_sync_get(a sync object, a dmabuf); + + 2. Lock a sync object - A task tries to lock all dmabufs added in its own + sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead + lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA + and DMA. Taking a lock means that others cannot access all locked dmabufs + until the task that locked the corresponding dmabufs, unlocks all the locked + dmabufs. + This locking should be performed before DMA or CPU accesses these dmabufs. + + dma_buf_sync_lock(a sync object); + + 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync + object. The unlock means that the DMA or CPU accesses to the dmabufs have + been completed so that others may access them. + This unlocking should be performed after DMA or CPU has completed accesses + to the dmabufs. + + dma_buf_sync_unlock(a sync object); + + 4. Unregister one or all dmabufs from a sync object - A task unregisters + the given dmabufs from the sync object. This means that the task dosen't + want to lock the dmabufs. + The unregistering should be performed after DMA or CPU has completed + accesses to the dmabufs or when dma_buf_sync_lock() is failed. + + dma_buf_sync_put(a sync object, a dmabuf); + dma_buf_sync_put_all(a sync object); + + The described steps may be summarized as: + get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put + +This framework includes the following two features. + 1. read (shared) and write (exclusive) locks - A task is required to declare + the access type when the task tries to register a dmabuf; + READ, WRITE, READ DMA, or WRITE DMA. + + The below is example codes, + struct dmabuf_sync *sync; + + sync = dmabuf_sync_init(NULL, "test sync"); + + dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); + ... + + 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. + A task may never try to unlock a buffer after taking a lock to the buffer. + In this case, a timer handler to the corresponding sync object is called + in five (default) seconds and then the timed-out buffer is unlocked by work + queue handler to avoid lockups and to enforce resources of the buffer. + + +Access types +------------ + +DMA_BUF_ACCESS_READ - CPU will access a buffer for read. +DMA_BUF_ACCESS_WRITE - CPU will access a buffer for read or write. +DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA - DMA will access a buffer for read +DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA - DMA will access a buffer for read + or write. + + +API set +------- + +bool is_dmabuf_sync_supported(void) + - Check if dmabuf sync is supported or not. + +struct dmabuf_sync *dmabuf_sync_init(void *priv, const char *name) + - Allocate and initialize a new sync object. The caller can get a new + sync object for buffer synchronization. priv is used to set caller's + private data and name is the name of sync object. + +void dmabuf_sync_fini(struct dmabuf_sync *sync) + - Release all resources to the sync object. + +int dmabuf_sync_get(struct dmabuf_sync *sync, void *sync_buf, + unsigned int type) + - Add a dmabuf to a sync object. The caller can group multiple dmabufs + by calling this function several times. Internally, this function also + takes a reference to a dmabuf. + +void dmabuf_sync_put(struct dmabuf_sync *sync, struct dma_buf *dmabuf) + - Remove a given dmabuf from a sync object. Internally, this function + also release every reference to the given dmabuf. + +void dmabuf_sync_put_all(struct dmabuf_sync *sync) + - Remove all dmabufs added in a sync object. Internally, this function + also release every reference to the dmabufs of the sync object. + +int dmabuf_sync_lock(struct dmabuf_sync *sync) + - Lock all dmabufs added in a sync object. The caller should call this + function prior to CPU or DMA access to the dmabufs so that others can + not access the dmabufs. Internally, this function avoids dead lock + issue with ww-mutex. + +int dmabuf_sync_unlock(struct dmabuf_sync *sync) + - Unlock all dmabufs added in a sync object. The caller should call + this function after CPU or DMA access to the dmabufs is completed so + that others can access the dmabufs. + + +Tutorial +-------- + +1. Allocate and Initialize a sync object: + struct dmabuf_sync *sync; + + sync = dmabuf_sync_init(NULL, "test sync"); + ... + +2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: + dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); + ... + +3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: + dmabuf_sync_lock(sync); + ... + +4. Now CPU or DMA can access all dmabufs locked in step 3. + +5. Unlock all dmabufs added in a sync object after DMA or CPU access to these + dmabufs is completed: + dmabuf_sync_unlock(sync); + + And call the following functions to release all resources, + dmabuf_sync_put_all(sync); + dmabuf_sync_fini(sync); + + +Cache operation +--------------- + +The framework performs cache operation based on the previous and current access +types to the dmabufs after the locks to all dmabufs are taken: + Call dma_buf_begin_cpu_access() to invalidate cache if, + previous access type is DMA_BUF_ACCESS_WRITE | DMA and + current access type is DMA_BUF_ACCESS_READ + + Call dma_buf_end_cpu_access() to clean cache if, + previous access type is DMA_BUF_ACCESS_WRITE and + current access type is DMA_BUF_ACCESS_READ | DMA + +Such cache operations are invoked via dma-buf interfaces. Thus, the dma buf +exporter should implement dmabuf->ops->begin_cpu_access and end_cpu_access +callbacks. + + +References: +[1] https://patchwork-mail1.kernel.org/patch/2625321/ diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 5ccf182..54a1d5a 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -212,6 +212,13 @@ config FENCE_TRACE lockup related problems for dma-buffers shared across multiple devices. +config DMABUF_SYNC + bool "DMABUF Synchronization Framework" + depends on DMA_SHARED_BUFFER + help + This option enables dmabuf sync framework for buffer synchronization between + DMA and DMA, CPU and DMA, and CPU and CPU. + config CMA bool "Contiguous Memory Allocator" depends on HAVE_DMA_CONTIGUOUS && HAVE_MEMBLOCK diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 8a55cb9..599f6c90 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -11,6 +11,7 @@ obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o fence.o reservation.o +obj-$(CONFIG_DMABUF_SYNC) += dmabuf-sync.o obj-$(CONFIG_ISA) += isa.o obj-$(CONFIG_FW_LOADER) += firmware_class.o obj-$(CONFIG_NUMA) += node.o diff --git a/drivers/base/dmabuf-sync.c b/drivers/base/dmabuf-sync.c new file mode 100644 index 0000000..c8723a5 --- /dev/null +++ b/drivers/base/dmabuf-sync.c @@ -0,0 +1,555 @@ +/* + * Copyright (C) 2013 Samsung Electronics Co.Ltd + * Authors: + * Inki Dae <inki.dae(a)samsung.com> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/slab.h> +#include <linux/debugfs.h> +#include <linux/uaccess.h> + +#include <linux/dmabuf-sync.h> + +#define MAX_SYNC_TIMEOUT 5 /* Second. */ + +#define NEED_BEGIN_CPU_ACCESS(old, new) \ + (old->accessed_type == (DMA_BUF_ACCESS_WRITE | \ + DMA_BUF_ACCESS_DMA) && \ + (new->access_type == DMA_BUF_ACCESS_READ)) + +#define NEED_END_CPU_ACCESS(old, new) \ + (old->accessed_type == DMA_BUF_ACCESS_WRITE && \ + ((new->access_type == (DMA_BUF_ACCESS_READ | \ + DMA_BUF_ACCESS_DMA)) || \ + (new->access_type == (DMA_BUF_ACCESS_WRITE | \ + DMA_BUF_ACCESS_DMA)))) + +int dmabuf_sync_enabled = 1; + +MODULE_PARM_DESC(enabled, "Check if dmabuf sync is supported or not"); +module_param_named(enabled, dmabuf_sync_enabled, int, 0444); + +static void dmabuf_sync_timeout_worker(struct work_struct *work) +{ + struct dmabuf_sync *sync = container_of(work, struct dmabuf_sync, work); + struct dmabuf_sync_object *sobj; + + mutex_lock(&sync->lock); + + list_for_each_entry(sobj, &sync->syncs, head) { + if (WARN_ON(!sobj->robj)) + continue; + + printk(KERN_WARNING "%s: timeout = 0x%x [type = %d, " \ + "refcnt = %d, locked = %d]\n", + sync->name, (u32)sobj->dmabuf, + sobj->access_type, + atomic_read(&sobj->robj->shared_cnt), + sobj->robj->locked); + + /* unlock only valid sync object. */ + if (!sobj->robj->locked) + continue; + + if (sobj->robj->shared && + atomic_read(&sobj->robj->shared_cnt) > 1) { + atomic_dec(&sobj->robj->shared_cnt); + continue; + } + + ww_mutex_unlock(&sobj->robj->lock); + + if (sobj->access_type & DMA_BUF_ACCESS_READ) + printk(KERN_WARNING "%s: r-unlocked = 0x%x\n", + sync->name, (u32)sobj->dmabuf); + else + printk(KERN_WARNING "%s: w-unlocked = 0x%x\n", + sync->name, (u32)sobj->dmabuf); + +#if defined(CONFIG_DEBUG_FS) + sync_debugfs_timeout_cnt++; +#endif + } + + sync->status = 0; + mutex_unlock(&sync->lock); + + dmabuf_sync_put_all(sync); + dmabuf_sync_fini(sync); +} + +static void dmabuf_sync_cache_ops(struct dmabuf_sync *sync) +{ + struct dmabuf_sync_object *sobj; + + mutex_lock(&sync->lock); + + list_for_each_entry(sobj, &sync->syncs, head) { + struct dma_buf *dmabuf; + + dmabuf = sobj->dmabuf; + if (WARN_ON(!dmabuf || !sobj->robj)) + continue; + + /* first time access. */ + if (!sobj->robj->accessed_type) + goto out; + + if (NEED_END_CPU_ACCESS(sobj->robj, sobj)) + /* cache clean */ + dma_buf_end_cpu_access(dmabuf, 0, dmabuf->size, + DMA_TO_DEVICE); + else if (NEED_BEGIN_CPU_ACCESS(sobj->robj, sobj)) + /* cache invalidate */ + dma_buf_begin_cpu_access(dmabuf, 0, dmabuf->size, + DMA_FROM_DEVICE); + +out: + /* Update access type to new one. */ + sobj->robj->accessed_type = sobj->access_type; + } + + mutex_unlock(&sync->lock); +} + +static void dmabuf_sync_lock_timeout(unsigned long arg) +{ + struct dmabuf_sync *sync = (struct dmabuf_sync *)arg; + + schedule_work(&sync->work); +} + +static int dmabuf_sync_lock_objs(struct dmabuf_sync *sync, + struct ww_acquire_ctx *ctx) +{ + struct dmabuf_sync_object *contended_sobj = NULL; + struct dmabuf_sync_object *res_sobj = NULL; + struct dmabuf_sync_object *sobj = NULL; + int ret; + + if (ctx) + ww_acquire_init(ctx, &reservation_ww_class); + +retry: + list_for_each_entry(sobj, &sync->syncs, head) { + if (WARN_ON(!sobj->robj)) + continue; + + /* Don't lock in case of read and read. */ + if (sobj->robj->accessed_type & DMA_BUF_ACCESS_READ && + sobj->access_type & DMA_BUF_ACCESS_READ) { + atomic_inc(&sobj->robj->shared_cnt); + sobj->robj->shared = true; + continue; + } + + if (sobj == res_sobj) { + res_sobj = NULL; + continue; + } + + ret = ww_mutex_lock(&sobj->robj->lock, ctx); + if (ret < 0) { + contended_sobj = sobj; + + if (ret == -EDEADLK) + printk(KERN_WARNING"%s: deadlock = 0x%x\n", + sync->name, (u32)sobj->dmabuf); + goto err; + } + + sobj->robj->locked = true; + } + + if (ctx) + ww_acquire_done(ctx); + + init_timer(&sync->timer); + + sync->timer.data = (unsigned long)sync; + sync->timer.function = dmabuf_sync_lock_timeout; + sync->timer.expires = jiffies + (HZ * MAX_SYNC_TIMEOUT); + + add_timer(&sync->timer); + + return 0; + +err: + list_for_each_entry_continue_reverse(sobj, &sync->syncs, head) { + /* Don't need to unlock in case of read and read. */ + if (atomic_read(&sobj->robj->shared_cnt) > 1) { + atomic_dec(&sobj->robj->shared_cnt); + continue; + } + + ww_mutex_unlock(&sobj->robj->lock); + sobj->robj->locked = false; + } + + if (res_sobj) { + if (atomic_read(&res_sobj->robj->shared_cnt) > 1) + atomic_dec(&res_sobj->robj->shared_cnt); + else { + ww_mutex_unlock(&res_sobj->robj->lock); + res_sobj->robj->locked = false; + } + } + + if (ret == -EDEADLK) { + ww_mutex_lock_slow(&contended_sobj->robj->lock, ctx); + res_sobj = contended_sobj; + + goto retry; + } + + if (ctx) + ww_acquire_fini(ctx); + + return ret; +} + +static void dmabuf_sync_unlock_objs(struct dmabuf_sync *sync, + struct ww_acquire_ctx *ctx) +{ + struct dmabuf_sync_object *sobj; + + if (list_empty(&sync->syncs)) + return; + + mutex_lock(&sync->lock); + + list_for_each_entry(sobj, &sync->syncs, head) { + if (sobj->robj->shared) { + if (atomic_read(&sobj->robj->shared_cnt) > 1) { + atomic_dec(&sobj->robj->shared_cnt); + continue; + } + + ww_mutex_unlock(&sobj->robj->lock); + sobj->robj->shared = false; + sobj->robj->locked = false; + } else { + ww_mutex_unlock(&sobj->robj->lock); + sobj->robj->locked = false; + } + } + + mutex_unlock(&sync->lock); + + if (ctx) + ww_acquire_fini(ctx); + + del_timer(&sync->timer); +} + +/** + * is_dmabuf_sync_supported - Check if dmabuf sync is supported or not. + */ +bool is_dmabuf_sync_supported(void) +{ + return dmabuf_sync_enabled == 1; +} +EXPORT_SYMBOL(is_dmabuf_sync_supported); + +/** + * dmabuf_sync_init - Allocate and initialize a dmabuf sync. + * + * @priv: A device private data. + * @name: A sync object name. + * + * This function should be called when a device context or an event + * context such as a page flip event is created. And the created + * dmabuf_sync object should be set to the context. + * The caller can get a new sync object for buffer synchronization + * through this function. + */ +struct dmabuf_sync *dmabuf_sync_init(void *priv, const char *name) +{ + struct dmabuf_sync *sync; + + sync = kzalloc(sizeof(*sync), GFP_KERNEL); + if (!sync) + return ERR_PTR(-ENOMEM); + + strncpy(sync->name, name, ARRAY_SIZE(sync->name) - 1); + + sync->priv = priv; + INIT_LIST_HEAD(&sync->syncs); + mutex_init(&sync->lock); + INIT_WORK(&sync->work, dmabuf_sync_timeout_worker); + + return sync; +} +EXPORT_SYMBOL(dmabuf_sync_init); + +/** + * dmabuf_sync_fini - Release a given dmabuf sync. + * + * @sync: An object to dmabuf_sync structure. + * + * This function should be called if some operation is failed after + * dmabuf_sync_init call to release relevant resources, and after + * dmabuf_sync_unlock function is called. + */ +void dmabuf_sync_fini(struct dmabuf_sync *sync) +{ + if (WARN_ON(!sync)) + return; + + kfree(sync); +} +EXPORT_SYMBOL(dmabuf_sync_fini); + +/* + * dmabuf_sync_get_obj - Add a given object to syncs list. + * + * @sync: An object to dmabuf_sync structure. + * @dmabuf: An object to dma_buf structure. + * @type: A access type to a dma buf. + * The DMA_BUF_ACCESS_READ means that this dmabuf could be accessed by + * others for read access. On the other hand, the DMA_BUF_ACCESS_WRITE + * means that this dmabuf couldn't be accessed by others but would be + * accessed by caller's dma exclusively. And the DMA_BUF_ACCESS_DMA can be + * combined. + * + * This function creates and initializes a new dmabuf sync object and it adds + * the dmabuf sync object to syncs list to track and manage all dmabufs. + */ +static int dmabuf_sync_get_obj(struct dmabuf_sync *sync, struct dma_buf *dmabuf, + unsigned int type) +{ + struct dmabuf_sync_object *sobj; + + if (!dmabuf->resv) { + WARN_ON(1); + return -EFAULT; + } + + sobj = kzalloc(sizeof(*sobj), GFP_KERNEL); + if (!sobj) { + WARN_ON(1); + return -ENOMEM; + } + + sobj->dmabuf = dmabuf; + sobj->robj = dmabuf->resv; + + mutex_lock(&sync->lock); + list_add_tail(&sobj->head, &sync->syncs); + mutex_unlock(&sync->lock); + + get_dma_buf(dmabuf); + + sobj->access_type = type; + + return 0; +} + +/* + * dmabuf_sync_put_obj - Release a given sync object. + * + * @sync: An object to dmabuf_sync structure. + * + * This function should be called if some operation is failed after + * dmabuf_sync_get_obj call to release a given sync object. + */ +static void dmabuf_sync_put_obj(struct dmabuf_sync *sync, + struct dma_buf *dmabuf) +{ + struct dmabuf_sync_object *sobj; + + mutex_lock(&sync->lock); + + list_for_each_entry(sobj, &sync->syncs, head) { + if (sobj->dmabuf != dmabuf) + continue; + + dma_buf_put(sobj->dmabuf); + + list_del_init(&sobj->head); + kfree(sobj); + break; + } + + if (list_empty(&sync->syncs)) + sync->status = 0; + + mutex_unlock(&sync->lock); +} + +/* + * dmabuf_sync_put_objs - Release all sync objects of dmabuf_sync. + * + * @sync: An object to dmabuf_sync structure. + * + * This function should be called if some operation is failed after + * dmabuf_sync_get_obj call to release all sync objects. + */ +static void dmabuf_sync_put_objs(struct dmabuf_sync *sync) +{ + struct dmabuf_sync_object *sobj, *next; + + mutex_lock(&sync->lock); + + list_for_each_entry_safe(sobj, next, &sync->syncs, head) { + dma_buf_put(sobj->dmabuf); + + list_del_init(&sobj->head); + kfree(sobj); + } + + mutex_unlock(&sync->lock); + + sync->status = 0; +} + +/** + * dmabuf_sync_lock - lock all dmabufs added to syncs list. + * + * @sync: An object to dmabuf_sync structure. + * + * The caller should call this function prior to CPU or DMA access to + * the dmabufs so that others can not access the dmabufs. + * Internally, this function avoids dead lock issue with ww-mutex. + */ +int dmabuf_sync_lock(struct dmabuf_sync *sync) +{ + int ret; + + if (!sync) { + WARN_ON(1); + return -EFAULT; + } + + if (list_empty(&sync->syncs)) + return -EINVAL; + + if (sync->status != DMABUF_SYNC_GOT) + return -EINVAL; + + ret = dmabuf_sync_lock_objs(sync, &sync->ctx); + if (ret < 0) { + WARN_ON(1); + return ret; + } + + sync->status = DMABUF_SYNC_LOCKED; + + dmabuf_sync_cache_ops(sync); + + return ret; +} +EXPORT_SYMBOL(dmabuf_sync_lock); + +/** + * dmabuf_sync_unlock - unlock all objects added to syncs list. + * + * @sync: An object to dmabuf_sync structure. + * + * The caller should call this function after CPU or DMA access to + * the dmabufs is completed so that others can access the dmabufs. + */ +int dmabuf_sync_unlock(struct dmabuf_sync *sync) +{ + if (!sync) { + WARN_ON(1); + return -EFAULT; + } + + /* If current dmabuf sync object wasn't reserved then just return. */ + if (sync->status != DMABUF_SYNC_LOCKED) + return -EAGAIN; + + dmabuf_sync_unlock_objs(sync, &sync->ctx); + + return 0; +} +EXPORT_SYMBOL(dmabuf_sync_unlock); + +/** + * dmabuf_sync_get - initialize reservation entry and update + * dmabuf sync. + * + * @sync: An object to dmabuf_sync structure. + * @sync_buf: A dma_buf object pointer that we want to be synchronized + * with others. + * + * This function should be called after dmabuf_sync_init function is called. + * The caller can group multiple dmabufs by calling this function several + * times. Internally, this function also takes a reference to a dmabuf. + */ +int dmabuf_sync_get(struct dmabuf_sync *sync, void *sync_buf, unsigned int type) +{ + int ret; + + if (!sync || !sync_buf) { + WARN_ON(1); + return -EFAULT; + } + + ret = dmabuf_sync_get_obj(sync, sync_buf, type); + if (ret < 0) { + WARN_ON(1); + return ret; + } + + sync->status = DMABUF_SYNC_GOT; + + return 0; +} +EXPORT_SYMBOL(dmabuf_sync_get); + +/** + * dmabuf_sync_put - Release a given dmabuf. + * + * @sync: An object to dmabuf_sync structure. + * @dmabuf: An object to dma_buf structure. + * + * This function should be called if some operation is failed after + * dmabuf_sync_get function is called to release the dmabuf, or + * dmabuf_sync_unlock function is called. + */ +void dmabuf_sync_put(struct dmabuf_sync *sync, struct dma_buf *dmabuf) +{ + if (!sync || !dmabuf) { + WARN_ON(1); + return; + } + + if (list_empty(&sync->syncs)) + return; + + dmabuf_sync_put_obj(sync, dmabuf); +} +EXPORT_SYMBOL(dmabuf_sync_put); + +/** + * dmabuf_sync_put_all - Release all sync objects + * + * @sync: An object to dmabuf_sync structure. + * + * This function should be called if some operation is failed after + * dmabuf_sync_get function is called to release all sync objects, or + * dmabuf_sync_unlock function is called. + */ +void dmabuf_sync_put_all(struct dmabuf_sync *sync) +{ + if (!sync) { + WARN_ON(1); + return; + } + + if (list_empty(&sync->syncs)) + return; + + dmabuf_sync_put_objs(sync); +} +EXPORT_SYMBOL(dmabuf_sync_put_all); diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 34cfbac..f320c8e 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -150,6 +150,11 @@ struct dma_buf_attachment { void *priv; }; +#define DMA_BUF_ACCESS_READ 0x1 +#define DMA_BUF_ACCESS_WRITE 0x2 +#define DMA_BUF_ACCESS_DMA 0x4 +#define DMA_BUF_ACCESS_MAX 0x8 + /** * get_dma_buf - convenience wrapper for get_file. * @dmabuf: [in] pointer to dma_buf diff --git a/include/linux/dmabuf-sync.h b/include/linux/dmabuf-sync.h new file mode 100644 index 0000000..44c37de --- /dev/null +++ b/include/linux/dmabuf-sync.h @@ -0,0 +1,115 @@ +/* + * Copyright (C) 2013 Samsung Electronics Co.Ltd + * Authors: + * Inki Dae <inki.dae(a)samsung.com> + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + */ + +#include <linux/mutex.h> +#include <linux/sched.h> +#include <linux/dma-buf.h> +#include <linux/reservation.h> + +enum dmabuf_sync_status { + DMABUF_SYNC_GOT = 1, + DMABUF_SYNC_LOCKED, +}; + +/* + * A structure for dmabuf_sync_object. + * + * @head: A list head to be added to syncs list. + * @robj: A reservation_object object. + * @dma_buf: A dma_buf object. + * @access_type: Indicate how a current task tries to access + * a given buffer. + */ +struct dmabuf_sync_object { + struct list_head head; + struct reservation_object *robj; + struct dma_buf *dmabuf; + unsigned int access_type; +}; + +/* + * A structure for dmabuf_sync. + * + * @syncs: A list head to sync object and this is global to system. + * @list: A list entry used as committed list node + * @lock: A mutex lock to current sync object. + * @ctx: A current context for ww mutex. + * @work: A work struct to release resources at timeout. + * @priv: A private data. + * @name: A string to dmabuf sync owner. + * @timer: A timer list to avoid lockup and release resources. + * @status: Indicate current status (DMABUF_SYNC_GOT or DMABUF_SYNC_LOCKED). + */ +struct dmabuf_sync { + struct list_head syncs; + struct list_head list; + struct mutex lock; + struct ww_acquire_ctx ctx; + struct work_struct work; + void *priv; + char name[64]; + struct timer_list timer; + unsigned int status; +}; + +#ifdef CONFIG_DMABUF_SYNC +extern bool is_dmabuf_sync_supported(void); + +extern struct dmabuf_sync *dmabuf_sync_init(void *priv, const char *name); + +extern void dmabuf_sync_fini(struct dmabuf_sync *sync); + +extern int dmabuf_sync_lock(struct dmabuf_sync *sync); + +extern int dmabuf_sync_unlock(struct dmabuf_sync *sync); + +extern int dmabuf_sync_get(struct dmabuf_sync *sync, void *sync_buf, + unsigned int type); + +extern void dmabuf_sync_put(struct dmabuf_sync *sync, struct dma_buf *dmabuf); + +extern void dmabuf_sync_put_all(struct dmabuf_sync *sync); + +#else +static inline bool is_dmabuf_sync_supported(void) { return false; } + +static inline struct dmabuf_sync *dmabuf_sync_init(void *priv, + const char *names) +{ + return ERR_PTR(0); +} + +static inline void dmabuf_sync_fini(struct dmabuf_sync *sync) { } + +static inline int dmabuf_sync_lock(struct dmabuf_sync *sync) +{ + return 0; +} + +static inline int dmabuf_sync_unlock(struct dmabuf_sync *sync) +{ + return 0; +} + +static inline int dmabuf_sync_get(struct dmabuf_sync *sync, + void *sync_buf, + unsigned int type) +{ + return 0; +} + +static inline void dmabuf_sync_put(struct dmabuf_sync *sync, + struct dma_buf *dmabuf) { } + +static inline void dmabuf_sync_put_all(struct dmabuf_sync *sync) { } + +#endif diff --git a/include/linux/reservation.h b/include/linux/reservation.h index 80050e2..4310192 100644 --- a/include/linux/reservation.h +++ b/include/linux/reservation.h @@ -50,6 +50,11 @@ struct reservation_object { struct fence *fence_excl; struct fence **fence_shared; u32 fence_shared_count, fence_shared_max; + + atomic_t shared_cnt; + unsigned int accessed_type; + unsigned int shared; + unsigned int locked; }; static inline void @@ -60,6 +65,8 @@ reservation_object_init(struct reservation_object *obj) obj->fence_shared_count = obj->fence_shared_max = 0; obj->fence_shared = NULL; obj->fence_excl = NULL; + + atomic_set(&obj->shared_cnt, 1); } static inline void -- 1.7.5.4

8 49

[Bug 54143] New: Error when running GLSL_deferred
by bugzilla-daemon＠freedesktop.org 09 Aug '13

09 Aug '13

https://bugs.freedesktop.org/show_bug.cgi?id=54143 Bug #: 54143 Summary: Error when running GLSL_deferred Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: alexandre.f.demers(a)gmail.com Download and compile GLSL_deferred from http://www.autistici.org/encelo/prog_gldemos.php Mesa: User error: GL_INVALID_VALUE in glDisableVertexAttribArrayARB(index) EE r600_shader.c:1700 r600_shader_from_tgsi - GPR limit exceeded - shader requires 147 registers EE r600_shader.c:141 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:738 r600_shader_select - Failed to build shader variant (type=1, key=0) -12 With mesa git f9767dac9a06aad93a9d61d108055ad673498bf8 drm git 7080bfdfd9b6c5f003daaef37ae9c329f2d46a6c kernel 3.6.0-rc2 Using HD6950 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 43655] New: Latest radeon dri driver on HD6950 with kernel 3.2 flickers
by bugzilla-daemon＠freedesktop.org 09 Aug '13

09 Aug '13

https://bugs.freedesktop.org/show_bug.cgi?id=43655 Bug #: 43655 Summary: Latest radeon dri driver on HD6950 with kernel 3.2 flickers Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: alexandre.f.demers(a)gmail.com My new HD6950 flickers like hell right from the initialization. Using kernel 3.1.0 is just fine, but kernels 3.2.0-rc3 and over make the screen flicker (I can't tell for versions in between for now). Also, the screen seems shifted by a bit more than half my monitor's width. I also have an integrated HD3200 and I have no problem at all when selecting this integrated chipset over my PCI-E 6950 with the same driver and kernel combinations. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 36

[PATCH 0/3] Fix backlight issues on some Windows 8 systems
by Matthew Garrett 07 Aug '13

07 Aug '13

Windows 8 introduced new policy for backlight control by pushing it out to graphics drivers. This appears to have coincided with a range of vendors adding Windows 8 checks to their backlight control code which trigger either awkward behaviour (Lenovo) or complete brokenness (some Dells). The simplest thing to do would be to just disable ACPI backlight control entirely if the firmware indicates Windows 8 support, but it's entirely possible that individual graphics drivers might still make use of the ACPI functionality in preference to native control. The first two patches in this series are picked from other patchesets aimed at solving similar problems. The last simply unregisters ACPI backlight control on Windows 8 systems when using an Intel GPU. Similar code could be added to other drivers, but I'm reluctant to do so without further investigation as to the behaviour of the vendor drivers under Windows. -- Matthew Garrett | mjg59(a)srcf.ucam.org

14 73

[PATCH] drm: Don't pass negative delta to ktime_sub_ns()
by Michel Dänzer 07 Aug '13

07 Aug '13

From: Michel Dänzer <michel.daenzer(a)amd.com> It takes an unsigned value. This happens not to blow up on 64-bit architectures, but it does on 32-bit, causing drm_calc_vbltimestamp_from_scanoutpos() to calculate totally bogus timestamps for vblank events. Which in turn causes e.g. gnome-shell to hang after a DPMS off cycle with current xf86-video-ati Git. Cc: stable(a)vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> --- drivers/gpu/drm/drm_irq.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index a6a8643..39665f8 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -708,7 +708,10 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc, /* Subtract time delta from raw timestamp to get final * vblank_time timestamp for end of vblank. */ - etime = ktime_sub_ns(etime, delta_ns); + if (delta_ns < 0) + etime = ktime_add_ns(etime, -delta_ns); + else + etime = ktime_sub_ns(etime, delta_ns); *vblank_time = ktime_to_timeval(etime); DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d rep]\n", -- 1.8.3

4 6

[Bug 64503] New: audio glitches when running at 24hz/24p
by bugzilla-daemon＠freedesktop.org 03 Aug '13

03 Aug '13

https://bugs.freedesktop.org/show_bug.cgi?id=64503 Priority: medium Bug ID: 64503 Assignee: dri-devel(a)lists.freedesktop.org Summary: audio glitches when running at 24hz/24p Severity: normal Classification: Unclassified OS: All Reporter: pierre-bugzilla(a)ossman.eu Hardware: Other Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI (originally reported to Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=954009) I've recently started trying out 24 Hz again as my TV handles it better, and XBMC is finally at a point where they can keep things synced up when playing at exactly the monitor refresh rate. Unfortunately that broke the HDMI audio output. If I try to output audio when the refresh rate is at 24 Hz, the receiver will lose audio sync every few minutes, resulting in silence until it regains sync. I've tried the following: - Sending audio over SPDIF from the onboard audio to the same receiver works fine. Another cable though, and cannot handle high-bitrate formats, so hardly a long term solution. - Audio format doesn't seem to matter. I get glitches with PCM, AC3 and DTS. DTS is the worst, but that might just be because it requires more effort to sync back up again. - It's not xbmc that gets confused as sending audio from an entirely different program results in the same audio glitches (I tried mplayer with -vo null in the background). - Doesn't seem to be a application buffering issue as I see no spikes in either xbmc's or mplayer's sync statistics when the glitch appears. This is with kernel-3.8.7-201.fc18.x86_64. -- You are receiving this mail because: You are the assignee for the bug.

1 23

[Bug 59761] New: Kernel fails to reset AMD HD5770 GPU properly and encounters OOPS. GPU reset fails - system remains in unusable state.
by bugzilla-daemon＠bugzilla.kernel.org 02 Aug '13

02 Aug '13

https://bugzilla.kernel.org/show_bug.cgi?id=59761 Summary: Kernel fails to reset AMD HD5770 GPU properly and encounters OOPS. GPU reset fails - system remains in unusable state. Product: Drivers Version: 2.5 Kernel Version: 3.10 RC5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: t3st3r(a)mail.ru Regression: No Intro: This is really tricky bug. Probably GPU lockup itself is provoked by MESA and is out of scope. However, GPU lockup recovery is kernel work and that's where kernel fails in this case. Configuration: Xubuntu 13.04 64 bit running 3.10 RC5 Linux kernel. Though similar problems occurs with some older kernels as well (recent GPU reset handling rework not seems to help much). MESA should be recent 9.1 or 9.2 git to provoke GPU lockup condition. GPU is AMD HD5770, 512Mb GDDR5. libtxc-dxtn-s2tc is installed to handle To reproduce: It's enough to run Ryzom RPG (www.ryzom.com) with 128Mb textures setting. I'm using 64-bit version from launchpad PPA (https://launchpad.net/~kervala/+archive/ppa) Basically it's looks like following: 1) Launch game and let it run for some time using best (128Mb) textures on GPU like my one. 2) You can notice that on some objects textures are grabled/broken and don't display properly. Maybe data transfer error or so. Note: MESA before 9.1 lacks this bug and it will not occur. 3) After some run time GPU would encounter lockup (CP stall). Probably MESA does something wrong at code genreation. 4) Then kernel attempts to reset GPU but it never works properly. 5) All graphic output locks up since GPU driver has failed to reset GPU properly This condition is quite fatal: system responds to alt-sysrq stuff but becomes completely unusable due to lack of any graphic output. Expected: GPU is properly reset and system recovers to usable state. No kernel errors should happen during this process. One of logs with crash data follows: Jun 15 04:47:12 compname kernel: [17564.696695] radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec Jun 15 04:47:12 compname kernel: [17564.696706] radeon 0000:01:00.0: GPU lockup (waiting for 0x00000000004ae9a1 last fence id 0x00000000004ae9a0) Jun 15 04:47:12 compname kernel: [17564.697787] radeon 0000:01:00.0: Saved 119 dwords of commands on ring 0. Jun 15 04:47:12 compname kernel: [17564.697812] BUG: unable to handle kernel paging request at ffffc90012a9c418 Jun 15 04:47:12 compname kernel: [17564.697885] IP: [<ffffffffa03a2ace>] radeon_fence_process+0x8e/0x160 [radeon] Jun 15 04:47:12 compname kernel: [17564.697985] PGD 41f00f067 PUD 41f020067 PMD 417586067 PTE 0 Jun 15 04:47:12 compname kernel: [17564.698045] Oops: 0000 [#1] SMP Jun 15 04:47:12 compname kernel: [17564.698080] Modules linked in: parport_pc ppdev bnep rfcomm bluetooth snd_hda_codec_hdmi kvm_amd kvm crc32_pclmul ghash_clmulni_intel mxm_wmi aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd snd_hda_codec_realtek microcode fam15h_power snd_hda_intel serio_raw snd_ca0106 amd64_edac_mod edac_core snd_ac97_codec edac_mce_amd snd_hda_codec k10temp ac97_bus snd_hwdep snd_pcm snd_seq_midi radeon snd_page_alloc joydev sp5100_tco snd_seq_midi_event i2c_piix4 snd_rawmidi snd_seq snd_seq_device snd_timer ttm drm_kms_helper drm snd i2c_algo_bit soundcore mac_hid wmi xfs it87 hwmon_vid lp parport btrfs xor zlib_deflate hid_generic usbhid hid raid6_pq libcrc32c usb_storage firewire_ohci firewire_core pata_acpi crc_itu_t r8169 ahci pata_atiixp libahci Jun 15 04:47:12 compname kernel: [17564.698840] CPU: 6 PID: 2925 Comm: ryzom_client Not tainted 3.10.0-031000rc5-generic #201306082135 Jun 15 04:47:12 compname kernel: [17564.698914] Hardware name: Gigabyte Technology Co., Ltd. Jun 15 04:47:12 compname kernel: [17564.698991] task: ffff880414908000 ti: ffff880403afc000 task.ti: ffff880403afc000 Jun 15 04:47:12 compname kernel: [17564.699053] RIP: 0010:[<ffffffffa03a2ace>] [<ffffffffa03a2ace>] radeon_fence_process+0x8e/0x160 [radeon] Jun 15 04:47:12 compname kernel: [17564.699160] RSP: 0018:ffff880403afdc18 EFLAGS: 00010246 Jun 15 04:47:12 compname kernel: [17564.699205] RAX: ffffc90012a9c418 RBX: 0000000000000002 RCX: ffff880415134dc0 Jun 15 04:47:12 compname kernel: [17564.699264] RDX: 0000000000000041 RSI: 0000000000000000 RDI: ffff880415134000 Jun 15 04:47:12 compname kernel: [17564.699323] RBP: ffff880403afdc78 R08: ffffffff00000000 R09: ffff880415134208 Jun 15 04:47:12 compname kernel: [17564.699382] R10: 0000000000000000 R11: 0000000000000005 R12: 000000000000000c Jun 15 04:47:12 compname kernel: [17564.699441] R13: ffff880415134e08 R14: 0000000000000002 R15: ffff880415134000 Jun 15 04:47:12 compname kernel: [17564.699501] FS: 00007f6231639780(0000) GS:ffff88042fd80000(0000) knlGS:0000000000000000 Jun 15 04:47:12 compname kernel: [17564.699567] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b Jun 15 04:47:12 compname kernel: [17564.699615] CR2: ffffc90012a9c418 CR3: 00000003d049d000 CR4: 00000000000407e0 Jun 15 04:47:12 compname kernel: [17564.699674] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jun 15 04:47:12 compname kernel: [17564.699734] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jun 15 04:47:12 compname kernel: [17564.699792] Stack: Jun 15 04:47:12 compname kernel: [17564.699811] ffff880417a9c848 ffffffffa042b3d0 ffff88041918b8a0 ffff880403afdc98 Jun 15 04:47:12 compname kernel: [17564.699886] ffff880403afdc68 ffffffff8143357f 0000000000000001 ffff880415134000 Jun 15 04:47:12 compname kernel: [17564.699960] 0000000000000005 ffff880415134000 ffff880415134e38 ffff8804151345f8 Jun 15 04:47:12 compname kernel: [17564.700034] Call Trace: Jun 15 04:47:12 compname kernel: [17564.700067] [<ffffffff8143357f>] ? __dev_printk+0x5f/0xa0 Jun 15 04:47:12 compname kernel: [17564.700141] [<ffffffffa03a38c3>] radeon_fence_count_emitted+0x23/0x70 [radeon] Jun 15 04:47:12 compname kernel: [17564.700234] [<ffffffffa03b9fcb>] radeon_ring_backup+0x4b/0x130 [radeon] Jun 15 04:47:12 compname kernel: [17564.700314] [<ffffffffa038e560>] radeon_gpu_reset+0x90/0x220 [radeon] Jun 15 04:47:12 compname kernel: [17564.700402] [<ffffffffa03b8d36>] radeon_gem_wait_idle_ioctl+0xd6/0x100 [radeon] Jun 15 04:47:12 compname kernel: [17564.700486] [<ffffffffa02c658a>] drm_ioctl+0x50a/0x650 [drm] Jun 15 04:47:12 compname kernel: [17564.700568] [<ffffffffa03b8c60>] ? radeon_gem_busy_ioctl+0x120/0x120 [radeon] Jun 15 04:47:12 compname kernel: [17564.700632] [<ffffffff81082401>] ? update_curr+0x141/0x1f0 Jun 15 04:47:12 compname kernel: [17564.700684] [<ffffffff810810dd>] ? set_next_entity+0xad/0xd0 Jun 15 04:47:12 compname kernel: [17564.700738] [<ffffffff811987c7>] do_vfs_ioctl+0x87/0x330 Jun 15 04:47:12 compname kernel: [17564.700787] [<ffffffff816cab14>] ? __schedule+0x3d4/0x6b0 Jun 15 04:47:12 compname kernel: [17564.700837] [<ffffffff81198b01>] SyS_ioctl+0x91/0xb0 Jun 15 04:47:12 compname kernel: [17564.700885] [<ffffffff816d5506>] system_call_fastpath+0x1a/0x1f Jun 15 04:47:12 compname kernel: [17564.700936] Code: 49 87 55 00 48 39 d0 73 50 48 89 c3 41 ba 01 00 00 00 41 80 bf a0 16 00 00 00 4d 8b b1 f8 0b 00 00 0f 84 8a 00 00 00 48 8b 41 10 <8b> 00 48 89 da 89 c0 4c 21 c2 48 09 d0 48 39 c3 76 0c 4c 89 f2 Jun 15 04:47:12 compname kernel: [17564.701288] RIP [<ffffffffa03a2ace>] radeon_fence_process+0x8e/0x160 [radeon] Jun 15 04:47:12 compname kernel: [17564.701375] RSP <ffff880403afdc18> Jun 15 04:47:12 compname kernel: [17564.701406] CR2: ffffc90012a9c418 Jun 15 04:47:12 compname kernel: [17564.735862] ---[ end trace 5017208705d52fa8 ]--- Jun 15 04:47:17 compname kernel: [17570.145204] SysRq : Emergency Sync Jun 15 04:47:17 compname kernel: [17570.153481] Emergency Sync complete -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 3

[Bug 64695] New: Enabling both MLAA and MLAA color 2D crashes Gnome Shell on Cayman (6950)
by bugzilla-daemon＠freedesktop.org 31 Jul '13

31 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=64695 Priority: medium Bug ID: 64695 Assignee: dri-devel(a)lists.freedesktop.org Summary: Enabling both MLAA and MLAA color 2D crashes Gnome Shell on Cayman (6950) Severity: major Classification: Unclassified OS: All Reporter: alexandre.f.demers(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Forcing MLAA through driconf on Cayman 6950 crashes Gnome Shell if both mlaa and mlaa color (2D) are set (tested with both set to 8). If one of them is not set, Gnome Shell doesn't crashes. MLAA color (2D) seems to have an effect on my Gnome Shell display. Tested with mesa's commit 7e17e72cb716c56264d4778684f6f23de69a56a1. -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 65192] New: Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible)
by bugzilla-daemon＠freedesktop.org 30 Jul '13

30 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=65192 Priority: medium Bug ID: 65192 Assignee: dri-devel(a)lists.freedesktop.org Summary: Screensavers lock up machine (screen goes blank, keyboard unresponsive, sound loops; sysrq/ssh possible) Severity: major Classification: Unclassified OS: Linux (All) Reporter: luziphermcleod(a)yahoo.ie Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa For a while now, some screensavers sometimes lock up my machine. That means all screens go blank, the keyboard is unresponsive (numpad-key doesn't toggle the indicator led), the sound loops. But I still can use ssh from a remote machine and the magic-sysrq-keys also work. There is nothing to see in neither /var/log/messages (acquired via netconsole) nor /var/log/Xorg.0.log. I can trigger the bug (or regression, I think it used to work about 2 months ago) reliably by using the Xfce4 screensaver settings application, which has a preview of the screensaver selected. When switching between screensavers, the lockup quickly occurs. A good candidate is the screensaver named "AntMaze", it alsmost always locks up my machine (only worked once so far). Other stuff works quite solid, Half-Life 2 worked multiple hours today. Setting R600_HYPERZ=0 in /etc/environment didn't help. Also occurs on kernel 3.8.0-rc7. I'm happy to provide more info if needed. System Specs: Intel Core i7-965 2x Radeon HD4870 (rv770, currently only one active without xorg.conf), 2 Monitors Gentoo Linux Kernel 3.10.0-rc3 Mesa 9.2.0 (git-60f9b72) git commit 60f9b722ef80c499a94b4e5ab7304dcd739ea569 Revert "i965: fix problem with constant out of bounds access (v2)" xorg-server-1.14.1 libdrm git commit 8a88e349975a64676f143183e835e6d296f29627 modetest: Make RGB565 pwetty too xf86-video-ati git commit commit bd2557ea5ef84b975060e929d5ece53ec464336f DRI2: add interpolated blanks to frame number in event handlers -- You are receiving this mail because: You are the assignee for the bug.

1 12

← Newer
1
...
45
46
47
48
49
50
51
...
73
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2013