dri-devel October 2013

dri-devel@lists.freedesktop.org

171 participants
926 discussions

[Bug 70035] GPU Lockup on AMD RS880 HD4200
by bugzilla-daemon＠freedesktop.org 09 Oct '13

09 Oct '13

https://bugs.freedesktop.org/show_bug.cgi?id=70035 --- Comment #14 from Tasev <tasev.stefanoska(a)skynet.be> --- Created attachment 87338 --> https://bugs.freedesktop.org/attachment.cgi?id=87338&action=edit dmesg-3.12rc4.txt The lockup occurs at the 34 seconds of the boot process -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 70035] GPU Lockup on AMD RS880 HD4200
by bugzilla-daemon＠freedesktop.org 09 Oct '13

09 Oct '13

https://bugs.freedesktop.org/show_bug.cgi?id=70035 Tasev <tasev.stefanoska(a)skynet.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|DUPLICATE |--- --- Comment #13 from Tasev <tasev.stefanoska(a)skynet.be> --- Hi, I was just lucky yesterday. Today during boot the gpu lockup once again for 10 seconds, after that the boot goes normaly. The dmesg is attached. I update again the system now to version 9.3~git1310080951.20bf50+glvdpau~gd~p from the oibaf ppa. I use the system normaly for 15 minutes now. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE
by Peter Zijlstra 09 Oct '13

09 Oct '13

Hi Dave, So I'm poking around the preemption code and stumbled upon: drivers/gpu/drm/i915/i915_gem.c: set_need_resched(); drivers/gpu/drm/ttm/ttm_bo_vm.c: set_need_resched(); drivers/gpu/drm/ttm/ttm_bo_vm.c: set_need_resched(); drivers/gpu/drm/udl/udl_gem.c: set_need_resched(); All these sites basically do: while (!trylock()) yield(); which is a horrible and broken locking pattern. Firstly its deadlock prone, suppose the faulting process is a FIFOn+1 task that preempted the lock holder at FIFOn. Secondly the implementation is worse than usual by abusing VM_FAULT_NOPAGE, which is supposed to install a PTE so that the fault doesn't retry, but you're using it as a get out of fault path. And you're using set_need_resched() which is not something a driver should _ever_ touch. Now I'm going to take away set_need_resched() -- and while you can 'reimplement' it using set_thread_flag() you're not going to do that because it will be broken due to changes to the preempt code. So please as to fix ASAP and don't allow anybody to trick you into merging silly things like that again ;-)

10 58

[PATCH] drm: Fix typo in debug message
by Thierry Reding 09 Oct '13

09 Oct '13

Fix a typo (iotcl -> ioctl) in the debug message when an unknown IOCTL is encountered. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/gpu/drm/drm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index e79d8d9..e8737c0 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -467,7 +467,7 @@ long drm_ioctl(struct file *filp, err_i1: if (!ioctl) - DRM_DEBUG("invalid iotcl: pid=%d, dev=0x%lx, auth=%d, cmd=0x%02x, nr=0x%02x\n", + DRM_DEBUG("invalid ioctl: pid=%d, dev=0x%lx, auth=%d, cmd=0x%02x, nr=0x%02x\n", task_pid_nr(current), (long)old_encode_dev(file_priv->minor->device), file_priv->authenticated, cmd, nr); -- 1.8.4

1 0

[PATCH RFC] drm/ttm: Allow vm fault retries
by Thomas Hellstrom 09 Oct '13

09 Oct '13

Make use of the FAULT_FLAG_ALLOW_RETRY flag to allow dropping the mmap_sem while waiting for bo idle. FAULT_FLAG_ALLOW_RETRY appears to be primarily designed for disk waits but should work just as fine for GPU waits.. Only compile-tested so far pending comments. Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com> --- drivers/gpu/drm/ttm/ttm_bo_vm.c | 61 ++++++++++++++++++++++++++++++--------- 1 file changed, 48 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index 1006c15..6510ce2 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -41,6 +41,50 @@ #define TTM_BO_VM_NUM_PREFAULT 16 +static int ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo, + struct vm_area_struct *vma, + struct vm_fault *vmf) +{ + struct ttm_bo_device *bdev = bo->bdev; + int ret = 0; + + spin_lock(&bdev->fence_lock); + if (likely(!test_bit(TTM_BO_PRIV_FLAG_MOVING, &bo->priv_flags))) + goto out_unlock; + + /* + * Quick non-stalling check for idle. + */ + ret = ttm_bo_wait(bo, false, false, true); + if (likely(ret == 0)) + goto out_unlock; + + /* + * If possible, avoid waiting for GPU with mmap_sem + * held. + */ + if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) { + ret = VM_FAULT_RETRY; + if (vmf->flags & FAULT_FLAG_RETRY_NOWAIT) + goto out_unlock; + + up_read(&vma->vm_mm->mmap_sem); + (void) ttm_bo_wait(bo, false, true, false); + goto out_unlock; + } + + /* + * Ordinary wait. + */ + ret = ttm_bo_wait(bo, false, true, false); + if (unlikely(ret != 0)) + ret = (ret == -ERESTARTSYS) ? VM_FAULT_SIGBUS : + VM_FAULT_NOPAGE; +out_unlock: + spin_unlock(&bdev->fence_lock); + return ret; +} + static int ttm_bo_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf) { struct ttm_buffer_object *bo = (struct ttm_buffer_object *) @@ -91,19 +135,10 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf) * Wait for buffer data in transit, due to a pipelined * move. */ - - spin_lock(&bdev->fence_lock); - if (test_bit(TTM_BO_PRIV_FLAG_MOVING, &bo->priv_flags)) { - ret = ttm_bo_wait(bo, false, true, false); - spin_unlock(&bdev->fence_lock); - if (unlikely(ret != 0)) { - retval = (ret != -ERESTARTSYS) ? - VM_FAULT_SIGBUS : VM_FAULT_NOPAGE; - goto out_unlock; - } - } else - spin_unlock(&bdev->fence_lock); - + retval = ttm_bo_vm_fault_idle(bo, vma, vmf); + if (unlikely(retval != 0)) + goto out_unlock; + ret = ttm_mem_io_lock(man, true); if (unlikely(ret != 0)) { retval = VM_FAULT_NOPAGE; -- 1.7.10.4

1 0

[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
by bugzilla-daemon＠freedesktop.org 09 Oct '13

09 Oct '13

https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #14 from Michel Dänzer <michel(a)daenzer.net> --- (In reply to comment #11) > The root of the problem *isn't* glamor: I just tried Glamor with Intel > HD4000 and it works flawlessly. The issue is with mesa. Could also be the glamor glue code in xf86-video-ati. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 69341] [radeonsi] KDE 4.11 is EXTREMELY slow with Raster QT backend
by bugzilla-daemon＠freedesktop.org 09 Oct '13

09 Oct '13

https://bugs.freedesktop.org/show_bug.cgi?id=69341 --- Comment #13 from Michel Dänzer <michel(a)daenzer.net> --- (In reply to comment #12) > I noticed something weird: if I start KDE with desktop effects off it is > *much* faster and there is corruption in the title bar. The corruption indicates it's using the native Qt backend, not Raster. > Also I noticed it is much faster when I set resolution to 1920x1200 compared > to 2560x1600, at least when starting KDE with desktop effects off. 2560x1600 is almost twice as many pixels as 1920x1200, so some difference in performance between them is expected. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] drm/i915: check gem bo size when creating framebuffers
by Daniel Vetter 09 Oct '13

09 Oct '13

It's better to catch such fallout early, and this way we can rely on the checking done by the drm core on fb->heigh/width at modeset time. If we ever support planar formats on intel we might want to look into a common helper to do all this, but for now this is good enough. Requested-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/i915/intel_display.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f5126b8..3073154 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -10069,6 +10069,10 @@ int intel_framebuffer_init(struct drm_device *dev, if (mode_cmd->offsets[0] != 0) return -EINVAL; + /* FIXME drm helper for size checks (especially planar formats)? */ + if (obj->base.size < mode_cmd->height * mode_cmd->pitches[0]) + return -EINVAL; + drm_helper_mode_fill_fb_struct(&intel_fb->base, mode_cmd); intel_fb->obj = obj; -- 1.8.4.rc3

2 1

[Bug 69961] New: Regression: Xserver fails to start
by bugzilla-daemon＠freedesktop.org 09 Oct '13

09 Oct '13

https://bugs.freedesktop.org/show_bug.cgi?id=69961 Priority: medium Bug ID: 69961 Assignee: dri-devel(a)lists.freedesktop.org Summary: Regression: Xserver fails to start Severity: critical Classification: Unclassified OS: All Reporter: hysvats(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 86844 --> https://bugs.freedesktop.org/attachment.cgi?id=86844&action=edit xorg.log Driver Stack Details: ===================== 1) Kernel-3.10.5-031005-generic 2) drm-2.4.46 3) Mesa-9.2 4) Xorg-server-1.11.4 5) xf86-video-ati- master 6) glamor-0.5.1/0.5.0 7) LLVM-3.3 System Configuration: ===================== Asic : CapeVerde XT (ID-683D) O.S. : Ubuntu-13.04 (64 bit) Details: ======== 1) The Xserver start fine with driver build before 28th september commit. 2) X server crashes with Backtrace with git master : (==) Using system config directory "/usr/share/X11/xorg.conf.d" (II) [KMS] Kernel modesetting enabled. /usr/bin/X: symbol lookup error: /home/atitest/install/lib/xorg/modules/drivers/radeon_drv.so: undefined symbol: glamor_xv_init xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error -- You are receiving this mail because: You are the assignee for the bug.

1 8

[PATCH 0/2] A couple of vmwgfx fixes
by Thomas Hellstrom 09 Oct '13

09 Oct '13

The log messages speak for themselves

1 2

← Newer
1
...
80
81
82
83
84
85
86
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2013