Re: Moving a bug upstream per downstream request, emailing the maintainers
On Thu, Aug 15, 2013 at 03:28:53PM -0400, John Hupp wrote: > [1.] One line summary of the problem: > Flash 11.2 content displays in shades of green and purple only, and > in a horizontally compressed space > > [2.] Full description of the problem/report: > The full downstream bug report is at > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1212455 , but > my description from there: > > In my testing with the Intel driver using its default acceleration: > - Flash 11.2 works on Quantal with the 3.5 kernel > - Flash 11.2 works on Raring with the 3.5.0-17 kernel (though it > boots to a low-res desktop with a frozen pointer) > - Flash 11.2 works on Raring also with the 3.6.11-030611 or > 3.7.10-030710 mainline kernels > - Flash 11.8 works on Raring with the 3.8 kernel (in Chrome) > - Flash 11.2 fails on Raring with the 3.8 kernel > - Flash 11.2 fails on Raring with the latest mainline kernel, > 3.11.0-031100rc5 > - Flash 11.2 fails on Saucy alpha 2 with its default kernel It's a flash bug. They ignore the format of the Window that they PutImage to. (Worse, they create an image of the right depth or else X would reject the PutImage with a BadMatch and then render incorrect pixel data into it.) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68178] New: evergreen: hard lockup on suspend and resume with current firmware
https://bugs.freedesktop.org/show_bug.cgi?id=68178 Priority: medium Bug ID: 68178 Assignee: dri-devel@lists.freedesktop.org Summary: evergreen: hard lockup on suspend and resume with current firmware Severity: major Classification: Unclassified OS: Linux (All) Reporter: n...@detonation.org Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 84133 --> https://bugs.freedesktop.org/attachment.cgi?id=84133&action=edit dmesg of my system for information As soon as the up to date firmware package is installed, my system hangs on suspend and again on resume with the screen turned off and the system not reacting to anything. Tested it on various kernels with the earliest being 3.7.10 (current openSUSE kernel) and the latest being 3.11-rc5. I tried to get more information, but there are no logs, the screen is turned off and even netconsole did not show more. Do you have suggestions about how to debug this or things that I can try to narrow it down? My GPU is a: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Redwood [Radeon HD 5670] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e151 Flags: bus master, fast devsel, latency 0, IRQ 48 Memory at e000 (64-bit, prefetchable) [size=256M] Memory at f442 (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at f440 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon Attaching dmesg of a running system just for info. -- 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 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #68 from Tomasz P. --- Maybe post this to mesa-dev mailing list.I doubt that they have time to read this. -- 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
[PATCH] drm: Eliminate dev->vmalist
The primary purpose of this list is for pretty printing the maps through
debugfs/vma - per process information can be found in /proc/*/map et al.
However, the list manipulation eats processor cycles resulting in a near
indefinite (I got bored) stall for a leaky i-g-t/gem_concurrent_blit.
There is one true user of the vmalist though. drm_vm_shm_close() uses
the list to count the number of drm_local_map references. For this, we
switch to using a counter inside drm_local_map.
This patch kills drm_vm_open_locked and drm_vm_close_locked, and
redirects the one user outside of the core (exoynos) to use the now
semantically equivalent drm_gem_vm_open.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: Rob Clark
Cc: Inki Dae
---
drivers/gpu/drm/drm_bufs.c | 1 +
drivers/gpu/drm/drm_drv.c | 8 -
drivers/gpu/drm/drm_gem.c | 16 +++--
drivers/gpu/drm/drm_info.c | 38 -
drivers/gpu/drm/drm_stub.c | 1 -
drivers/gpu/drm/drm_vm.c| 58 +++--
drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
include/drm/drmP.h | 7 ++--
8 files changed, 20 insertions(+), 118 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index bef4abf..b0aa2eb 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -152,6 +152,7 @@ static int drm_addmap_core(struct drm_device * dev,
resource_size_t offset,
map->size = size;
map->flags = flags;
map->type = type;
+ map->count = 0;
/* Only allow shared memory to be removable since we only keep enough
* book keeping information about shared memory to allow for removal
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 799..7ec9959 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -182,8 +182,6 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
*/
int drm_lastclose(struct drm_device * dev)
{
- struct drm_vma_entry *vma, *vma_temp;
-
DRM_DEBUG("\n");
if (dev->driver->lastclose)
@@ -203,12 +201,6 @@ int drm_lastclose(struct drm_device * dev)
dev->sg = NULL;
}
- /* Clear vma list (only built for debugging) */
- list_for_each_entry_safe(vma, vma_temp, &dev->vmalist, head) {
- list_del(&vma->head);
- kfree(vma);
- }
-
if (drm_core_check_feature(dev, DRIVER_HAVE_DMA) &&
!drm_core_check_feature(dev, DRIVER_MODESET))
drm_dma_takedown(dev);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 9ab038c..84a5834 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -573,22 +573,16 @@ void drm_gem_vm_open(struct vm_area_struct *vma)
struct drm_gem_object *obj = vma->vm_private_data;
drm_gem_object_reference(obj);
-
- mutex_lock(&obj->dev->struct_mutex);
- drm_vm_open_locked(obj->dev, vma);
- mutex_unlock(&obj->dev->struct_mutex);
+ drm_vma_open(obj->dev, vma);
}
EXPORT_SYMBOL(drm_gem_vm_open);
void drm_gem_vm_close(struct vm_area_struct *vma)
{
struct drm_gem_object *obj = vma->vm_private_data;
- struct drm_device *dev = obj->dev;
- mutex_lock(&dev->struct_mutex);
- drm_vm_close_locked(obj->dev, vma);
- drm_gem_object_unreference(obj);
- mutex_unlock(&dev->struct_mutex);
+ drm_vma_close(obj->dev, vma);
+ drm_gem_object_unreference_unlocked(obj);
}
EXPORT_SYMBOL(drm_gem_vm_close);
@@ -639,9 +633,7 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned
long obj_size,
* (which should happen whether the vma was created by this call, or
* by a vm_open due to mremap or partial unmap or whatever).
*/
- drm_gem_object_reference(obj);
-
- drm_vm_open_locked(dev, vma);
+ drm_gem_vm_open(vma);
return 0;
}
EXPORT_SYMBOL(drm_gem_mmap_obj);
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index d4b20ce..6ea817c 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -228,49 +228,11 @@ int drm_vma_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
- struct drm_vma_entry *pt;
- struct vm_area_struct *vma;
-#if defined(__i386__)
- unsigned int pgprot;
-#endif
- mutex_lock(&dev->struct_mutex);
seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
atomic_read(&dev->vma_count),
high_memory, (void *)(unsigned
long)virt_to_phys(high_memory));
- list_for_each_entry(pt, &dev->vmalist, head) {
- vma = pt->vma;
- if (!vma)
- continue;
- seq_printf(m,
- "\n%5d 0x%
Re: [PATCH] drm/ttm: kill unused functions
Reviewed-by: Thomas Hellstrom
On 08/15/2013 04:03 PM, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 159
1 file changed, 159 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 3df9f16..87906c2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -304,162 +304,3 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct
ttm_buffer_object *bo)
return 0;
}
EXPORT_SYMBOL(ttm_fbdev_mmap);
-
-
-ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file *filp,
- const char __user *wbuf, char __user *rbuf, size_t count,
- loff_t *f_pos, bool write)
-{
- struct ttm_buffer_object *bo;
- struct ttm_bo_driver *driver;
- struct ttm_bo_kmap_obj map;
- unsigned long dev_offset = (*f_pos >> PAGE_SHIFT);
- unsigned long kmap_offset;
- unsigned long kmap_end;
- unsigned long kmap_num;
- size_t io_size;
- unsigned int page_offset;
- char *virtual;
- int ret;
- bool no_wait = false;
- bool dummy;
-
- read_lock(&bdev->vm_lock);
- bo = ttm_bo_vm_lookup_rb(bdev, dev_offset, 1);
- if (likely(bo != NULL))
- ttm_bo_reference(bo);
- read_unlock(&bdev->vm_lock);
-
- if (unlikely(bo == NULL))
- return -EFAULT;
-
- driver = bo->bdev->driver;
- if (unlikely(!driver->verify_access)) {
- ret = -EPERM;
- goto out_unref;
- }
-
- ret = driver->verify_access(bo, filp);
- if (unlikely(ret != 0))
- goto out_unref;
-
- kmap_offset = dev_offset - bo->vm_node->start;
- if (unlikely(kmap_offset >= bo->num_pages)) {
- ret = -EFBIG;
- goto out_unref;
- }
-
- page_offset = *f_pos & ~PAGE_MASK;
- io_size = bo->num_pages - kmap_offset;
- io_size = (io_size << PAGE_SHIFT) - page_offset;
- if (count < io_size)
- io_size = count;
-
- kmap_end = (*f_pos + count - 1) >> PAGE_SHIFT;
- kmap_num = kmap_end - kmap_offset + 1;
-
- ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
-
- switch (ret) {
- case 0:
- break;
- case -EBUSY:
- ret = -EAGAIN;
- goto out_unref;
- default:
- goto out_unref;
- }
-
- ret = ttm_bo_kmap(bo, kmap_offset, kmap_num, &map);
- if (unlikely(ret != 0)) {
- ttm_bo_unreserve(bo);
- goto out_unref;
- }
-
- virtual = ttm_kmap_obj_virtual(&map, &dummy);
- virtual += page_offset;
-
- if (write)
- ret = copy_from_user(virtual, wbuf, io_size);
- else
- ret = copy_to_user(rbuf, virtual, io_size);
-
- ttm_bo_kunmap(&map);
- ttm_bo_unreserve(bo);
- ttm_bo_unref(&bo);
-
- if (unlikely(ret != 0))
- return -EFBIG;
-
- *f_pos += io_size;
-
- return io_size;
-out_unref:
- ttm_bo_unref(&bo);
- return ret;
-}
-
-ssize_t ttm_bo_fbdev_io(struct ttm_buffer_object *bo, const char __user *wbuf,
- char __user *rbuf, size_t count, loff_t *f_pos,
- bool write)
-{
- struct ttm_bo_kmap_obj map;
- unsigned long kmap_offset;
- unsigned long kmap_end;
- unsigned long kmap_num;
- size_t io_size;
- unsigned int page_offset;
- char *virtual;
- int ret;
- bool no_wait = false;
- bool dummy;
-
- kmap_offset = (*f_pos >> PAGE_SHIFT);
- if (unlikely(kmap_offset >= bo->num_pages))
- return -EFBIG;
-
- page_offset = *f_pos & ~PAGE_MASK;
- io_size = bo->num_pages - kmap_offset;
- io_size = (io_size << PAGE_SHIFT) - page_offset;
- if (count < io_size)
- io_size = count;
-
- kmap_end = (*f_pos + count - 1) >> PAGE_SHIFT;
- kmap_num = kmap_end - kmap_offset + 1;
-
- ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
-
- switch (ret) {
- case 0:
- break;
- case -EBUSY:
- return -EAGAIN;
- default:
- return ret;
- }
-
- ret = ttm_bo_kmap(bo, kmap_offset, kmap_num, &map);
- if (unlikely(ret != 0)) {
- ttm_bo_unreserve(bo);
- return ret;
- }
-
- virtual = ttm_kmap_obj_virtual(&map, &dummy);
- virtual += page_offset;
-
- if (write)
- ret = copy_from_user(virtual, wbuf, io_size);
- else
- ret = copy_to_user(rbuf, virtual, io_size);
-
- ttm_bo_kunmap(&map);
- ttm_bo_unreserve(bo);
- ttm_bo_unref(&bo);
-
- if (unlikely(ret != 0))
- return ret;
-
- *f_pos += io_size;
-
- return io_size;
-}
___
[Bug 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 Alex Deucher changed: What|Removed |Added Summary|evergreen: hard lockup on |evergreen: hard lockup on |suspend and resume with |suspend and resume with dpm |current firmware| --- Comment #1 from Alex Deucher --- It's not the firmware per se. It's probably the new dpm code. Do you still get when dpm is disabled? -- 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 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #69 from Alex Deucher --- I would recommend you do a piglit run (quick driver tests) before and after and make sure there are no regressions. -- 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
Re: [PATCH 08/16] drm/vmwgfx: implement mmap access managament
Hi
On Wed, Aug 14, 2013 at 7:35 PM, Thomas Hellstrom wrote:
> (CC'ing the proper people since I'm still on parental leave).
>
> On 08/13/2013 11:44 PM, David Herrmann wrote:
>
> Please see inline comments.
>
>
>> Hi
>>
>> On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann
>> wrote:
>>>
>>> Correctly allow and revoke buffer access on each open/close via the new
>>> VMA offset manager.
>
>
> I haven't yet had time to check the access policies of the new VMA offset
> manager, but anything that is identical or stricter than the current vmwgfx
> verify_access() would be fine. If it's stricter however, we need to
> double-check backwards user-space compatibility.
My patches make vmw_dmabuf_alloc_ioctl() add the caller's open-file
(file*) to the list of allowed users of the new bo.
vmw_dmabuf_unref_ioctl() removes it again. I haven't seen any way to
pass a user-dmabuf to another user so there is currently at most one
user for a vmw_dmabuf. vmw_user_dmabuf_reference() looks like it is
intended exactly for this case so it would have to add the file* of
the caller to the list of allowed users. I will change that in v2.
This means every user who gets a handle for the buffer (like gem_open)
will be added to the allowed users. For TTM-object currently only a
single user is allowed.
So I replace vmw_user_bo->base.tfile with a list (actually rbtree) of
allowed files. So more than one user can have access. This, however,
breaks the "shareable" attribute which I wasn't aware of. As far as I
can see, "shareable" is only used by vmwgfx_surface.c and can be set
by userspace to allow arbitrary processes to map this buffer (sounds
like a security issue similar to gem flink).
I actually think we can replace the "shareable" attribute with proper
access-management in the vma-manager. But first I'd need to know
whether "shareable = true" is actually used by vmwgfx user-space and
how buffers are shared? Do you simply pass the mmap offset between
processes? Or do you pass some handle?
If you really pass mmap offsets in user-space and rely on this, I
guess there is no way I can make vmwgfx use the vma-manager access
management. I will have to find a way to work around it or move the
"shareable" flag to ttm_bo.
>
>>> We also need to make vmw_user_dmabuf_reference()
>>> correctly increase the vma-allow counter, but it is unused so remove it
>>> instead.
>
> IIRC this function or a derivative thereof is used heavily in an upcoming
> version driver, so if possible, please add a corrected version rather than
> remove the (currently) unused code. This will trigger a merge error and the
> upcoming code can be more easily corrected.
I will do so.
>
>>>
>>> Cc: Thomas Hellstrom
>>> Signed-off-by: David Herrmann
>>
>> Just as a hint, this patch would allow to remove the
>> "->access_verify()" callback in vmwgfx. No other driver uses it,
>> afaik. I will try to add this in v2.
>>
>> Regards
>> David
>>
>>> ---
>>> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 29
>>> +
>>> 1 file changed, 17 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>>> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>>> index 0e67cf4..4d3f0ae 100644
>>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>>> @@ -499,6 +499,12 @@ int vmw_dmabuf_alloc_ioctl(struct drm_device *dev,
>>> void *data,
>>> if (unlikely(ret != 0))
>>> goto out_no_dmabuf;
>>>
>>> + ret = drm_vma_node_allow(&dma_buf->base.vma_node,
>>> file_priv->filp);
>>> + if (ret) {
>>> + vmw_dmabuf_unreference(&dma_buf);
>>> + goto out_no_dmabuf;
>>> + }
>>> +
>>> rep->handle = handle;
>>> rep->map_handle =
>>> drm_vma_node_offset_addr(&dma_buf->base.vma_node);
>>> rep->cur_gmr_id = handle;
>>> @@ -517,7 +523,18 @@ int vmw_dmabuf_unref_ioctl(struct drm_device *dev,
>>> void *data,
>>> {
>>> struct drm_vmw_unref_dmabuf_arg *arg =
>>> (struct drm_vmw_unref_dmabuf_arg *)data;
>>> + struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
>>> + struct vmw_dma_buffer *dma_buf;
>>> + int ret;
>>> +
>>> + ret = vmw_user_dmabuf_lookup(tfile, arg->handle, &dma_buf);
>>> + if (ret)
>>> + return -EINVAL;
>>>
>>> + drm_vma_node_revoke(&dma_buf->base.vma_node, file_priv->filp);
>>> + vmw_dmabuf_unreference(&dma_buf);
>>> +
>>> + /* FIXME: is this equivalent to vmw_dmabuf_unreference(dma_buf)?
>>> */
>
>
> No. A ttm ref object is rather similar to a generic GEM object, only that
> it's generic in the sense that it is not restricted to buffers, and can make
> any desired object visible to user-space. So translated the below code
> removes a reference that the arg->handle holds on the "gem" object,
> potentially destroying the whole object in which the "gem" object is
> embedded.
So I actually need both lookups, vmw_us
[Bug 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 --- Comment #2 from n...@detonation.org --- (In reply to comment #1) > It's not the firmware per se. It's probably the new dpm code. Do you still > get when dpm is disabled? Indeed. If I turn off dpm, I can suspend successfully and more or less successfully resume. But a few seconds after resume my X server dies. May be related or not. Attaching a dmesg taken after that. It's strange though that with an older kernel I still get hangs on suspend and resume even though they do not support dpm at all. So how can I proceed? -- 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 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 --- Comment #3 from n...@detonation.org --- Created attachment 84144 --> https://bugs.freedesktop.org/attachment.cgi?id=84144&action=edit dmesg after X server crash after suspend/resume without dpm -- 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 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 --- Comment #4 from Alex Deucher --- Sounds like this may be a problem independent of dpm. Have you ever had successful suspend and resume? When you say X crash, do you you mean X hangs? system hangs? segfault? -- 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 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760
https://bugzilla.kernel.org/show_bug.cgi?id=60687 --- Comment #13 from Gabor Hasenfrasz --- @Rafał: I've tested the patch and solves the problem in my case. Thank you! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 --- Comment #5 from n...@detonation.org --- (In reply to comment #4) > Sounds like this may be a problem independent of dpm. Have you ever had > successful suspend and resume? I've always (meaning > 5 years) had successful suspend and resume on this machine. Until I updated the firmware files to test UVD and then dpm. With the original firmware contained in openSUSE's kernel-firmware-20130114git-1.2.1 package, suspend/resume works just fine. I started having problems immediately after updating the radeon firmware files from your FTP site. In the meantime, openSUSE shipped an update to the kernel-firmware package with which I see the same problems. > When you say X crash, do you you mean X > hangs? system hangs? segfault? I mean the X server terminated unexpectedly and I got thrown back to the login screen. Other than this message and the part about GPU lockup in the dmesg dump I posted, I could not find any messages. -- 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
Re: [PATCH 08/16] drm/vmwgfx: implement mmap access managament
On 08/16/2013 03:19 PM, David Herrmann wrote:
Hi
On Wed, Aug 14, 2013 at 7:35 PM, Thomas Hellstrom wrote:
(CC'ing the proper people since I'm still on parental leave).
On 08/13/2013 11:44 PM, David Herrmann wrote:
Please see inline comments.
Hi
On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann
wrote:
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.
I haven't yet had time to check the access policies of the new VMA offset
manager, but anything that is identical or stricter than the current vmwgfx
verify_access() would be fine. If it's stricter however, we need to
double-check backwards user-space compatibility.
My patches make vmw_dmabuf_alloc_ioctl() add the caller's open-file
(file*) to the list of allowed users of the new bo.
vmw_dmabuf_unref_ioctl() removes it again. I haven't seen any way to
pass a user-dmabuf to another user so there is currently at most one
user for a vmw_dmabuf. vmw_user_dmabuf_reference() looks like it is
intended exactly for this case so it would have to add the file* of
the caller to the list of allowed users. I will change that in v2.
This means every user who gets a handle for the buffer (like gem_open)
will be added to the allowed users. For TTM-object currently only a
single user is allowed.
So I replace vmw_user_bo->base.tfile with a list (actually rbtree) of
allowed files. So more than one user can have access. This, however,
breaks the "shareable" attribute which I wasn't aware of. As far as I
can see, "shareable" is only used by vmwgfx_surface.c and can be set
by userspace to allow arbitrary processes to map this buffer (sounds
like a security issue similar to gem flink).
I actually think we can replace the "shareable" attribute with proper
access-management in the vma-manager. But first I'd need to know
whether "shareable = true" is actually used by vmwgfx user-space and
how buffers are shared? Do you simply pass the mmap offset between
processes? Or do you pass some handle?
Buffer- and surface sharing is done by passing an opaque (not mmap) handle.
A process intending to map the shared buffer must obtain the map offset
through a
vmw_user_dmabuf_reference() call, and that only works if the buffer is
"shareable".
mmap offsets are never passed between processes, but valid only if
obtained directly
from the kernel driver.
This means that currently buffer mapping should have the same access
restriction as the
X server imposes on DRI clients; If a process is allowed to open the drm
device, it also has
map access to all "shareable" objects, which is a security hole in the
sense that verify_access() should
really check that the caller, if not the buffer owner, is also
authenticated.
The reason verify_access() is there is to make the TTM buffer object
transparent to how it is exported
to user space (GEM or TTM objects). Apparently the GEM TTM drivers have
ignored this hook for some unknown
reason.
Some ideas:
1) Rather than having a list of allowable files on each buffer object,
perhaps we should have a user and a group and
a set of permissions (for user, group and system) more like how files
are handled?
2) Rather than imposing a security policy in the vma manager, could we
perhaps have a set a utility functions that
are called through verify_access(). Each driver could then have a
wrapper to gather the needed information and
hand it over to the VMA manager?
If you really pass mmap offsets in user-space and rely on this, I
guess there is no way I can make vmwgfx use the vma-manager access
management. I will have to find a way to work around it or move the
"shareable" flag to ttm_bo.
We also need to make vmw_user_dmabuf_reference()
correctly increase the vma-allow counter, but it is unused so remove it
instead.
IIRC this function or a derivative thereof is used heavily in an upcoming
version driver, so if possible, please add a corrected version rather than
remove the (currently) unused code. This will trigger a merge error and the
upcoming code can be more easily corrected.
I will do so.
Cc: Thomas Hellstrom
Signed-off-by: David Herrmann
Just as a hint, this patch would allow to remove the
"->access_verify()" callback in vmwgfx. No other driver uses it,
afaik. I will try to add this in v2.
Regards
David
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 29
+
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 0e67cf4..4d3f0ae 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -499,6 +499,12 @@ int vmw_dmabuf_alloc_ioctl(struct drm_device *dev,
void *data,
if (unlikely(ret != 0))
goto out_no_dmabuf;
+ ret = drm_vma_node_allow(&dma_buf->base.vma_node,
file_priv->filp);
+ if (ret) {
+ vmw_dmabuf_unreference(&dma_buf);
+ goto out_no_d
Re: [PATCH 08/16] drm/vmwgfx: implement mmap access managament
Hi On Fri, Aug 16, 2013 at 5:33 PM, Thomas Hellstrom wrote: > On 08/16/2013 03:19 PM, David Herrmann wrote: >> >> Hi >> >> On Wed, Aug 14, 2013 at 7:35 PM, Thomas Hellstrom >> wrote: >>> >>> (CC'ing the proper people since I'm still on parental leave). >>> >>> On 08/13/2013 11:44 PM, David Herrmann wrote: >>> >>> Please see inline comments. >>> >>> Hi On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann wrote: > > Correctly allow and revoke buffer access on each open/close via the new > VMA offset manager. >>> >>> >>> I haven't yet had time to check the access policies of the new VMA offset >>> manager, but anything that is identical or stricter than the current >>> vmwgfx >>> verify_access() would be fine. If it's stricter however, we need to >>> double-check backwards user-space compatibility. >> >> My patches make vmw_dmabuf_alloc_ioctl() add the caller's open-file >> (file*) to the list of allowed users of the new bo. >> vmw_dmabuf_unref_ioctl() removes it again. I haven't seen any way to >> pass a user-dmabuf to another user so there is currently at most one >> user for a vmw_dmabuf. vmw_user_dmabuf_reference() looks like it is >> intended exactly for this case so it would have to add the file* of >> the caller to the list of allowed users. I will change that in v2. >> This means every user who gets a handle for the buffer (like gem_open) >> will be added to the allowed users. For TTM-object currently only a >> single user is allowed. >> >> So I replace vmw_user_bo->base.tfile with a list (actually rbtree) of >> allowed files. So more than one user can have access. This, however, >> breaks the "shareable" attribute which I wasn't aware of. As far as I >> can see, "shareable" is only used by vmwgfx_surface.c and can be set >> by userspace to allow arbitrary processes to map this buffer (sounds >> like a security issue similar to gem flink). >> I actually think we can replace the "shareable" attribute with proper >> access-management in the vma-manager. But first I'd need to know >> whether "shareable = true" is actually used by vmwgfx user-space and >> how buffers are shared? Do you simply pass the mmap offset between >> processes? Or do you pass some handle? > > > Buffer- and surface sharing is done by passing an opaque (not mmap) handle. > A process intending to map the shared buffer must obtain the map offset > through a > vmw_user_dmabuf_reference() call, and that only works if the buffer is > "shareable". Ugh? That's not true. At least in upstream vmwgfx vmw_user_dmabuf_reference() is unused. Maybe you have access to some newer codebase? Anyway, I can easily make this function call drm_vma_node_allow() and then newer vmwgfx additions will work just fine. This means, every user who calls vmw_user_dmabuf_reference() will then also be allowed to mmap that buffer. But users who do not own a handle (that is, they didn't call vmw_user_dmabuf_reference() or they dropped the reference via vmw_user_dmabuf_unref_ioctl()) will get -EACCES if they try to mmap the buffer. This is an extension to how it currently works, so I doubt that it breaks any user-space. Is that fine for vmwgfx? > mmap offsets are never passed between processes, but valid only if obtained > directly > from the kernel driver. Good to hear. That means this patch doesn't break any existing userspace. > This means that currently buffer mapping should have the same access > restriction as the > X server imposes on DRI clients; If a process is allowed to open the drm > device, it also has > map access to all "shareable" objects, which is a security hole in the sense > that verify_access() should > really check that the caller, if not the buffer owner, is also > authenticated. I actually don't care for DRI. This series tries to fix exactly that. I don't want that. Users with DRM access shouldn't be able to map arbitrary buffers. Instead, users should only be able to map buffers that they own a handle for. Access management for handles is an orthogonal problem that this series does not change. dma-buf does a pretty good job there, anyway. > The reason verify_access() is there is to make the TTM buffer object > transparent to how it is exported > to user space (GEM or TTM objects). Apparently the GEM TTM drivers have > ignored this hook for some unknown > reason. I don't think that we need any extended access-management here. Why would we ever need different access-modes for mmap than for handles? This series reduces mmap() access-management to handle-access-management. That is, the right to mmap() a buffer is now bound to a buffer handle. If you don't own a handle, you cannot mmap the buffer. But if you own a handle, you're always allowed to mmap the buffer. I think this should be the policy to go for, or am I missing something? That's also why I think verify_access() is not needed at all. Drivers shouldn't care for mmap() access, instead they should take care only privileged users get handles (whatever th
[Bug 67876] linux v3.11.0-rc1 many drm:radeon_ttm_backend_bind ERROR failed to bind 2025 pages issued during boot
https://bugs.freedesktop.org/show_bug.cgi?id=67876 Alexandre Demers changed: What|Removed |Added Summary|linux v4.11-rc1 many|linux v3.11.0-rc1 many |drm:radeon_ttm_backend_bind |drm:radeon_ttm_backend_bind |ERROR failed to bind 2025 |ERROR failed to bind 2025 |pages issued during boot|pages issued during boot -- 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 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 Alexandre Demers changed: What|Removed |Added Summary|r600: linux 3.11RC isn't|r600: linux v3.11.0-RC |booting with radeon.dpm=1 |isn't booting with |option in grub |radeon.dpm=1 option in grub -- 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
Re: [PATCH 08/16] drm/vmwgfx: implement mmap access managament
On 08/16/2013 07:01 PM, David Herrmann wrote: Hi On Fri, Aug 16, 2013 at 5:33 PM, Thomas Hellstrom wrote: On 08/16/2013 03:19 PM, David Herrmann wrote: Hi On Wed, Aug 14, 2013 at 7:35 PM, Thomas Hellstrom wrote: (CC'ing the proper people since I'm still on parental leave). On 08/13/2013 11:44 PM, David Herrmann wrote: Please see inline comments. Hi On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann wrote: Correctly allow and revoke buffer access on each open/close via the new VMA offset manager. I haven't yet had time to check the access policies of the new VMA offset manager, but anything that is identical or stricter than the current vmwgfx verify_access() would be fine. If it's stricter however, we need to double-check backwards user-space compatibility. My patches make vmw_dmabuf_alloc_ioctl() add the caller's open-file (file*) to the list of allowed users of the new bo. vmw_dmabuf_unref_ioctl() removes it again. I haven't seen any way to pass a user-dmabuf to another user so there is currently at most one user for a vmw_dmabuf. vmw_user_dmabuf_reference() looks like it is intended exactly for this case so it would have to add the file* of the caller to the list of allowed users. I will change that in v2. This means every user who gets a handle for the buffer (like gem_open) will be added to the allowed users. For TTM-object currently only a single user is allowed. So I replace vmw_user_bo->base.tfile with a list (actually rbtree) of allowed files. So more than one user can have access. This, however, breaks the "shareable" attribute which I wasn't aware of. As far as I can see, "shareable" is only used by vmwgfx_surface.c and can be set by userspace to allow arbitrary processes to map this buffer (sounds like a security issue similar to gem flink). I actually think we can replace the "shareable" attribute with proper access-management in the vma-manager. But first I'd need to know whether "shareable = true" is actually used by vmwgfx user-space and how buffers are shared? Do you simply pass the mmap offset between processes? Or do you pass some handle? Buffer- and surface sharing is done by passing an opaque (not mmap) handle. A process intending to map the shared buffer must obtain the map offset through a vmw_user_dmabuf_reference() call, and that only works if the buffer is "shareable". Ugh? That's not true. At least in upstream vmwgfx vmw_user_dmabuf_reference() is unused. Maybe you have access to some newer codebase? Yes, this is how TTM buffer management used to work in older TTM drivers and how the codebase for newer device versions will work. Anyway, I can easily make this function call drm_vma_node_allow() and then newer vmwgfx additions will work just fine. This means, every user who calls vmw_user_dmabuf_reference() will then also be allowed to mmap that buffer. But users who do not own a handle (that is, they didn't call vmw_user_dmabuf_reference() or they dropped the reference via vmw_user_dmabuf_unref_ioctl()) will get -EACCES if they try to mmap the buffer. This is an extension to how it currently works, so I doubt that it breaks any user-space. Is that fine for vmwgfx? Yes, that sounds fine. mmap offsets are never passed between processes, but valid only if obtained directly from the kernel driver. Good to hear. That means this patch doesn't break any existing userspace. This means that currently buffer mapping should have the same access restriction as the X server imposes on DRI clients; If a process is allowed to open the drm device, it also has map access to all "shareable" objects, which is a security hole in the sense that verify_access() should really check that the caller, if not the buffer owner, is also authenticated. I actually don't care for DRI. This series tries to fix exactly that. I don't want that. Users with DRM access shouldn't be able to map arbitrary buffers. Instead, users should only be able to map buffers that they own a handle for. Access management for handles is an orthogonal problem that this series does not change. dma-buf does a pretty good job there, anyway. Understood. The reason verify_access() is there is to make the TTM buffer object transparent to how it is exported to user space (GEM or TTM objects). Apparently the GEM TTM drivers have ignored this hook for some unknown reason. I don't think that we need any extended access-management here. Why would we ever need different access-modes for mmap than for handles? This series reduces mmap() access-management to handle-access-management. That is, the right to mmap() a buffer is now bound to a buffer handle. If you don't own a handle, you cannot mmap the buffer. But if you own a handle, you're always allowed to mmap the buffer. I think this should be the policy to go for, or am I missing something? That's also why I think verify_access() is not needed at all. Drivers shouldn't care for mmap() access, instead they should take care only privileged users get ha
Re: [PATCH] intel: Update i915_drm.h and correct misspelled caching
On 08/14/2013 01:19 AM, Sedat Dilek wrote:
AFAICS, there are more updates needed to be in sync with recent kernel-drm.
I fell over the misspelling when digging into an issue in Linux-next.
The spelling should be consistent in kernel-drm, libdrm, intel-ddx, etc.
Here, I had a look especially at the defined macros (defines).
Signed-off-by: Sedat Dilek
This should get Chris's ok before committing, but
Reviewed-by: Ian Romanick
---
include/drm/i915_drm.h | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index aa983f3..61a8407 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -195,8 +195,8 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_WAIT 0x2c
#define DRM_I915_GEM_CONTEXT_CREATE 0x2d
#define DRM_I915_GEM_CONTEXT_DESTROY 0x2e
-#define DRM_I915_GEM_SET_CACHEING 0x2f
-#define DRM_I915_GEM_GET_CACHEING 0x30
+#define DRM_I915_GEM_SET_CACHING 0x2f
+#define DRM_I915_GEM_GET_CACHING 0x30
#define DRM_I915_REG_READ 0x31
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t)
@@ -222,8 +222,8 @@ typedef struct _drm_i915_sarea {
#define DRM_IOCTL_I915_GEM_PINDRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
#define DRM_IOCTL_I915_GEM_UNPIN DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
#define DRM_IOCTL_I915_GEM_BUSY DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
-#define DRM_IOCTL_I915_GEM_SET_CACHEING
DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHEING, struct
drm_i915_gem_cacheing)
-#define DRM_IOCTL_I915_GEM_GET_CACHEING
DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHEING, struct
drm_i915_gem_cacheing)
+#define DRM_IOCTL_I915_GEM_SET_CACHING DRM_IOW(DRM_COMMAND_BASE +
DRM_I915_GEM_SET_CACHING, struct drm_i915_gem_caching)
+#define DRM_IOCTL_I915_GEM_GET_CACHING DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_GET_CACHING, struct drm_i915_gem_caching)
#define DRM_IOCTL_I915_GEM_THROTTLE DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_GEM_THROTTLE)
#define DRM_IOCTL_I915_GEM_ENTERVTDRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_ENTERVT)
#define DRM_IOCTL_I915_GEM_LEAVEVTDRM_IO(DRM_COMMAND_BASE +
DRM_I915_GEM_LEAVEVT)
@@ -706,21 +706,22 @@ struct drm_i915_gem_busy {
__u32 busy;
};
-#define I915_CACHEING_NONE 0
-#define I915_CACHEING_CACHED 1
+#define I915_CACHING_NONE 0
+#define I915_CACHING_CACHED1
+#define I915_CACHING_DISPLAY 2
-struct drm_i915_gem_cacheing {
+struct drm_i915_gem_caching {
/**
-* Handle of the buffer to set/get the cacheing level of. */
+* Handle of the buffer to set/get the caching level of. */
__u32 handle;
/**
* Cacheing level to apply or return value
*
-* bits0-15 are for generic cacheing control (i.e. the above defined
+* bits0-15 are for generic caching control (i.e. the above defined
* values). bits16-31 are reserved for platform-specific variations
* (e.g. l3$ caching on gen7). */
- __u32 cacheing;
+ __u32 caching;
};
#define I915_TILING_NONE 0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute
From: Tom Stellard
Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.
Signed-off-by: Tom Stellard
---
drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
drivers/gpu/drm/radeon/radeon_kms.c | 3 +
drivers/gpu/drm/radeon/si.c | 106 +---
include/uapi/drm/radeon_drm.h | 2 +
4 files changed, 68 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 29876b1..c2c6da1 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -75,9 +75,10 @@
* 2.32.0 - new info request for rings working
* 2.33.0 - Add SI tiling mode array query
* 2.34.0 - Add CIK tiling mode array query
+ * 2.35.0 - Add SI CP DMA compute query
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 34
+#define KMS_DRIVER_MINOR 35
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 49ff3d1..cc2ca38 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -433,6 +433,9 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return -EINVAL;
}
break;
+ case RADEON_INFO_SI_CP_DMA_COMPUTE:
+ *value = 1;
+ break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index daa8d2d..8a21132 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4083,13 +4083,64 @@ static int si_vm_packet3_ce_check(struct radeon_device
*rdev,
return 0;
}
+static int si_vm_packet3_cp_dma_check(u32 *ib, u32 idx)
+{
+ u32 start_reg, reg, i;
+ u32 command = ib[idx + 4];
+ u32 info = ib[idx + 1];
+ u32 idx_value = ib[idx];
+ if (command & PACKET3_CP_DMA_CMD_SAS) {
+ /* src address space is register */
+ if (((info & 0x6000) >> 29) == 0) {
+ start_reg = idx_value << 2;
+ if (command & PACKET3_CP_DMA_CMD_SAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad SRC register\n");
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i < (command & 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad SRC
register\n");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ if (command & PACKET3_CP_DMA_CMD_DAS) {
+ /* dst address space is register */
+ if (((info & 0x0030) >> 20) == 0) {
+ start_reg = ib[idx + 2];
+ if (command & PACKET3_CP_DMA_CMD_DAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad DST register\n");
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i < (command & 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad DST
register\n");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ return 0;
+}
+
static int si_vm_packet3_gfx_check(struct radeon_device *rdev,
u32 *ib, struct radeon_cs_packet *pkt)
{
+ int r;
u32 idx = pkt->idx + 1;
u32 idx_value = ib[idx];
u32 start_reg, end_reg, reg, i;
- u32 command, info;
switch (pkt->opcode) {
case PACKET3_NOP:
@@ -4190,50 +4241,9 @@ static int si_vm_packet3_gfx_check(struct radeon_device
*rdev,
}
break;
case PACKET3_CP_DMA:
- command = ib[idx + 4];
- info = ib[idx + 1];
- if (command & PACKET3_CP_DMA_CMD_SAS) {
-
Re: [PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute
On Fri, Aug 16, 2013 at 3:16 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> Also add a new RADEON_INFO query to check that CP DMA packets are
> supported on the compute ring.
>
> Signed-off-by: Tom Stellard
> ---
> drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
> drivers/gpu/drm/radeon/radeon_kms.c | 3 +
> drivers/gpu/drm/radeon/si.c | 106
> +---
> include/uapi/drm/radeon_drm.h | 2 +
> 4 files changed, 68 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 29876b1..c2c6da1 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -75,9 +75,10 @@
> * 2.32.0 - new info request for rings working
> * 2.33.0 - Add SI tiling mode array query
> * 2.34.0 - Add CIK tiling mode array query
> + * 2.35.0 - Add SI CP DMA compute query
> */
> #define KMS_DRIVER_MAJOR 2
> -#define KMS_DRIVER_MINOR 34
> +#define KMS_DRIVER_MINOR 35
Skip the version bump if we want this to go to stable kernels. We can
query the info ioctl for the cp_dma_compute arg and if it's a kernel
where it doesn't exist, it'll just fail. if it exists the ioctl will
succeed. If we don't want to send this to stable, just bump the
version and skip the info ioctl.
Alex
> #define KMS_DRIVER_PATCHLEVEL 0
> int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
> int radeon_driver_unload_kms(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 49ff3d1..cc2ca38 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -433,6 +433,9 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
> struct drm_file *filp)
> return -EINVAL;
> }
> break;
> + case RADEON_INFO_SI_CP_DMA_COMPUTE:
> + *value = 1;
> + break;
> default:
> DRM_DEBUG_KMS("Invalid request %d\n", info->request);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index daa8d2d..8a21132 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -4083,13 +4083,64 @@ static int si_vm_packet3_ce_check(struct
> radeon_device *rdev,
> return 0;
> }
>
> +static int si_vm_packet3_cp_dma_check(u32 *ib, u32 idx)
> +{
> + u32 start_reg, reg, i;
> + u32 command = ib[idx + 4];
> + u32 info = ib[idx + 1];
> + u32 idx_value = ib[idx];
> + if (command & PACKET3_CP_DMA_CMD_SAS) {
> + /* src address space is register */
> + if (((info & 0x6000) >> 29) == 0) {
> + start_reg = idx_value << 2;
> + if (command & PACKET3_CP_DMA_CMD_SAIC) {
> + reg = start_reg;
> + if (!si_vm_reg_valid(reg)) {
> + DRM_ERROR("CP DMA Bad SRC
> register\n");
> + return -EINVAL;
> + }
> + } else {
> + for (i = 0; i < (command & 0x1f); i++) {
> + reg = start_reg + (4 * i);
> + if (!si_vm_reg_valid(reg)) {
> + DRM_ERROR("CP DMA Bad SRC
> register\n");
> + return -EINVAL;
> + }
> + }
> + }
> + }
> + }
> + if (command & PACKET3_CP_DMA_CMD_DAS) {
> + /* dst address space is register */
> + if (((info & 0x0030) >> 20) == 0) {
> + start_reg = ib[idx + 2];
> + if (command & PACKET3_CP_DMA_CMD_DAIC) {
> + reg = start_reg;
> + if (!si_vm_reg_valid(reg)) {
> + DRM_ERROR("CP DMA Bad DST
> register\n");
> + return -EINVAL;
> + }
> + } else {
> + for (i = 0; i < (command & 0x1f); i++) {
> + reg = start_reg + (4 * i);
> + if (!si_vm_reg_valid(reg)) {
> + DRM_ERROR("CP DMA Bad DST
> register\n");
> + return -EINVAL;
> + }
> + }
> + }
> + }
> + }
> + return 0;
> +}
> +
> static int si_vm_packet3_gfx_check(struct radeon_device *rdev
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #10 from Bernhard Held --- My mileage varies with 3.11-rc5. In rare case suspend/resume works. Most of the time suspend shows: [ 34.926841] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 35.075229] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 45.908028] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 45.908031] radeon :01:00.0: GPU lockup (waiting for 0x0004 last fence id 0x0002) [ 45.908033] [drm:r600_uvd_ib_test] *ERROR* radeon: fence wait failed (-35). [ 45.908037] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35). During resume the PC either freezes after "PM: Read x kbytes in y.yy seconds" or dmesg shows: [4.879714] Freezing user space processes ... (elapsed 0.000 seconds) done. [5.190862] PM: Using 3 thread(s) for decompression. [5.190862] PM: Loading and decompressing image data (99920 pages)... [5.466130] PM: Image loading progress: 0% [5.774497] PM: Image loading progress: 10% [5.868650] PM: Image loading progress: 20% [5.951424] PM: Image loading progress: 30% [6.044454] PM: Image loading progress: 40% [6.158650] PM: Image loading progress: 50% [6.249908] PM: Image loading progress: 60% [6.336868] PM: Image loading progress: 70% [6.421403] PM: Image loading progress: 80% [6.508071] PM: Image loading progress: 90% [6.592575] PM: Image loading done. [6.596124] PM: Read 399680 kbytes in 1.39 seconds (287.53 MB/s) [ 35.608037] usb usb1: root hub lost power or was reset [ 35.608038] usb usb2: root hub lost power or was reset [ 35.948432] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 8801a5f8e880 [ 45.992029] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 45.992032] radeon :01:00.0: GPU lockup (waiting for 0x0004 last fence id 0x0002) [ 45.992034] [drm:r600_uvd_ib_test] *ERROR* radeon: fence wait failed (-35). [ 45.992037] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35). [ 46.548477] Restarting tasks ... done. After this I can use the console and KDM is running, but X crashes at logon. Without CYPRESS_uvd.bin suspend/resume works reliable. CEDAR_me.bin, CEDAR_pfp.bin, CEDAR_rlc.bin, CEDAR_smc.bin and CYPRESS_uvd.bin are from git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git I'm using a 2560x1440 console with Dual-DVI. -- 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 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #11 from Bernhard Held --- Created attachment 84155 --> https://bugs.freedesktop.org/attachment.cgi?id=84155&action=edit full dmesg of suspend/resume cycle -- 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 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #12 from Bernhard Held --- Created attachment 84156 --> https://bugs.freedesktop.org/attachment.cgi?id=84156&action=edit lspci -- 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 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #13 from Bernhard Held --- Created attachment 84157 --> https://bugs.freedesktop.org/attachment.cgi?id=84157&action=edit .config for 3.11-rc5 -- 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
[PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute v2
From: Tom Stellard
Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.
v2:
- Don't bump kms version, so this patch can be backported to stable
kernels.
Cc: sta...@vger.kernel.org
Signed-off-by: Tom Stellard
---
drivers/gpu/drm/radeon/radeon_kms.c | 3 +
drivers/gpu/drm/radeon/si.c | 106 +---
include/uapi/drm/radeon_drm.h | 2 +
3 files changed, 66 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 49ff3d1..cc2ca38 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -433,6 +433,9 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return -EINVAL;
}
break;
+ case RADEON_INFO_SI_CP_DMA_COMPUTE:
+ *value = 1;
+ break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index daa8d2d..8a21132 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4083,13 +4083,64 @@ static int si_vm_packet3_ce_check(struct radeon_device
*rdev,
return 0;
}
+static int si_vm_packet3_cp_dma_check(u32 *ib, u32 idx)
+{
+ u32 start_reg, reg, i;
+ u32 command = ib[idx + 4];
+ u32 info = ib[idx + 1];
+ u32 idx_value = ib[idx];
+ if (command & PACKET3_CP_DMA_CMD_SAS) {
+ /* src address space is register */
+ if (((info & 0x6000) >> 29) == 0) {
+ start_reg = idx_value << 2;
+ if (command & PACKET3_CP_DMA_CMD_SAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad SRC register\n");
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i < (command & 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad SRC
register\n");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ if (command & PACKET3_CP_DMA_CMD_DAS) {
+ /* dst address space is register */
+ if (((info & 0x0030) >> 20) == 0) {
+ start_reg = ib[idx + 2];
+ if (command & PACKET3_CP_DMA_CMD_DAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad DST register\n");
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i < (command & 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad DST
register\n");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ return 0;
+}
+
static int si_vm_packet3_gfx_check(struct radeon_device *rdev,
u32 *ib, struct radeon_cs_packet *pkt)
{
+ int r;
u32 idx = pkt->idx + 1;
u32 idx_value = ib[idx];
u32 start_reg, end_reg, reg, i;
- u32 command, info;
switch (pkt->opcode) {
case PACKET3_NOP:
@@ -4190,50 +4241,9 @@ static int si_vm_packet3_gfx_check(struct radeon_device
*rdev,
}
break;
case PACKET3_CP_DMA:
- command = ib[idx + 4];
- info = ib[idx + 1];
- if (command & PACKET3_CP_DMA_CMD_SAS) {
- /* src address space is register */
- if (((info & 0x6000) >> 29) == 0) {
- start_reg = idx_value << 2;
- if (command & PACKET3_CP_DMA_CMD_SAIC) {
- reg = start_reg;
- if (!si_vm_reg_valid(reg)) {
- DRM_ERROR("CP DMA Bad SRC
register\n");
- return -EINVAL;
- }
- } else {
-
[Bug 67981] Graphical Glitches with RV200 on IBM Thinkpad T40
https://bugs.freedesktop.org/show_bug.cgi?id=67981 --- Comment #11 from Stefan Schmidt --- Okay, I played a little around with window managers. Mutter also has graphical glitches (a little different ones though), Compiz doesn't work at all, Xfce and Fluxbox work and If I replace elementary's window manager gala with xfwm4 then as far as I can see the severe glitches disappear with only minor glitches remaining. -- 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
Re: [PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute v2
On Fri, Aug 16, 2013 at 03:34:09PM -0700, Greg KH wrote: > On Fri, Aug 16, 2013 at 05:47:39PM -0400, Tom Stellard wrote: > > From: Tom Stellard > > > > Also add a new RADEON_INFO query to check that CP DMA packets are > > supported on the compute ring. > > > > v2: > > - Don't bump kms version, so this patch can be backported to stable > > kernels. > > Why is this for a stable kernel? What reported problem does it fix? > CP DMA has been supported since the 3.8 kernel, but due to an oversight we forgot to teach the CS checker that the CP DMA packet was legal for the compute ring on Southern Islands GPUs. This patch fixes a bug where the radeon driver will incorrectly reject a legal CP DMA packet from user space. I would like to have the patch backported to stable so that we don't have to require Mesa users to use a bleeding edge kernel in order to take advantage of this feature which is already present in the stable kernels (3.8 and newer). -Tom ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gma500: Fix SDVO turning off randomly
On Sun, Aug 11, 2013 at 12:00 PM, Daniel Vetter wrote: > On Sat, Aug 10, 2013 at 10:12 PM, Patrik Jakobsson > wrote: >> I will give this a spin on my gma500 and i915 hardware on monday. The gma500 >> sdvo code should be pretty much identical to i915 from around 2011 but I >> guess >> we've diverged since then. I'll also rework sdvo for gma500 a little in the >> coming days when I start working on Minnowboard support so I'll probably >> compare >> it to i915 for any peculiarities. Monday turned into friday, but it seems ok on my Poulsbo boxes. I'll apply it to gma500-fixes > > If you take this opportunity to share a bit of code between gma500 and > i915 (the sdvo #defines header and maybe the sdvo i2c read/write and > cmd helpers) I'd be interested in such a patch. We probably need an > struct intel_sdvo_chip to abstract away a few things. > -Daniel I'll take a look at it. Does i915 also have GMBUS and GPIOs spread out on different devices like the minnow? GPIOs seem to be accessed through LPC. -Patrik
[Bug 65254] opengl flicker in xbmc / glxgears
https://bugs.freedesktop.org/show_bug.cgi?id=65254 --- Comment #16 from Vladi --- nope, tried that and R600_DEBUG=sb as well I also just tried latest patches from http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.11 with no luck -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/e7ae5bbc/attachment.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #41 from Erdem U. Alt?nyurt --- I think those patches are merged with llvm-trunk. Manually installation give me hunks and fails. I update/build/install llvm-trunk,ibclc-trunk mesa-trunk and now I still got lock ups!??? ( Using 3.11.rc5 with disabled dpm ) --- If you have clean patches, I can test them also. Because this patches gives me /temp/llvm/lib/Target/R600/SIInstrInfo.td:39:1: error: def 'SIload_constant' already defined error at compile time... Thanks -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/453ebff9/attachment.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #42 from Aaron Watry --- (In reply to comment #41) > I think those patches are merged with llvm-trunk. Manually installation give > me hunks and fails. The second LLVM series is not yet merged upstream, but the first one is. I was able to use a clean LLVM/Clang checkout from today with the second series on my Cedar-based machine. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/9c5f803f/attachment.html>
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #43 from Erdem U. Alt?nyurt --- I patched llvm with http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130812/184089.html using patch -N -p1 -i p2.patch But still got lock-ups. Any hints? :/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/0f80c463/attachment.html>
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 Ond?ej Svoboda changed: What|Removed |Added CC||ondrej at svobodasoft.cz --- Comment #11 from Ond?ej Svoboda --- Thank you guys for solving this one out! I can confirm the patch works; I applied it to an almost vanilla Arch kernel (package linux 3.10.7-1) and the driver now works with my HD 4770 beautifully, Gtk applications are drawn correctly. -- You are receiving this mail because: You are watching the assignee of the bug.
Moving a bug upstream per downstream request, emailing the maintainers
On Thu, Aug 15, 2013 at 03:28:53PM -0400, John Hupp wrote: > [1.] One line summary of the problem: > Flash 11.2 content displays in shades of green and purple only, and > in a horizontally compressed space > > [2.] Full description of the problem/report: > The full downstream bug report is at > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1212455 , but > my description from there: > > In my testing with the Intel driver using its default acceleration: > - Flash 11.2 works on Quantal with the 3.5 kernel > - Flash 11.2 works on Raring with the 3.5.0-17 kernel (though it > boots to a low-res desktop with a frozen pointer) > - Flash 11.2 works on Raring also with the 3.6.11-030611 or > 3.7.10-030710 mainline kernels > - Flash 11.8 works on Raring with the 3.8 kernel (in Chrome) > - Flash 11.2 fails on Raring with the 3.8 kernel > - Flash 11.2 fails on Raring with the latest mainline kernel, > 3.11.0-031100rc5 > - Flash 11.2 fails on Saucy alpha 2 with its default kernel It's a flash bug. They ignore the format of the Window that they PutImage to. (Worse, they create an image of the right depth or else X would reject the PutImage with a BadMatch and then render incorrect pixel data into it.) -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 68178] New: evergreen: hard lockup on suspend and resume with current firmware
https://bugs.freedesktop.org/show_bug.cgi?id=68178 Priority: medium Bug ID: 68178 Assignee: dri-devel at lists.freedesktop.org Summary: evergreen: hard lockup on suspend and resume with current firmware Severity: major Classification: Unclassified OS: Linux (All) Reporter: nine at detonation.org Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 84133 --> https://bugs.freedesktop.org/attachment.cgi?id=84133&action=edit dmesg of my system for information As soon as the up to date firmware package is installed, my system hangs on suspend and again on resume with the screen turned off and the system not reacting to anything. Tested it on various kernels with the earliest being 3.7.10 (current openSUSE kernel) and the latest being 3.11-rc5. I tried to get more information, but there are no logs, the screen is turned off and even netconsole did not show more. Do you have suggestions about how to debug this or things that I can try to narrow it down? My GPU is a: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Redwood [Radeon HD 5670] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e151 Flags: bus master, fast devsel, latency 0, IRQ 48 Memory at e000 (64-bit, prefetchable) [size=256M] Memory at f442 (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at f440 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon Attaching dmesg of a running system just for info. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/de7469a2/attachment.html>
[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #68 from Tomasz P. --- Maybe post this to mesa-dev mailing list.I doubt that they have time to read this. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/efd930af/attachment-0001.html>
[PATCH] drm: Eliminate dev->vmalist
The primary purpose of this list is for pretty printing the maps through
debugfs/vma - per process information can be found in /proc/*/map et al.
However, the list manipulation eats processor cycles resulting in a near
indefinite (I got bored) stall for a leaky i-g-t/gem_concurrent_blit.
There is one true user of the vmalist though. drm_vm_shm_close() uses
the list to count the number of drm_local_map references. For this, we
switch to using a counter inside drm_local_map.
This patch kills drm_vm_open_locked and drm_vm_close_locked, and
redirects the one user outside of the core (exoynos) to use the now
semantically equivalent drm_gem_vm_open.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
Cc: Rob Clark
Cc: Inki Dae
---
drivers/gpu/drm/drm_bufs.c | 1 +
drivers/gpu/drm/drm_drv.c | 8 -
drivers/gpu/drm/drm_gem.c | 16 +++--
drivers/gpu/drm/drm_info.c | 38 -
drivers/gpu/drm/drm_stub.c | 1 -
drivers/gpu/drm/drm_vm.c| 58 +++--
drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
include/drm/drmP.h | 7 ++--
8 files changed, 20 insertions(+), 118 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index bef4abf..b0aa2eb 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -152,6 +152,7 @@ static int drm_addmap_core(struct drm_device * dev,
resource_size_t offset,
map->size = size;
map->flags = flags;
map->type = type;
+ map->count = 0;
/* Only allow shared memory to be removable since we only keep enough
* book keeping information about shared memory to allow for removal
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 799..7ec9959 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -182,8 +182,6 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
*/
int drm_lastclose(struct drm_device * dev)
{
- struct drm_vma_entry *vma, *vma_temp;
-
DRM_DEBUG("\n");
if (dev->driver->lastclose)
@@ -203,12 +201,6 @@ int drm_lastclose(struct drm_device * dev)
dev->sg = NULL;
}
- /* Clear vma list (only built for debugging) */
- list_for_each_entry_safe(vma, vma_temp, &dev->vmalist, head) {
- list_del(&vma->head);
- kfree(vma);
- }
-
if (drm_core_check_feature(dev, DRIVER_HAVE_DMA) &&
!drm_core_check_feature(dev, DRIVER_MODESET))
drm_dma_takedown(dev);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 9ab038c..84a5834 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -573,22 +573,16 @@ void drm_gem_vm_open(struct vm_area_struct *vma)
struct drm_gem_object *obj = vma->vm_private_data;
drm_gem_object_reference(obj);
-
- mutex_lock(&obj->dev->struct_mutex);
- drm_vm_open_locked(obj->dev, vma);
- mutex_unlock(&obj->dev->struct_mutex);
+ drm_vma_open(obj->dev, vma);
}
EXPORT_SYMBOL(drm_gem_vm_open);
void drm_gem_vm_close(struct vm_area_struct *vma)
{
struct drm_gem_object *obj = vma->vm_private_data;
- struct drm_device *dev = obj->dev;
- mutex_lock(&dev->struct_mutex);
- drm_vm_close_locked(obj->dev, vma);
- drm_gem_object_unreference(obj);
- mutex_unlock(&dev->struct_mutex);
+ drm_vma_close(obj->dev, vma);
+ drm_gem_object_unreference_unlocked(obj);
}
EXPORT_SYMBOL(drm_gem_vm_close);
@@ -639,9 +633,7 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned
long obj_size,
* (which should happen whether the vma was created by this call, or
* by a vm_open due to mremap or partial unmap or whatever).
*/
- drm_gem_object_reference(obj);
-
- drm_vm_open_locked(dev, vma);
+ drm_gem_vm_open(vma);
return 0;
}
EXPORT_SYMBOL(drm_gem_mmap_obj);
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index d4b20ce..6ea817c 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -228,49 +228,11 @@ int drm_vma_info(struct seq_file *m, void *data)
{
struct drm_info_node *node = (struct drm_info_node *) m->private;
struct drm_device *dev = node->minor->dev;
- struct drm_vma_entry *pt;
- struct vm_area_struct *vma;
-#if defined(__i386__)
- unsigned int pgprot;
-#endif
- mutex_lock(&dev->struct_mutex);
seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
atomic_read(&dev->vma_count),
high_memory, (void *)(unsigned
long)virt_to_phys(high_memory));
- list_for_each_entry(pt, &dev->vmalist, head) {
- vma = pt->vma;
- if (!vma)
- continue;
- seq_printf(m,
- "\n%5d 0x%pK-0x%pK
[PATCH] drm/ttm: kill unused functions
Reviewed-by: Thomas Hellstrom
On 08/15/2013 04:03 PM, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 159
>
> 1 file changed, 159 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 3df9f16..87906c2 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -304,162 +304,3 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct
> ttm_buffer_object *bo)
> return 0;
> }
> EXPORT_SYMBOL(ttm_fbdev_mmap);
> -
> -
> -ssize_t ttm_bo_io(struct ttm_bo_device *bdev, struct file *filp,
> - const char __user *wbuf, char __user *rbuf, size_t count,
> - loff_t *f_pos, bool write)
> -{
> - struct ttm_buffer_object *bo;
> - struct ttm_bo_driver *driver;
> - struct ttm_bo_kmap_obj map;
> - unsigned long dev_offset = (*f_pos >> PAGE_SHIFT);
> - unsigned long kmap_offset;
> - unsigned long kmap_end;
> - unsigned long kmap_num;
> - size_t io_size;
> - unsigned int page_offset;
> - char *virtual;
> - int ret;
> - bool no_wait = false;
> - bool dummy;
> -
> - read_lock(&bdev->vm_lock);
> - bo = ttm_bo_vm_lookup_rb(bdev, dev_offset, 1);
> - if (likely(bo != NULL))
> - ttm_bo_reference(bo);
> - read_unlock(&bdev->vm_lock);
> -
> - if (unlikely(bo == NULL))
> - return -EFAULT;
> -
> - driver = bo->bdev->driver;
> - if (unlikely(!driver->verify_access)) {
> - ret = -EPERM;
> - goto out_unref;
> - }
> -
> - ret = driver->verify_access(bo, filp);
> - if (unlikely(ret != 0))
> - goto out_unref;
> -
> - kmap_offset = dev_offset - bo->vm_node->start;
> - if (unlikely(kmap_offset >= bo->num_pages)) {
> - ret = -EFBIG;
> - goto out_unref;
> - }
> -
> - page_offset = *f_pos & ~PAGE_MASK;
> - io_size = bo->num_pages - kmap_offset;
> - io_size = (io_size << PAGE_SHIFT) - page_offset;
> - if (count < io_size)
> - io_size = count;
> -
> - kmap_end = (*f_pos + count - 1) >> PAGE_SHIFT;
> - kmap_num = kmap_end - kmap_offset + 1;
> -
> - ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
> -
> - switch (ret) {
> - case 0:
> - break;
> - case -EBUSY:
> - ret = -EAGAIN;
> - goto out_unref;
> - default:
> - goto out_unref;
> - }
> -
> - ret = ttm_bo_kmap(bo, kmap_offset, kmap_num, &map);
> - if (unlikely(ret != 0)) {
> - ttm_bo_unreserve(bo);
> - goto out_unref;
> - }
> -
> - virtual = ttm_kmap_obj_virtual(&map, &dummy);
> - virtual += page_offset;
> -
> - if (write)
> - ret = copy_from_user(virtual, wbuf, io_size);
> - else
> - ret = copy_to_user(rbuf, virtual, io_size);
> -
> - ttm_bo_kunmap(&map);
> - ttm_bo_unreserve(bo);
> - ttm_bo_unref(&bo);
> -
> - if (unlikely(ret != 0))
> - return -EFBIG;
> -
> - *f_pos += io_size;
> -
> - return io_size;
> -out_unref:
> - ttm_bo_unref(&bo);
> - return ret;
> -}
> -
> -ssize_t ttm_bo_fbdev_io(struct ttm_buffer_object *bo, const char __user
> *wbuf,
> - char __user *rbuf, size_t count, loff_t *f_pos,
> - bool write)
> -{
> - struct ttm_bo_kmap_obj map;
> - unsigned long kmap_offset;
> - unsigned long kmap_end;
> - unsigned long kmap_num;
> - size_t io_size;
> - unsigned int page_offset;
> - char *virtual;
> - int ret;
> - bool no_wait = false;
> - bool dummy;
> -
> - kmap_offset = (*f_pos >> PAGE_SHIFT);
> - if (unlikely(kmap_offset >= bo->num_pages))
> - return -EFBIG;
> -
> - page_offset = *f_pos & ~PAGE_MASK;
> - io_size = bo->num_pages - kmap_offset;
> - io_size = (io_size << PAGE_SHIFT) - page_offset;
> - if (count < io_size)
> - io_size = count;
> -
> - kmap_end = (*f_pos + count - 1) >> PAGE_SHIFT;
> - kmap_num = kmap_end - kmap_offset + 1;
> -
> - ret = ttm_bo_reserve(bo, true, no_wait, false, 0);
> -
> - switch (ret) {
> - case 0:
> - break;
> - case -EBUSY:
> - return -EAGAIN;
> - default:
> - return ret;
> - }
> -
> - ret = ttm_bo_kmap(bo, kmap_offset, kmap_num, &map);
> - if (unlikely(ret != 0)) {
> - ttm_bo_unreserve(bo);
> - return ret;
> - }
> -
> - virtual = ttm_kmap_obj_virtual(&map, &dummy);
> - virtual += page_offset;
> -
> - if (write)
> - ret = copy_from_user(virtual, wbuf, io_size);
> - else
> - ret = copy_to_user(rbuf, virtual, io_size);
> -
> - ttm_bo_kunmap(&map);
> - ttm_bo_unreserve(bo);
> - ttm_bo_unref(&bo);
> -
> - if (unlikely(ret != 0))
> - return
[Bug 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 Alex Deucher changed: What|Removed |Added Summary|evergreen: hard lockup on |evergreen: hard lockup on |suspend and resume with |suspend and resume with dpm |current firmware| --- Comment #1 from Alex Deucher --- It's not the firmware per se. It's probably the new dpm code. Do you still get when dpm is disabled? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/79839578/attachment.html>
[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #69 from Alex Deucher --- I would recommend you do a piglit run (quick driver tests) before and after and make sure there are no regressions. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/df9960e7/attachment.html>
[PATCH 08/16] drm/vmwgfx: implement mmap access managament
Hi
On Wed, Aug 14, 2013 at 7:35 PM, Thomas Hellstrom
wrote:
> (CC'ing the proper people since I'm still on parental leave).
>
> On 08/13/2013 11:44 PM, David Herrmann wrote:
>
> Please see inline comments.
>
>
>> Hi
>>
>> On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann
>> wrote:
>>>
>>> Correctly allow and revoke buffer access on each open/close via the new
>>> VMA offset manager.
>
>
> I haven't yet had time to check the access policies of the new VMA offset
> manager, but anything that is identical or stricter than the current vmwgfx
> verify_access() would be fine. If it's stricter however, we need to
> double-check backwards user-space compatibility.
My patches make vmw_dmabuf_alloc_ioctl() add the caller's open-file
(file*) to the list of allowed users of the new bo.
vmw_dmabuf_unref_ioctl() removes it again. I haven't seen any way to
pass a user-dmabuf to another user so there is currently at most one
user for a vmw_dmabuf. vmw_user_dmabuf_reference() looks like it is
intended exactly for this case so it would have to add the file* of
the caller to the list of allowed users. I will change that in v2.
This means every user who gets a handle for the buffer (like gem_open)
will be added to the allowed users. For TTM-object currently only a
single user is allowed.
So I replace vmw_user_bo->base.tfile with a list (actually rbtree) of
allowed files. So more than one user can have access. This, however,
breaks the "shareable" attribute which I wasn't aware of. As far as I
can see, "shareable" is only used by vmwgfx_surface.c and can be set
by userspace to allow arbitrary processes to map this buffer (sounds
like a security issue similar to gem flink).
I actually think we can replace the "shareable" attribute with proper
access-management in the vma-manager. But first I'd need to know
whether "shareable = true" is actually used by vmwgfx user-space and
how buffers are shared? Do you simply pass the mmap offset between
processes? Or do you pass some handle?
If you really pass mmap offsets in user-space and rely on this, I
guess there is no way I can make vmwgfx use the vma-manager access
management. I will have to find a way to work around it or move the
"shareable" flag to ttm_bo.
>
>>> We also need to make vmw_user_dmabuf_reference()
>>> correctly increase the vma-allow counter, but it is unused so remove it
>>> instead.
>
> IIRC this function or a derivative thereof is used heavily in an upcoming
> version driver, so if possible, please add a corrected version rather than
> remove the (currently) unused code. This will trigger a merge error and the
> upcoming code can be more easily corrected.
I will do so.
>
>>>
>>> Cc: Thomas Hellstrom
>>> Signed-off-by: David Herrmann
>>
>> Just as a hint, this patch would allow to remove the
>> "->access_verify()" callback in vmwgfx. No other driver uses it,
>> afaik. I will try to add this in v2.
>>
>> Regards
>> David
>>
>>> ---
>>> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 29
>>> +
>>> 1 file changed, 17 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>>> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>>> index 0e67cf4..4d3f0ae 100644
>>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
>>> @@ -499,6 +499,12 @@ int vmw_dmabuf_alloc_ioctl(struct drm_device *dev,
>>> void *data,
>>> if (unlikely(ret != 0))
>>> goto out_no_dmabuf;
>>>
>>> + ret = drm_vma_node_allow(&dma_buf->base.vma_node,
>>> file_priv->filp);
>>> + if (ret) {
>>> + vmw_dmabuf_unreference(&dma_buf);
>>> + goto out_no_dmabuf;
>>> + }
>>> +
>>> rep->handle = handle;
>>> rep->map_handle =
>>> drm_vma_node_offset_addr(&dma_buf->base.vma_node);
>>> rep->cur_gmr_id = handle;
>>> @@ -517,7 +523,18 @@ int vmw_dmabuf_unref_ioctl(struct drm_device *dev,
>>> void *data,
>>> {
>>> struct drm_vmw_unref_dmabuf_arg *arg =
>>> (struct drm_vmw_unref_dmabuf_arg *)data;
>>> + struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
>>> + struct vmw_dma_buffer *dma_buf;
>>> + int ret;
>>> +
>>> + ret = vmw_user_dmabuf_lookup(tfile, arg->handle, &dma_buf);
>>> + if (ret)
>>> + return -EINVAL;
>>>
>>> + drm_vma_node_revoke(&dma_buf->base.vma_node, file_priv->filp);
>>> + vmw_dmabuf_unreference(&dma_buf);
>>> +
>>> + /* FIXME: is this equivalent to vmw_dmabuf_unreference(dma_buf)?
>>> */
>
>
> No. A ttm ref object is rather similar to a generic GEM object, only that
> it's generic in the sense that it is not restricted to buffers, and can make
> any desired object visible to user-space. So translated the below code
> removes a reference that the arg->handle holds on the "gem" object,
> potentially destroying the whole object in which the "gem" object is
> embedded.
So I actually need both lookups, vmw_u
[Bug 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 --- Comment #2 from nine at detonation.org --- (In reply to comment #1) > It's not the firmware per se. It's probably the new dpm code. Do you still > get when dpm is disabled? Indeed. If I turn off dpm, I can suspend successfully and more or less successfully resume. But a few seconds after resume my X server dies. May be related or not. Attaching a dmesg taken after that. It's strange though that with an older kernel I still get hangs on suspend and resume even though they do not support dpm at all. So how can I proceed? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/1ec7dd14/attachment.html>
[Bug 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 --- Comment #3 from nine at detonation.org --- Created attachment 84144 --> https://bugs.freedesktop.org/attachment.cgi?id=84144&action=edit dmesg after X server crash after suspend/resume without dpm -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/dd97b06a/attachment.html>
[Bug 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 --- Comment #4 from Alex Deucher --- Sounds like this may be a problem independent of dpm. Have you ever had successful suspend and resume? When you say X crash, do you you mean X hangs? system hangs? segfault? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/65f8b620/attachment.html>
[Bug 60687] Using radeon.audio=1 blocks hdmi display output on Radeon 5760
https://bugzilla.kernel.org/show_bug.cgi?id=60687 --- Comment #13 from Gabor Hasenfrasz --- @Rafa?: I've tested the patch and solves the problem in my case. Thank you! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 68178] evergreen: hard lockup on suspend and resume with dpm
https://bugs.freedesktop.org/show_bug.cgi?id=68178 --- Comment #5 from nine at detonation.org --- (In reply to comment #4) > Sounds like this may be a problem independent of dpm. Have you ever had > successful suspend and resume? I've always (meaning > 5 years) had successful suspend and resume on this machine. Until I updated the firmware files to test UVD and then dpm. With the original firmware contained in openSUSE's kernel-firmware-20130114git-1.2.1 package, suspend/resume works just fine. I started having problems immediately after updating the radeon firmware files from your FTP site. In the meantime, openSUSE shipped an update to the kernel-firmware package with which I see the same problems. > When you say X crash, do you you mean X > hangs? system hangs? segfault? I mean the X server terminated unexpectedly and I got thrown back to the login screen. Other than this message and the part about GPU lockup in the dmesg dump I posted, I could not find any messages. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/c07598a5/attachment.html>
[PATCH 08/16] drm/vmwgfx: implement mmap access managament
On 08/16/2013 03:19 PM, David Herrmann wrote: > Hi > > On Wed, Aug 14, 2013 at 7:35 PM, Thomas Hellstrom > wrote: >> (CC'ing the proper people since I'm still on parental leave). >> >> On 08/13/2013 11:44 PM, David Herrmann wrote: >> >> Please see inline comments. >> >> >>> Hi >>> >>> On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann >>> wrote: Correctly allow and revoke buffer access on each open/close via the new VMA offset manager. >> >> I haven't yet had time to check the access policies of the new VMA offset >> manager, but anything that is identical or stricter than the current vmwgfx >> verify_access() would be fine. If it's stricter however, we need to >> double-check backwards user-space compatibility. > My patches make vmw_dmabuf_alloc_ioctl() add the caller's open-file > (file*) to the list of allowed users of the new bo. > vmw_dmabuf_unref_ioctl() removes it again. I haven't seen any way to > pass a user-dmabuf to another user so there is currently at most one > user for a vmw_dmabuf. vmw_user_dmabuf_reference() looks like it is > intended exactly for this case so it would have to add the file* of > the caller to the list of allowed users. I will change that in v2. > This means every user who gets a handle for the buffer (like gem_open) > will be added to the allowed users. For TTM-object currently only a > single user is allowed. > > So I replace vmw_user_bo->base.tfile with a list (actually rbtree) of > allowed files. So more than one user can have access. This, however, > breaks the "shareable" attribute which I wasn't aware of. As far as I > can see, "shareable" is only used by vmwgfx_surface.c and can be set > by userspace to allow arbitrary processes to map this buffer (sounds > like a security issue similar to gem flink). > I actually think we can replace the "shareable" attribute with proper > access-management in the vma-manager. But first I'd need to know > whether "shareable = true" is actually used by vmwgfx user-space and > how buffers are shared? Do you simply pass the mmap offset between > processes? Or do you pass some handle? Buffer- and surface sharing is done by passing an opaque (not mmap) handle. A process intending to map the shared buffer must obtain the map offset through a vmw_user_dmabuf_reference() call, and that only works if the buffer is "shareable". mmap offsets are never passed between processes, but valid only if obtained directly from the kernel driver. This means that currently buffer mapping should have the same access restriction as the X server imposes on DRI clients; If a process is allowed to open the drm device, it also has map access to all "shareable" objects, which is a security hole in the sense that verify_access() should really check that the caller, if not the buffer owner, is also authenticated. The reason verify_access() is there is to make the TTM buffer object transparent to how it is exported to user space (GEM or TTM objects). Apparently the GEM TTM drivers have ignored this hook for some unknown reason. Some ideas: 1) Rather than having a list of allowable files on each buffer object, perhaps we should have a user and a group and a set of permissions (for user, group and system) more like how files are handled? 2) Rather than imposing a security policy in the vma manager, could we perhaps have a set a utility functions that are called through verify_access(). Each driver could then have a wrapper to gather the needed information and hand it over to the VMA manager? > > If you really pass mmap offsets in user-space and rely on this, I > guess there is no way I can make vmwgfx use the vma-manager access > management. I will have to find a way to work around it or move the > "shareable" flag to ttm_bo. > We also need to make vmw_user_dmabuf_reference() correctly increase the vma-allow counter, but it is unused so remove it instead. >> IIRC this function or a derivative thereof is used heavily in an upcoming >> version driver, so if possible, please add a corrected version rather than >> remove the (currently) unused code. This will trigger a merge error and the >> upcoming code can be more easily corrected. > I will do so. > Cc: Thomas Hellstrom Signed-off-by: David Herrmann >>> Just as a hint, this patch would allow to remove the >>> "->access_verify()" callback in vmwgfx. No other driver uses it, >>> afaik. I will try to add this in v2. >>> >>> Regards >>> David >>> --- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 29 + 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c index 0e67cf4..4d3f0ae 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c @@ -499,6 +499,12 @@ int vmw_dmabuf_alloc_ioctl(struct drm_device *dev, void *data, if (unlike
[PATCH 08/16] drm/vmwgfx: implement mmap access managament
Hi On Fri, Aug 16, 2013 at 5:33 PM, Thomas Hellstrom wrote: > On 08/16/2013 03:19 PM, David Herrmann wrote: >> >> Hi >> >> On Wed, Aug 14, 2013 at 7:35 PM, Thomas Hellstrom >> wrote: >>> >>> (CC'ing the proper people since I'm still on parental leave). >>> >>> On 08/13/2013 11:44 PM, David Herrmann wrote: >>> >>> Please see inline comments. >>> >>> Hi On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann wrote: > > Correctly allow and revoke buffer access on each open/close via the new > VMA offset manager. >>> >>> >>> I haven't yet had time to check the access policies of the new VMA offset >>> manager, but anything that is identical or stricter than the current >>> vmwgfx >>> verify_access() would be fine. If it's stricter however, we need to >>> double-check backwards user-space compatibility. >> >> My patches make vmw_dmabuf_alloc_ioctl() add the caller's open-file >> (file*) to the list of allowed users of the new bo. >> vmw_dmabuf_unref_ioctl() removes it again. I haven't seen any way to >> pass a user-dmabuf to another user so there is currently at most one >> user for a vmw_dmabuf. vmw_user_dmabuf_reference() looks like it is >> intended exactly for this case so it would have to add the file* of >> the caller to the list of allowed users. I will change that in v2. >> This means every user who gets a handle for the buffer (like gem_open) >> will be added to the allowed users. For TTM-object currently only a >> single user is allowed. >> >> So I replace vmw_user_bo->base.tfile with a list (actually rbtree) of >> allowed files. So more than one user can have access. This, however, >> breaks the "shareable" attribute which I wasn't aware of. As far as I >> can see, "shareable" is only used by vmwgfx_surface.c and can be set >> by userspace to allow arbitrary processes to map this buffer (sounds >> like a security issue similar to gem flink). >> I actually think we can replace the "shareable" attribute with proper >> access-management in the vma-manager. But first I'd need to know >> whether "shareable = true" is actually used by vmwgfx user-space and >> how buffers are shared? Do you simply pass the mmap offset between >> processes? Or do you pass some handle? > > > Buffer- and surface sharing is done by passing an opaque (not mmap) handle. > A process intending to map the shared buffer must obtain the map offset > through a > vmw_user_dmabuf_reference() call, and that only works if the buffer is > "shareable". Ugh? That's not true. At least in upstream vmwgfx vmw_user_dmabuf_reference() is unused. Maybe you have access to some newer codebase? Anyway, I can easily make this function call drm_vma_node_allow() and then newer vmwgfx additions will work just fine. This means, every user who calls vmw_user_dmabuf_reference() will then also be allowed to mmap that buffer. But users who do not own a handle (that is, they didn't call vmw_user_dmabuf_reference() or they dropped the reference via vmw_user_dmabuf_unref_ioctl()) will get -EACCES if they try to mmap the buffer. This is an extension to how it currently works, so I doubt that it breaks any user-space. Is that fine for vmwgfx? > mmap offsets are never passed between processes, but valid only if obtained > directly > from the kernel driver. Good to hear. That means this patch doesn't break any existing userspace. > This means that currently buffer mapping should have the same access > restriction as the > X server imposes on DRI clients; If a process is allowed to open the drm > device, it also has > map access to all "shareable" objects, which is a security hole in the sense > that verify_access() should > really check that the caller, if not the buffer owner, is also > authenticated. I actually don't care for DRI. This series tries to fix exactly that. I don't want that. Users with DRM access shouldn't be able to map arbitrary buffers. Instead, users should only be able to map buffers that they own a handle for. Access management for handles is an orthogonal problem that this series does not change. dma-buf does a pretty good job there, anyway. > The reason verify_access() is there is to make the TTM buffer object > transparent to how it is exported > to user space (GEM or TTM objects). Apparently the GEM TTM drivers have > ignored this hook for some unknown > reason. I don't think that we need any extended access-management here. Why would we ever need different access-modes for mmap than for handles? This series reduces mmap() access-management to handle-access-management. That is, the right to mmap() a buffer is now bound to a buffer handle. If you don't own a handle, you cannot mmap the buffer. But if you own a handle, you're always allowed to mmap the buffer. I think this should be the policy to go for, or am I missing something? That's also why I think verify_access() is not needed at all. Drivers shouldn't care for mmap() access, instead they should take care only privileged users get handles (whatever t
[Bug 67876] linux v3.11.0-rc1 many drm:radeon_ttm_backend_bind ERROR failed to bind 2025 pages issued during boot
https://bugs.freedesktop.org/show_bug.cgi?id=67876 Alexandre Demers changed: What|Removed |Added Summary|linux v4.11-rc1 many|linux v3.11.0-rc1 many |drm:radeon_ttm_backend_bind |drm:radeon_ttm_backend_bind |ERROR failed to bind 2025 |ERROR failed to bind 2025 |pages issued during boot|pages issued during boot -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/0b964b92/attachment.html>
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 Alexandre Demers changed: What|Removed |Added Summary|r600: linux 3.11RC isn't|r600: linux v3.11.0-RC |booting with radeon.dpm=1 |isn't booting with |option in grub |radeon.dpm=1 option in grub -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/51376990/attachment.html>
[PATCH 08/16] drm/vmwgfx: implement mmap access managament
On 08/16/2013 07:01 PM, David Herrmann wrote: > Hi > > On Fri, Aug 16, 2013 at 5:33 PM, Thomas Hellstrom > wrote: >> On 08/16/2013 03:19 PM, David Herrmann wrote: >>> Hi >>> >>> On Wed, Aug 14, 2013 at 7:35 PM, Thomas Hellstrom >>> wrote: (CC'ing the proper people since I'm still on parental leave). On 08/13/2013 11:44 PM, David Herrmann wrote: Please see inline comments. > Hi > > On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann > wrote: >> Correctly allow and revoke buffer access on each open/close via the new >> VMA offset manager. I haven't yet had time to check the access policies of the new VMA offset manager, but anything that is identical or stricter than the current vmwgfx verify_access() would be fine. If it's stricter however, we need to double-check backwards user-space compatibility. >>> My patches make vmw_dmabuf_alloc_ioctl() add the caller's open-file >>> (file*) to the list of allowed users of the new bo. >>> vmw_dmabuf_unref_ioctl() removes it again. I haven't seen any way to >>> pass a user-dmabuf to another user so there is currently at most one >>> user for a vmw_dmabuf. vmw_user_dmabuf_reference() looks like it is >>> intended exactly for this case so it would have to add the file* of >>> the caller to the list of allowed users. I will change that in v2. >>> This means every user who gets a handle for the buffer (like gem_open) >>> will be added to the allowed users. For TTM-object currently only a >>> single user is allowed. >>> >>> So I replace vmw_user_bo->base.tfile with a list (actually rbtree) of >>> allowed files. So more than one user can have access. This, however, >>> breaks the "shareable" attribute which I wasn't aware of. As far as I >>> can see, "shareable" is only used by vmwgfx_surface.c and can be set >>> by userspace to allow arbitrary processes to map this buffer (sounds >>> like a security issue similar to gem flink). >>> I actually think we can replace the "shareable" attribute with proper >>> access-management in the vma-manager. But first I'd need to know >>> whether "shareable = true" is actually used by vmwgfx user-space and >>> how buffers are shared? Do you simply pass the mmap offset between >>> processes? Or do you pass some handle? >> >> Buffer- and surface sharing is done by passing an opaque (not mmap) handle. >> A process intending to map the shared buffer must obtain the map offset >> through a >> vmw_user_dmabuf_reference() call, and that only works if the buffer is >> "shareable". > Ugh? That's not true. At least in upstream vmwgfx > vmw_user_dmabuf_reference() is unused. Maybe you have access to some > newer codebase? Yes, this is how TTM buffer management used to work in older TTM drivers and how the codebase for newer device versions will work. > Anyway, I can easily make this function call > drm_vma_node_allow() and then newer vmwgfx additions will work just > fine. This means, every user who calls vmw_user_dmabuf_reference() > will then also be allowed to mmap that buffer. But users who do not > own a handle (that is, they didn't call vmw_user_dmabuf_reference() or > they dropped the reference via vmw_user_dmabuf_unref_ioctl()) will get > -EACCES if they try to mmap the buffer. > > This is an extension to how it currently works, so I doubt that it > breaks any user-space. Is that fine for vmwgfx? Yes, that sounds fine. > >> mmap offsets are never passed between processes, but valid only if obtained >> directly >> from the kernel driver. > Good to hear. That means this patch doesn't break any existing userspace. > >> This means that currently buffer mapping should have the same access >> restriction as the >> X server imposes on DRI clients; If a process is allowed to open the drm >> device, it also has >> map access to all "shareable" objects, which is a security hole in the sense >> that verify_access() should >> really check that the caller, if not the buffer owner, is also >> authenticated. > I actually don't care for DRI. This series tries to fix exactly that. > I don't want that. Users with DRM access shouldn't be able to map > arbitrary buffers. Instead, users should only be able to map buffers > that they own a handle for. Access management for handles is an > orthogonal problem that this series does not change. dma-buf does a > pretty good job there, anyway. Understood. > >> The reason verify_access() is there is to make the TTM buffer object >> transparent to how it is exported >> to user space (GEM or TTM objects). Apparently the GEM TTM drivers have >> ignored this hook for some unknown >> reason. > I don't think that we need any extended access-management here. Why > would we ever need different access-modes for mmap than for handles? > This series reduces mmap() access-management to > handle-access-management. That is, the right to mmap() a buffer is now > bound to a buffer handle. If you don't own a handle, you cannot mmap > the buffe
[PATCH] intel: Update i915_drm.h and correct misspelled caching
On 08/14/2013 01:19 AM, Sedat Dilek wrote:
> AFAICS, there are more updates needed to be in sync with recent kernel-drm.
>
> I fell over the misspelling when digging into an issue in Linux-next.
> The spelling should be consistent in kernel-drm, libdrm, intel-ddx, etc.
> Here, I had a look especially at the defined macros (defines).
>
> Signed-off-by: Sedat Dilek
This should get Chris's ok before committing, but
Reviewed-by: Ian Romanick ---
> include/drm/i915_drm.h | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index aa983f3..61a8407 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -195,8 +195,8 @@ typedef struct _drm_i915_sarea {
> #define DRM_I915_GEM_WAIT 0x2c
> #define DRM_I915_GEM_CONTEXT_CREATE 0x2d
> #define DRM_I915_GEM_CONTEXT_DESTROY0x2e
> -#define DRM_I915_GEM_SET_CACHEING0x2f
> -#define DRM_I915_GEM_GET_CACHEING0x30
> +#define DRM_I915_GEM_SET_CACHING 0x2f
> +#define DRM_I915_GEM_GET_CACHING 0x30
> #define DRM_I915_REG_READ 0x31
>
> #define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
> DRM_I915_INIT, drm_i915_init_t)
> @@ -222,8 +222,8 @@ typedef struct _drm_i915_sarea {
> #define DRM_IOCTL_I915_GEM_PIN DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_PIN, struct drm_i915_gem_pin)
> #define DRM_IOCTL_I915_GEM_UNPINDRM_IOW(DRM_COMMAND_BASE +
> DRM_I915_GEM_UNPIN, struct drm_i915_gem_unpin)
> #define DRM_IOCTL_I915_GEM_BUSY DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_BUSY, struct drm_i915_gem_busy)
> -#define DRM_IOCTL_I915_GEM_SET_CACHEING
> DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHEING, struct
> drm_i915_gem_cacheing)
> -#define DRM_IOCTL_I915_GEM_GET_CACHEING
> DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHEING, struct
> drm_i915_gem_cacheing)
> +#define DRM_IOCTL_I915_GEM_SET_CACHING
> DRM_IOW(DRM_COMMAND_BASE + DRM_I915_GEM_SET_CACHING, struct
> drm_i915_gem_caching)
> +#define DRM_IOCTL_I915_GEM_GET_CACHING
> DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHING, struct
> drm_i915_gem_caching)
> #define DRM_IOCTL_I915_GEM_THROTTLE DRM_IO ( DRM_COMMAND_BASE +
> DRM_I915_GEM_THROTTLE)
> #define DRM_IOCTL_I915_GEM_ENTERVT DRM_IO(DRM_COMMAND_BASE +
> DRM_I915_GEM_ENTERVT)
> #define DRM_IOCTL_I915_GEM_LEAVEVT DRM_IO(DRM_COMMAND_BASE +
> DRM_I915_GEM_LEAVEVT)
> @@ -706,21 +706,22 @@ struct drm_i915_gem_busy {
> __u32 busy;
> };
>
> -#define I915_CACHEING_NONE 0
> -#define I915_CACHEING_CACHED 1
> +#define I915_CACHING_NONE0
> +#define I915_CACHING_CACHED 1
> +#define I915_CACHING_DISPLAY 2
>
> -struct drm_i915_gem_cacheing {
> +struct drm_i915_gem_caching {
> /**
> - * Handle of the buffer to set/get the cacheing level of. */
> + * Handle of the buffer to set/get the caching level of. */
> __u32 handle;
>
> /**
>* Cacheing level to apply or return value
>*
> - * bits0-15 are for generic cacheing control (i.e. the above defined
> + * bits0-15 are for generic caching control (i.e. the above defined
>* values). bits16-31 are reserved for platform-specific variations
>* (e.g. l3$ caching on gen7). */
> - __u32 cacheing;
> + __u32 caching;
> };
>
> #define I915_TILING_NONE0
>
[PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute
From: Tom Stellard
Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.
Signed-off-by: Tom Stellard
---
drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
drivers/gpu/drm/radeon/radeon_kms.c | 3 +
drivers/gpu/drm/radeon/si.c | 106 +---
include/uapi/drm/radeon_drm.h | 2 +
4 files changed, 68 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 29876b1..c2c6da1 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -75,9 +75,10 @@
* 2.32.0 - new info request for rings working
* 2.33.0 - Add SI tiling mode array query
* 2.34.0 - Add CIK tiling mode array query
+ * 2.35.0 - Add SI CP DMA compute query
*/
#define KMS_DRIVER_MAJOR 2
-#define KMS_DRIVER_MINOR 34
+#define KMS_DRIVER_MINOR 35
#define KMS_DRIVER_PATCHLEVEL 0
int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 49ff3d1..cc2ca38 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -433,6 +433,9 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return -EINVAL;
}
break;
+ case RADEON_INFO_SI_CP_DMA_COMPUTE:
+ *value = 1;
+ break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index daa8d2d..8a21132 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4083,13 +4083,64 @@ static int si_vm_packet3_ce_check(struct radeon_device
*rdev,
return 0;
}
+static int si_vm_packet3_cp_dma_check(u32 *ib, u32 idx)
+{
+ u32 start_reg, reg, i;
+ u32 command = ib[idx + 4];
+ u32 info = ib[idx + 1];
+ u32 idx_value = ib[idx];
+ if (command & PACKET3_CP_DMA_CMD_SAS) {
+ /* src address space is register */
+ if (((info & 0x6000) >> 29) == 0) {
+ start_reg = idx_value << 2;
+ if (command & PACKET3_CP_DMA_CMD_SAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad SRC register\n");
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i < (command & 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad SRC
register\n");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ if (command & PACKET3_CP_DMA_CMD_DAS) {
+ /* dst address space is register */
+ if (((info & 0x0030) >> 20) == 0) {
+ start_reg = ib[idx + 2];
+ if (command & PACKET3_CP_DMA_CMD_DAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad DST register\n");
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i < (command & 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad DST
register\n");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ return 0;
+}
+
static int si_vm_packet3_gfx_check(struct radeon_device *rdev,
u32 *ib, struct radeon_cs_packet *pkt)
{
+ int r;
u32 idx = pkt->idx + 1;
u32 idx_value = ib[idx];
u32 start_reg, end_reg, reg, i;
- u32 command, info;
switch (pkt->opcode) {
case PACKET3_NOP:
@@ -4190,50 +4241,9 @@ static int si_vm_packet3_gfx_check(struct radeon_device
*rdev,
}
break;
case PACKET3_CP_DMA:
- command = ib[idx + 4];
- info = ib[idx + 1];
- if (command & PACKET3_CP_DMA_CMD_SAS) {
-
[PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute
On Fri, Aug 16, 2013 at 3:16 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> Also add a new RADEON_INFO query to check that CP DMA packets are
> supported on the compute ring.
>
> Signed-off-by: Tom Stellard
> ---
> drivers/gpu/drm/radeon/radeon_drv.c | 3 +-
> drivers/gpu/drm/radeon/radeon_kms.c | 3 +
> drivers/gpu/drm/radeon/si.c | 106
> +---
> include/uapi/drm/radeon_drm.h | 2 +
> 4 files changed, 68 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 29876b1..c2c6da1 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -75,9 +75,10 @@
> * 2.32.0 - new info request for rings working
> * 2.33.0 - Add SI tiling mode array query
> * 2.34.0 - Add CIK tiling mode array query
> + * 2.35.0 - Add SI CP DMA compute query
> */
> #define KMS_DRIVER_MAJOR 2
> -#define KMS_DRIVER_MINOR 34
> +#define KMS_DRIVER_MINOR 35
Skip the version bump if we want this to go to stable kernels. We can
query the info ioctl for the cp_dma_compute arg and if it's a kernel
where it doesn't exist, it'll just fail. if it exists the ioctl will
succeed. If we don't want to send this to stable, just bump the
version and skip the info ioctl.
Alex
> #define KMS_DRIVER_PATCHLEVEL 0
> int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
> int radeon_driver_unload_kms(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 49ff3d1..cc2ca38 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -433,6 +433,9 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
> struct drm_file *filp)
> return -EINVAL;
> }
> break;
> + case RADEON_INFO_SI_CP_DMA_COMPUTE:
> + *value = 1;
> + break;
> default:
> DRM_DEBUG_KMS("Invalid request %d\n", info->request);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
> index daa8d2d..8a21132 100644
> --- a/drivers/gpu/drm/radeon/si.c
> +++ b/drivers/gpu/drm/radeon/si.c
> @@ -4083,13 +4083,64 @@ static int si_vm_packet3_ce_check(struct
> radeon_device *rdev,
> return 0;
> }
>
> +static int si_vm_packet3_cp_dma_check(u32 *ib, u32 idx)
> +{
> + u32 start_reg, reg, i;
> + u32 command = ib[idx + 4];
> + u32 info = ib[idx + 1];
> + u32 idx_value = ib[idx];
> + if (command & PACKET3_CP_DMA_CMD_SAS) {
> + /* src address space is register */
> + if (((info & 0x6000) >> 29) == 0) {
> + start_reg = idx_value << 2;
> + if (command & PACKET3_CP_DMA_CMD_SAIC) {
> + reg = start_reg;
> + if (!si_vm_reg_valid(reg)) {
> + DRM_ERROR("CP DMA Bad SRC
> register\n");
> + return -EINVAL;
> + }
> + } else {
> + for (i = 0; i < (command & 0x1f); i++) {
> + reg = start_reg + (4 * i);
> + if (!si_vm_reg_valid(reg)) {
> + DRM_ERROR("CP DMA Bad SRC
> register\n");
> + return -EINVAL;
> + }
> + }
> + }
> + }
> + }
> + if (command & PACKET3_CP_DMA_CMD_DAS) {
> + /* dst address space is register */
> + if (((info & 0x0030) >> 20) == 0) {
> + start_reg = ib[idx + 2];
> + if (command & PACKET3_CP_DMA_CMD_DAIC) {
> + reg = start_reg;
> + if (!si_vm_reg_valid(reg)) {
> + DRM_ERROR("CP DMA Bad DST
> register\n");
> + return -EINVAL;
> + }
> + } else {
> + for (i = 0; i < (command & 0x1f); i++) {
> + reg = start_reg + (4 * i);
> + if (!si_vm_reg_valid(reg)) {
> + DRM_ERROR("CP DMA Bad DST
> register\n");
> + return -EINVAL;
> + }
> + }
> + }
> + }
> + }
> + return 0;
> +}
> +
> static int si_vm_packet3_gfx_check(struct radeon_device *rdev
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #10 from Bernhard Held --- My mileage varies with 3.11-rc5. In rare case suspend/resume works. Most of the time suspend shows: [ 34.926841] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 35.075229] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 45.908028] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 45.908031] radeon :01:00.0: GPU lockup (waiting for 0x0004 last fence id 0x0002) [ 45.908033] [drm:r600_uvd_ib_test] *ERROR* radeon: fence wait failed (-35). [ 45.908037] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35). During resume the PC either freezes after "PM: Read x kbytes in y.yy seconds" or dmesg shows: [4.879714] Freezing user space processes ... (elapsed 0.000 seconds) done. [5.190862] PM: Using 3 thread(s) for decompression. [5.190862] PM: Loading and decompressing image data (99920 pages)... [5.466130] PM: Image loading progress: 0% [5.774497] PM: Image loading progress: 10% [5.868650] PM: Image loading progress: 20% [5.951424] PM: Image loading progress: 30% [6.044454] PM: Image loading progress: 40% [6.158650] PM: Image loading progress: 50% [6.249908] PM: Image loading progress: 60% [6.336868] PM: Image loading progress: 70% [6.421403] PM: Image loading progress: 80% [6.508071] PM: Image loading progress: 90% [6.592575] PM: Image loading done. [6.596124] PM: Read 399680 kbytes in 1.39 seconds (287.53 MB/s) [ 35.608037] usb usb1: root hub lost power or was reset [ 35.608038] usb usb2: root hub lost power or was reset [ 35.948432] xhci_hcd :03:00.0: xHCI xhci_drop_endpoint called with disabled ep 8801a5f8e880 [ 45.992029] radeon :01:00.0: GPU lockup CP stall for more than 1msec [ 45.992032] radeon :01:00.0: GPU lockup (waiting for 0x0004 last fence id 0x0002) [ 45.992034] [drm:r600_uvd_ib_test] *ERROR* radeon: fence wait failed (-35). [ 45.992037] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on ring 5 (-35). [ 46.548477] Restarting tasks ... done. After this I can use the console and KDM is running, but X crashes at logon. Without CYPRESS_uvd.bin suspend/resume works reliable. CEDAR_me.bin, CEDAR_pfp.bin, CEDAR_rlc.bin, CEDAR_smc.bin and CYPRESS_uvd.bin are from git://git.kernel.org/pub/scm/linux/kernel/git/dwmw2/linux-firmware.git I'm using a 2560x1440 console with Dual-DVI. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/80ec11a0/attachment-0001.html>
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #11 from Bernhard Held --- Created attachment 84155 --> https://bugs.freedesktop.org/attachment.cgi?id=84155&action=edit full dmesg of suspend/resume cycle -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/1da33954/attachment.html>
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #12 from Bernhard Held --- Created attachment 84156 --> https://bugs.freedesktop.org/attachment.cgi?id=84156&action=edit lspci -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/7d50b5e3/attachment.html>
[Bug 66940] Mobility Radeon HD 5650 doesn't resume from suspend on kernel 3.11 (linus and drm_next)
https://bugs.freedesktop.org/show_bug.cgi?id=66940 --- Comment #13 from Bernhard Held --- Created attachment 84157 --> https://bugs.freedesktop.org/attachment.cgi?id=84157&action=edit .config for 3.11-rc5 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/c9d416c9/attachment.html>
[PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute v2
From: Tom Stellard
Also add a new RADEON_INFO query to check that CP DMA packets are
supported on the compute ring.
v2:
- Don't bump kms version, so this patch can be backported to stable
kernels.
Cc: stable at vger.kernel.org
Signed-off-by: Tom Stellard
---
drivers/gpu/drm/radeon/radeon_kms.c | 3 +
drivers/gpu/drm/radeon/si.c | 106 +---
include/uapi/drm/radeon_drm.h | 2 +
3 files changed, 66 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 49ff3d1..cc2ca38 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -433,6 +433,9 @@ int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
return -EINVAL;
}
break;
+ case RADEON_INFO_SI_CP_DMA_COMPUTE:
+ *value = 1;
+ break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index daa8d2d..8a21132 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -4083,13 +4083,64 @@ static int si_vm_packet3_ce_check(struct radeon_device
*rdev,
return 0;
}
+static int si_vm_packet3_cp_dma_check(u32 *ib, u32 idx)
+{
+ u32 start_reg, reg, i;
+ u32 command = ib[idx + 4];
+ u32 info = ib[idx + 1];
+ u32 idx_value = ib[idx];
+ if (command & PACKET3_CP_DMA_CMD_SAS) {
+ /* src address space is register */
+ if (((info & 0x6000) >> 29) == 0) {
+ start_reg = idx_value << 2;
+ if (command & PACKET3_CP_DMA_CMD_SAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad SRC register\n");
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i < (command & 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad SRC
register\n");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ if (command & PACKET3_CP_DMA_CMD_DAS) {
+ /* dst address space is register */
+ if (((info & 0x0030) >> 20) == 0) {
+ start_reg = ib[idx + 2];
+ if (command & PACKET3_CP_DMA_CMD_DAIC) {
+ reg = start_reg;
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad DST register\n");
+ return -EINVAL;
+ }
+ } else {
+ for (i = 0; i < (command & 0x1f); i++) {
+ reg = start_reg + (4 * i);
+ if (!si_vm_reg_valid(reg)) {
+ DRM_ERROR("CP DMA Bad DST
register\n");
+ return -EINVAL;
+ }
+ }
+ }
+ }
+ }
+ return 0;
+}
+
static int si_vm_packet3_gfx_check(struct radeon_device *rdev,
u32 *ib, struct radeon_cs_packet *pkt)
{
+ int r;
u32 idx = pkt->idx + 1;
u32 idx_value = ib[idx];
u32 start_reg, end_reg, reg, i;
- u32 command, info;
switch (pkt->opcode) {
case PACKET3_NOP:
@@ -4190,50 +4241,9 @@ static int si_vm_packet3_gfx_check(struct radeon_device
*rdev,
}
break;
case PACKET3_CP_DMA:
- command = ib[idx + 4];
- info = ib[idx + 1];
- if (command & PACKET3_CP_DMA_CMD_SAS) {
- /* src address space is register */
- if (((info & 0x6000) >> 29) == 0) {
- start_reg = idx_value << 2;
- if (command & PACKET3_CP_DMA_CMD_SAIC) {
- reg = start_reg;
- if (!si_vm_reg_valid(reg)) {
- DRM_ERROR("CP DMA Bad SRC
register\n");
- return -EINVAL;
- }
- } else {
-
[Bug 67981] Graphical Glitches with RV200 on IBM Thinkpad T40
https://bugs.freedesktop.org/show_bug.cgi?id=67981 --- Comment #11 from Stefan Schmidt --- Okay, I played a little around with window managers. Mutter also has graphical glitches (a little different ones though), Compiz doesn't work at all, Xfce and Fluxbox work and If I replace elementary's window manager gala with xfwm4 then as far as I can see the severe glitches disappear with only minor glitches remaining. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/d9045f87/attachment.html>
[PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute v2
On Fri, Aug 16, 2013 at 03:34:09PM -0700, Greg KH wrote: > On Fri, Aug 16, 2013 at 05:47:39PM -0400, Tom Stellard wrote: > > From: Tom Stellard > > > > Also add a new RADEON_INFO query to check that CP DMA packets are > > supported on the compute ring. > > > > v2: > > - Don't bump kms version, so this patch can be backported to stable > > kernels. > > Why is this for a stable kernel? What reported problem does it fix? > CP DMA has been supported since the 3.8 kernel, but due to an oversight we forgot to teach the CS checker that the CP DMA packet was legal for the compute ring on Southern Islands GPUs. This patch fixes a bug where the radeon driver will incorrectly reject a legal CP DMA packet from user space. I would like to have the patch backported to stable so that we don't have to require Mesa users to use a bleeding edge kernel in order to take advantage of this feature which is already present in the stable kernels (3.8 and newer). -Tom
nouveau: temperature on nv40 is unavailable since ad40d73ef533ab0ad16b4a1ab2f7870c1f8ab954
contains temperature. Both nouveau and nvidia driver when show different temperature it does not show different output from "nvapeek 0x15b0". Now I started computer with nouveau driver. Temperature is incresing, but nvapeek 0x15b0 is still same. So do you really needs other tests with nvapeek 0x15b0? Is that register correct? > > I wait some some and started nvidia-smi and nvapeek again, here > > are results: > > > > $ nvidia-smi -q -d TEMPERATURE > > ... > > GPU :05:00.0 > > > > Temperature > > > > Gpu : 67 C > > > > $ nvapeek 0x15b0 > > 15b0: 108e > > > > So it looks like that nvapeek returning always same value and > > does not depends on temperature... It is OK? > > Well, it looks like the temperature reading is very noisy! > Could you please get the temperature + peek when the card is as hot as > possible? > > There is a very effective solution to get a GPU hot, use a hair drier. > If you could get your > GPU to at 110?C (or less, if you feel like it is too much), that could > help me check the formula > and default values. > > PS: I attached a new version of the patch that should improve the > temperature accuracy for > nv43s. Could you test it and send me your kernel log? -- Pali Roh?r pali.rohar at gmail.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/47e65ef5/attachment-0001.pgp>
[PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute v2
On Fri, Aug 16, 2013 at 05:47:39PM -0400, Tom Stellard wrote: > From: Tom Stellard > > Also add a new RADEON_INFO query to check that CP DMA packets are > supported on the compute ring. > > v2: > - Don't bump kms version, so this patch can be backported to stable > kernels. Why is this for a stable kernel? What reported problem does it fix? thanks, greg k-h
[PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774
On Thursday 15 August 2013 18:23:06 Martin Peres wrote: > On 15/08/2013 13:46, Pali Roh?r wrote: > > On Tuesday 13 August 2013 11:28:01 Pali Roh?r wrote: > >> Hello, > >> > >> in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was > >> introduced error which cause that on my Nvidia 6600GT card > >> reclocking not working anymore. There is missing assigment of > >> return value from pll_calc to ret. > >> > >> After this patch reclocking on my card working fine again. > >> Above broken commit was introduced in kernel 3.7, so consider > >> backporting this patch to older kernels too. > >> > >> Signed-off-by: Pali Roh?r > >> > >> diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c > >> b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d > >> 100644 > >> --- a/drivers/gpu/drm/nouveau/nv40_pm.c > >> +++ b/drivers/gpu/drm/nouveau/nv40_pm.c > >> @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 > >> reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq) > >> > >>pll->vco2.max_freq = 0; > >> > >> - pclk->pll_calc(pclk, pll, clk, &coef); > >> + ret = pclk->pll_calc(pclk, pll, clk, &coef); > >> > >>if (ret == 0) > >> > >>return -ERANGE; > > > > Martin, can you look at another problem with my graphics card? > > As I told you before, I'm away from my computers, so I cannot test the > patch. However, > this one seems quite obvious and should be pushed. Thanks. Yes, look at that diff of that problematic commit and you will see that ret here is missing. It is possible to push this patch to 3.11? -- Pali Roh?r pali.rohar at gmail.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130816/92a4a693/attachment-0001.pgp>
[PATCH] nouveau reclocking on nv40 not working since 77145f1cbdf8d28b46ff8070ca749bad821e0774
On 16/08/2013 03:16, Pali Roh?r wrote: > On Thursday 15 August 2013 18:23:06 Martin Peres wrote: >> On 15/08/2013 13:46, Pali Roh?r wrote: >>> On Tuesday 13 August 2013 11:28:01 Pali Roh?r wrote: Hello, in commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced error which cause that on my Nvidia 6600GT card reclocking not working anymore. There is missing assigment of return value from pll_calc to ret. After this patch reclocking on my card working fine again. Above broken commit was introduced in kernel 3.7, so consider backporting this patch to older kernels too. Signed-off-by: Pali Roh?r diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d 100644 --- a/drivers/gpu/drm/nouveau/nv40_pm.c +++ b/drivers/gpu/drm/nouveau/nv40_pm.c @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq) pll->vco2.max_freq = 0; - pclk->pll_calc(pclk, pll, clk, &coef); + ret = pclk->pll_calc(pclk, pll, clk, &coef); if (ret == 0) return -ERANGE; >>> Martin, can you look at another problem with my graphics card? >> As I told you before, I'm away from my computers, so I cannot test the >> patch. However, >> this one seems quite obvious and should be pushed. Thanks. > Yes, look at that diff of that problematic commit and you will see that ret > here is missing. It is possible to push this patch to 3.11? Please make a proper patch (generated by git format-patch or git send-email) and Ben will push it. You add my Signed-off-by: Martin Peres Cheers
[PATCH] nouveau: fix reclocking on nv40
In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced error which cause that reclocking on nv40 not working anymore. There is missing assigment of return value from pll_calc to ret. Signed-off-by: Pali Roh?r Signed-off-by: Martin Peres --- drivers/gpu/drm/nouveau/nv40_pm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d 100644 --- a/drivers/gpu/drm/nouveau/nv40_pm.c +++ b/drivers/gpu/drm/nouveau/nv40_pm.c @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct nvbios_pll *pll, if (clk < pll->vco1.max_freq) pll->vco2.max_freq = 0; - pclk->pll_calc(pclk, pll, clk, &coef); + ret = pclk->pll_calc(pclk, pll, clk, &coef); if (ret == 0) return -ERANGE; -- 1.7.10.4
Moving a bug upstream per downstream request, emailing the maintainers
On 8/16/2013 3:43 AM, Chris Wilson wrote: > On Thu, Aug 15, 2013 at 03:28:53PM -0400, John Hupp wrote: >> [1.] One line summary of the problem: >> Flash 11.2 content displays in shades of green and purple only, and >> in a horizontally compressed space >> >> [2.] Full description of the problem/report: >> The full downstream bug report is at >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1212455 , but >> my description from there: >> >> In my testing with the Intel driver using its default acceleration: >> - Flash 11.2 works on Quantal with the 3.5 kernel >> - Flash 11.2 works on Raring with the 3.5.0-17 kernel (though it >> boots to a low-res desktop with a frozen pointer) >> - Flash 11.2 works on Raring also with the 3.6.11-030611 or >> 3.7.10-030710 mainline kernels >> - Flash 11.8 works on Raring with the 3.8 kernel (in Chrome) >> - Flash 11.2 fails on Raring with the 3.8 kernel >> - Flash 11.2 fails on Raring with the latest mainline kernel, >> 3.11.0-031100rc5 >> - Flash 11.2 fails on Saucy alpha 2 with its default kernel > It's a flash bug. They ignore the format of the Window that they > PutImage to. (Worse, they create an image of the right depth or else X > would reject the PutImage with a BadMatch and then render incorrect > pixel data into it.) > -Chris > OK, thanks for identifying the problem.
[PATCH] drm/radeon/si: Add support for CP DMA to CS checker for compute v2
On Fri, Aug 16, 2013 at 05:31:39PM -0700, Tom Stellard wrote: > On Fri, Aug 16, 2013 at 03:34:09PM -0700, Greg KH wrote: > > On Fri, Aug 16, 2013 at 05:47:39PM -0400, Tom Stellard wrote: > > > From: Tom Stellard > > > > > > Also add a new RADEON_INFO query to check that CP DMA packets are > > > supported on the compute ring. > > > > > > v2: > > > - Don't bump kms version, so this patch can be backported to stable > > > kernels. > > > > Why is this for a stable kernel? What reported problem does it fix? > > > > CP DMA has been supported since the 3.8 kernel, but due to an oversight > we forgot to teach the CS checker that the CP DMA packet was legal for > the compute ring on Southern Islands GPUs. > > This patch fixes a bug where the radeon driver will incorrectly reject a legal > CP DMA packet from user space. I would like to have the patch > backported to stable so that we don't have to require Mesa users to use a > bleeding edge kernel in order to take advantage of this feature which > is already present in the stable kernels (3.8 and newer). Then please put that in the changelog section of the patch, otherwise people (like me), will ask these types of things :) thanks, greg k-h
