search for: reservation_object_wait_timeout_rcu

https://bugs.freedesktop.org/show_bug.cgi?id=93267 Bug ID: 93267 Summary: BUG: unable to handle kernel paging request in reservation_object_wait_timeout_rcu Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau Assignee: nouveau at lists.freedesktop.org...

...07,9 +107,12 @@ static int radeon_gem_set_domain(struct drm_gem_object *gobj, } if (domain == RADEON_GEM_DOMAIN_CPU) { /* Asking for cpu access wait for object idle */ - r = radeon_bo_wait(robj, NULL, false); - if (r) { - printk(KERN_ERR "Failed to wait for object !\n"); + r = reservation_object_wait_timeout_rcu(robj->tbo.resv, true, true, 30 * HZ); + if (!r) + r = -EBUSY; + + if (r < 0 && r != -EINTR) { + printk(KERN_ERR "Failed to wait for object: %i\n", r); return r; } } @@ -357,14 +360,20 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void *data, stru...

...rm/nouveau/nouveau_gem.c index b1e4852810ed..c7368aa0bdec 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -887,7 +887,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void *data, return -ENOENT; nvbo = nouveau_gem_object(gem); - lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true, + lret = reservation_object_wait_timeout_rcu(nvbo->bo.base.resv, write, true, no_wait ? 0 : 30 * HZ); if (!lret) ret = -EBUSY; -- 2.18.1

...rm/nouveau/nouveau_gem.c index b1e4852810ed..c7368aa0bdec 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -887,7 +887,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void *data, return -ENOENT; nvbo = nouveau_gem_object(gem); - lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true, + lret = reservation_object_wait_timeout_rcu(nvbo->bo.base.resv, write, true, no_wait ? 0 : 30 * HZ); if (!lret) ret = -EBUSY; -- 2.18.1

...rm/nouveau/nouveau_gem.c index b1e4852810ed..c7368aa0bdec 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -887,7 +887,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void *data, return -ENOENT; nvbo = nouveau_gem_object(gem); - lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true, + lret = reservation_object_wait_timeout_rcu(nvbo->bo.base.resv, write, true, no_wait ? 0 : 30 * HZ); if (!lret) ret = -EBUSY; -- 2.18.1

...rm/nouveau/nouveau_gem.c index b1e4852810ed..c7368aa0bdec 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -887,7 +887,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void *data, return -ENOENT; nvbo = nouveau_gem_object(gem); - lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true, + lret = reservation_object_wait_timeout_rcu(nvbo->bo.base.resv, write, true, no_wait ? 0 : 30 * HZ); if (!lret) ret = -EBUSY; -- 2.18.1

...rm/nouveau/nouveau_gem.c index b1e4852810ed..c7368aa0bdec 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -887,7 +887,7 @@ nouveau_gem_ioctl_cpu_prep(struct drm_device *dev, void *data, return -ENOENT; nvbo = nouveau_gem_object(gem); - lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true, + lret = reservation_object_wait_timeout_rcu(nvbo->bo.base.resv, write, true, no_wait ? 0 : 30 * HZ); if (!lret) ret = -EBUSY; diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c b/drivers/gpu/drm/nouveau/nouveau_prime.c index 0750caf86e12..b4b06ad3...

...m_map+0x56/0x80 [nouveau] [410260.351678] nvkm_uvmm_mthd+0x66a/0x780 [nouveau] [410260.351678] nvkm_ioctl+0xde/0x180 [nouveau] [410260.351678] nvif_object_mthd+0x104/0x130 [nouveau] [410260.351678] ? dma_fence_free+0x20/0x20 [410260.351678] nvif_vmm_map+0x115/0x130 [nouveau] [410260.351678] ? reservation_object_wait_timeout_rcu+0x159/0x2d0 [410260.351678] nouveau_mem_map+0x8d/0xf0 [nouveau] [410260.351678] nouveau_vma_map+0x44/0x70 [nouveau] [410260.351678] nouveau_bo_move_ntfy+0xc1/0xe0 [nouveau] [410260.351678] ttm_bo_handle_move_mem+0x3a1/0x4f0 [ttm] [410260.351678] ttm_bo_evict+0x150/0x1d0 [ttm] [410260.351678]...

...M] > (rev a1). > > I don't have the expertise to fully assess the suspect commit. Any thoughts as > to the root cause of this problem? Is there any other information I can > provide? This line of nouveau_gem_ioctl_cpu_prep() seems to match a 30-seconds timeout: lret = reservation_object_wait_timeout_rcu(nvbo->bo.resv, write, true, 30 * HZ); Without the commit you mentioned, and with CONFIG_DEBUG_SHIRQ enabled, do you also see this error? Is it absolutely reproducable? Also, can you give more details about the X configuration? (display driver, PRIME configuration, how the NVIDIA GPU is used by...

..._buffer_object *bo, ret = ttm_bo_wait(bo, false, false, true); if (ret && !no_wait_gpu) { - ret = ttm_bo_unreserve_and_wait(bo, interruptible); - if (ret) - return ret; + long lret; + ww_mutex_unlock(&bo->resv->lock); + spin_unlock(&glob->lru_lock); + + lret = reservation_object_wait_timeout_rcu(bo->resv, + true, + interruptible, + 30 * HZ); + + if (lret < 0) + return lret; + else if (lret == 0) + return -EBUSY; spin_lock(&glob->lru_lock); ret = __ttm_bo_reserve(bo, false, true, false, 0);

...(!ret) { - ret = ttm_bo_wait(bo, false, true, - !!(flags & drm_vmw_synccpu_dontblock)); - ttm_bo_unreserve(bo); - } - return ret; + long lret; + if (flags & drm_vmw_synccpu_dontblock) + return reservation_object_test_signaled_rcu(bo->resv, true) ? 0 : -EBUSY; + + lret = reservation_object_wait_timeout_rcu(bo->resv, true, true, MAX_SCHEDULE_TIMEOUT); + if (!lret) + return -EBUSY; + else if (lret < 0) + return lret; + return 0; } ret = ttm_bo_synccpu_write_grab

...gt; non-interrupt. > > Sounds mostly reasonable, but for holding the dma-buf ww_mutex, wouldn't be an RCU be more appropriate here? E.g. aren't we just interested that the current assigned fence at some point is signaled? You can wait with RCU, without holding the ww_mutex, by calling reservation_object_wait_timeout_rcu on ttm_bo->resv. If you don't want to block you could test with reservation_object_test_signaled_rcu. Or if you want a copy of all fences without taking locks, try reservation_object_get_fences_rcu. (Might be out of date by the time the function returns if you don't hold ww_mutex, if you...

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

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

https://bugs.freedesktop.org/show_bug.cgi?id=87819 Bug ID: 87819 Summary: [NVAC] EQ overflowing Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

Am 22.07.2014 17:42, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 5:35 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >> Drivers exporting fences need to provide a fence->signaled and a fence->wait >> function, everything else like fence->enable_signaling or calling >> fence_signaled() from the driver is optional. >> >> Drivers

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

Hello, I am encountering a 30 second hang during boot, in the Xorg process just before the display manager comes up. I have bisected the problem to the following commit: commit 2b700825e7a7702fb862edba1262c98040dc1bf6 Author: Ben Skeggs <bskeggs at redhat.com> Date: Thu Aug 20 14:54:22 2015 +1000 drm/nouveau/mc: move device irq handling to platform-specific code The hang only