dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

Linux Graphics Next: Userspace submission update
by Marek Olšák 17 Jun '21

17 Jun '21

Hi, Since Christian believes that we can't deadlock the kernel with some changes there, we just need to make everything nice for userspace too. Instead of explaining how it will work, I will explain the cases where future hardware (and its kernel driver) will break existing userspace in order to protect everybody from deadlocks. Anything that uses implicit sync will be spared, so X and Wayland will be fine, assuming they don't import/export fences. Those use cases that do import/export fences might or might not work, depending on how the fences are used. One of the necessities is that all fences will become future fences. The semantics of imported/exported fences will change completely and will have new restrictions on the usage. The restrictions are: 1) Android sync files will be impossible to support, so won't be supported. (they don't allow future fences) 2) Implicit sync and explicit sync will be mutually exclusive between process. A process can either use one or the other, but not both. This is meant to prevent a deadlock condition with future fences where any process can malevolently deadlock execution of any other process, even execution of a higher-privileged process. The kernel will impose the following restrictions to protect against the deadlock: a) a process with an implicitly-sync'd imported/exported buffer can't import/export a fence from/to another process b) a process with an imported/exported fence can't import/export an implicitly-sync'd buffer from/to another process Alternative: A higher-privileged process could enforce both restrictions instead of the kernel to protect itself from the deadlock, but this would be a can of worms for existing userspace. It would be better if the kernel just broke unsafe userspace on future hw, just like sync files. If both implicit and explicit sync are allowed to occur simultaneously, sending a future fence that will never signal to any process will deadlock that process after it acquires the implicit sync lock, which is a sequence number that the process is required to write to memory and send an interrupt from the GPU in a finite time. This is how the deadlock can happen: * The process gets sequence number N from the kernel for an implicitly-sync'd buffer. * The process inserts (into the GPU user-mapped queue) a wait for sequence number N-1. * The process inserts a wait for a fence, but it doesn't know that it will never signal ==> deadlock. ... * The process inserts a command to write sequence number N to a predetermined memory location. (which will make the buffer idle and send an interrupt to the kernel) ... * The kernel will terminate the process because it has never received the interrupt. (i.e. a less-privileged process just killed a more-privileged process) It's the interrupt for implicit sync that never arrived that caused the termination, and the only way another process can cause it is by sending a fence that will never signal. Thus, importing/exporting fences from/to other processes can't be allowed simultaneously with implicit sync. 3) Compositors (and other privileged processes, and display flipping) can't trust imported/exported fences. They need a timeout recovery mechanism from the beginning, and the following are some possible solutions to timeouts: a) use a CPU wait with a small absolute timeout, and display the previous content on timeout b) use a GPU wait with a small absolute timeout, and conditional rendering will choose between the latest content (if signalled) and previous content (if timed out) The result would be that the desktop can run close to 60 fps even if an app runs at 1 fps. *Redefining imported/exported fences and breaking some users/OSs is the only way to have userspace GPU command submission, and the deadlock example here is the counterexample proving that there is no other way.* So, what are the chances this is going to fly with the ecosystem? Thanks, Marek

5 49

vc4_bo_create: Failed to allocate from CMA
by Stefan Wahren 17 Jun '21

17 Jun '21

Hi, while testing the mainline kernel (arm64, defconfig) on Raspberry Pi 3 B Plus with Raspberry Pi OS - 64 bit, sometimes X doesn't start into desktop properly (unexpected and unusable login screen instead of auto login or mouse pointer is show shorty and than switch back to black screen in a loop). In that case dmesg shows the following: [ 74.737106] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA: [ 74.737558] vc4-drm soc:gpu: [drm] V3D: 28976kb BOs (10) [ 74.737602] vc4-drm soc:gpu: [drm] V3D shader: 44kb BOs (11) [ 74.737632] vc4-drm soc:gpu: [drm] dumb: 4564kb BOs (5) [ 74.737664] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1) [ 74.737697] vc4-drm soc:gpu: [drm] total purged BO: 4kb BOs (1) [ 74.739039] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA: [ 74.739466] vc4-drm soc:gpu: [drm] V3D: 28972kb BOs (9) [ 74.739512] vc4-drm soc:gpu: [drm] V3D shader: 44kb BOs (11) [ 74.739541] vc4-drm soc:gpu: [drm] dumb: 4564kb BOs (5) [ 74.739570] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1) [ 74.739602] vc4-drm soc:gpu: [drm] total purged BO: 4kb BOs (1) [ 74.740718] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA: [ 74.741138] vc4-drm soc:gpu: [drm] V3D: 28972kb BOs (9) [ 74.741171] vc4-drm soc:gpu: [drm] V3D shader: 44kb BOs (11) [ 74.741202] vc4-drm soc:gpu: [drm] dumb: 4564kb BOs (5) [ 74.741231] vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1) [ 74.741263] vc4-drm soc:gpu: [drm] total purged BO: 4kb BOs (1) ... I have only seen this issue on arm64 with latest mainline kernel (5.13.0-rc5-00130-gf21b807c3cf8), but also with older kernel versions. So it's not a regression. It seems 64 bit needs more CMA. In case X started properly i was also able to reproduce these errors above by dis- and reconneting HDMI. So i increased CMA in bcm283x.dtsi and the problem disappeared: iff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi index b83a864..d1304cb 100644 --- a/arch/arm/boot/dts/bcm283x.dtsi +++ b/arch/arm/boot/dts/bcm283x.dtsi @@ -37,7 +37,7 @@ cma: linux,cma { compatible = "shared-dma-pool"; - size = <0x4000000>; /* 64MB */ + size = <0x6000000>; /* 96MB */ reusable; linux,cma-default; }; The questions are: Is this the right way (tm) to fix this problem? And what is a sensible value (don't have a 4K display to test)? Best regards Stefan

3 3

[PATCH] drm/i915/gt: Fix duplicate included intel_region_lmem.h
by Jiapeng Chong 17 Jun '21

17 Jun '21

Clean up the following includecheck warning: ./drivers/gpu/drm/i915/gt/intel_region_lmem.c: intel_region_lmem.h is included more than once. No functional change. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c b/drivers/gpu/drm/i915/gt/intel_region_lmem.c index f7366b0..aa3cfca 100644 --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c @@ -5,7 +5,6 @@ #include "i915_drv.h" #include "intel_memory_region.h" -#include "intel_region_lmem.h" #include "intel_region_ttm.h" #include "gem/i915_gem_lmem.h" #include "gem/i915_gem_region.h" -- 1.8.3.1

2 1

[PATCH -next] apply: use DEFINE_SPINLOCK() instead of spin_lock_init().
by Yu Jiahua 17 Jun '21

17 Jun '21

From: Jiahua Yu <yujiahua1(a)huawei.com> spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Signed-off-by: Jiahua Yu <yujiahua1(a)huawei.com> --- drivers/video/fbdev/omap2/omapfb/dss/apply.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/dss/apply.c b/drivers/video/fbdev/omap2/omapfb/dss/apply.c index c71021091828..acca991c7540 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/apply.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/apply.c @@ -108,7 +108,7 @@ static struct { } dss_data; /* protects dss_data */ -static spinlock_t data_lock; +static DEFINE_SPINLOCK(data_lock); /* lock for blocking functions */ static DEFINE_MUTEX(apply_lock); static DECLARE_COMPLETION(extra_updated_completion); @@ -131,8 +131,6 @@ static void apply_init_priv(void) struct mgr_priv_data *mp; int i; - spin_lock_init(&data_lock); - for (i = 0; i < num_ovls; ++i) { struct ovl_priv_data *op; -- 2.17.1

2 1

[PATCH] drm/i915: Remove duplicate include of intel_region_lmem.h
by Wan Jiabing 17 Jun '21

17 Jun '21

Fix the following checkinclude.pl warning: drivers/gpu/drm/i915/gt/intel_region_lmem.c 8 #include "intel_region_lmem.h" 12 #include "intel_region_lmem.h" Signed-off-by: Wan Jiabing <wanjiabing(a)vivo.com> --- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c b/drivers/gpu/drm/i915/gt/intel_region_lmem.c index f7366b054f8e..119eeec98837 100644 --- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c +++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c @@ -9,7 +9,6 @@ #include "intel_region_ttm.h" #include "gem/i915_gem_lmem.h" #include "gem/i915_gem_region.h" -#include "intel_region_lmem.h" static int init_fake_lmem_bar(struct intel_memory_region *mem) { -- 2.20.1

2 1

[PATCH] dma-buf: fix and rework dma_buf_poll
by Christian König 17 Jun '21

17 Jun '21

Daniel pointed me towards this function and there are multiple obvious problems in the implementation. First of all the retry loop is not working as intended. In general the retry makes only sense if you grab the reference first and then check the retry. Then we skipped checking the exclusive fence when shared fences were present. And last the whole implementation was unnecessary complex and rather hard to understand which could lead to probably unexpected behavior of the IOCTL. Fix all this by reworking the implementation from scratch. Only mildly tested and needs a thoughtful review of the code. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-buf.c | 132 +++++++++++++++----------------------- include/linux/dma-buf.h | 2 +- 2 files changed, 54 insertions(+), 80 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 511fe0d217a0..1bd00e18291f 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -72,7 +72,7 @@ static void dma_buf_release(struct dentry *dentry) * If you hit this BUG() it means someone dropped their ref to the * dma-buf while still having pending operation to the buffer. */ - BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active); + BUG_ON(dmabuf->cb_in.active || dmabuf->cb_out.active); dmabuf->ops->release(dmabuf); @@ -206,12 +206,15 @@ static void dma_buf_poll_cb(struct dma_fence *fence, struct dma_fence_cb *cb) static __poll_t dma_buf_poll(struct file *file, poll_table *poll) { + struct dma_buf_poll_cb_t *dcb; struct dma_buf *dmabuf; struct dma_resv *resv; struct dma_resv_list *fobj; struct dma_fence *fence_excl; - __poll_t events; unsigned shared_count, seq; + struct dma_fence *fence; + __poll_t events; + int r, i; dmabuf = file->private_data; if (!dmabuf || !dmabuf->resv) @@ -225,99 +228,70 @@ static __poll_t dma_buf_poll(struct file *file, poll_table *poll) if (!events) return 0; + dcb = events & EPOLLOUT ? &dmabuf->cb_out : &dmabuf->cb_in; + + /* Only queue a new one if we are not still waiting for the old one */ + spin_lock_irq(&dmabuf->poll.lock); + if (dcb->active) + events = 0; + else + dcb->active = events; + spin_unlock_irq(&dmabuf->poll.lock); + if (!events) + return 0; + retry: seq = read_seqcount_begin(&resv->seq); rcu_read_lock(); fobj = rcu_dereference(resv->fence); - if (fobj) + if (fobj && events & EPOLLOUT) shared_count = fobj->shared_count; else shared_count = 0; - fence_excl = dma_resv_excl_fence(resv); - if (read_seqcount_retry(&resv->seq, seq)) { - rcu_read_unlock(); - goto retry; - } - if (fence_excl && (!(events & EPOLLOUT) || shared_count == 0)) { - struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl; - __poll_t pevents = EPOLLIN; - - if (shared_count == 0) - pevents |= EPOLLOUT; - - spin_lock_irq(&dmabuf->poll.lock); - if (dcb->active) { - dcb->active |= pevents; - events &= ~pevents; - } else - dcb->active = pevents; - spin_unlock_irq(&dmabuf->poll.lock); - - if (events & pevents) { - if (!dma_fence_get_rcu(fence_excl)) { - /* force a recheck */ - events &= ~pevents; - dma_buf_poll_cb(NULL, &dcb->cb); - } else if (!dma_fence_add_callback(fence_excl, &dcb->cb, - dma_buf_poll_cb)) { - events &= ~pevents; - dma_fence_put(fence_excl); - } else { - /* - * No callback queued, wake up any additional - * waiters. - */ - dma_fence_put(fence_excl); - dma_buf_poll_cb(NULL, &dcb->cb); - } + for (i = 0; i < shared_count; ++i) { + fence = rcu_dereference(fobj->shared[i]); + fence = dma_fence_get_rcu(fence); + if (!fence || read_seqcount_retry(&resv->seq, seq)) { + /* Concurrent modify detected, force re-check */ + dma_fence_put(fence); + rcu_read_unlock(); + goto retry; } - } - if ((events & EPOLLOUT) && shared_count > 0) { - struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_shared; - int i; - - /* Only queue a new callback if no event has fired yet */ - spin_lock_irq(&dmabuf->poll.lock); - if (dcb->active) - events &= ~EPOLLOUT; - else - dcb->active = EPOLLOUT; - spin_unlock_irq(&dmabuf->poll.lock); - - if (!(events & EPOLLOUT)) + r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb); + dma_fence_put(fence); + if (!r) { + /* Callback queued */ + events = 0; goto out; + } + } - for (i = 0; i < shared_count; ++i) { - struct dma_fence *fence = rcu_dereference(fobj->shared[i]); - - if (!dma_fence_get_rcu(fence)) { - /* - * fence refcount dropped to zero, this means - * that fobj has been freed - * - * call dma_buf_poll_cb and force a recheck! - */ - events &= ~EPOLLOUT; - dma_buf_poll_cb(NULL, &dcb->cb); - break; - } - if (!dma_fence_add_callback(fence, &dcb->cb, - dma_buf_poll_cb)) { - dma_fence_put(fence); - events &= ~EPOLLOUT; - break; - } + fence = dma_resv_excl_fence(resv); + if (fence) { + fence = dma_fence_get_rcu(fence); + if (!fence || read_seqcount_retry(&resv->seq, seq)) { + /* Concurrent modify detected, force re-check */ dma_fence_put(fence); + rcu_read_unlock(); + goto retry; + } - /* No callback queued, wake up any additional waiters. */ - if (i == shared_count) - dma_buf_poll_cb(NULL, &dcb->cb); + r = dma_fence_add_callback(fence, &dcb->cb, dma_buf_poll_cb); + dma_fence_put(fence_excl); + if (!r) { + /* Callback queued */ + events = 0; + goto out; + } } + /* No callback queued, wake up any additional waiters. */ + dma_buf_poll_cb(NULL, &dcb->cb); + out: rcu_read_unlock(); return events; @@ -562,8 +536,8 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info) dmabuf->owner = exp_info->owner; spin_lock_init(&dmabuf->name_lock); init_waitqueue_head(&dmabuf->poll); - dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll; - dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0; + dmabuf->cb_in.poll = dmabuf->cb_out.poll = &dmabuf->poll; + dmabuf->cb_in.active = dmabuf->cb_out.active = 0; if (!resv) { resv = (struct dma_resv *)&dmabuf[1]; diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index efdc56b9d95f..7e747ad54c81 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -329,7 +329,7 @@ struct dma_buf { wait_queue_head_t *poll; __poll_t active; - } cb_excl, cb_shared; + } cb_in, cb_out; }; /** -- 2.25.1

3 3

[RFC PATCH 0/2] GuC submission / DRM scheduler integration plan + new uAPI
by Matthew Brost 17 Jun '21

17 Jun '21

Subject and patches say it all. v2: Address comments, patches have details of changes v3: Address comments, patches have details of changes Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Matthew Brost (2): drm/doc/rfc: i915 GuC submission / DRM scheduler drm/doc/rfc: i915 new parallel submission uAPI plan Documentation/gpu/rfc/i915_parallel_execbuf.h | 145 ++++++++++++++++++ Documentation/gpu/rfc/i915_scheduler.rst | 136 ++++++++++++++++ Documentation/gpu/rfc/index.rst | 4 + 3 files changed, 285 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst -- 2.28.0

4 11

[PATCH 1/5] dma-buf: fix dma_resv_test_signaled test_all handling
by Christian König 17 Jun '21

17 Jun '21

As the name implies if testing all fences is requested we should indeed test all fences and not skip the exclusive one because we see shared ones. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-resv.c | 33 ++++++++++++--------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index f26c71747d43..c66bfdde9454 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -615,25 +615,21 @@ static inline int dma_resv_test_signaled_single(struct dma_fence *passed_fence) */ bool dma_resv_test_signaled(struct dma_resv *obj, bool test_all) { - unsigned int seq, shared_count; + struct dma_fence *fence; + unsigned int seq; int ret; rcu_read_lock(); retry: ret = true; - shared_count = 0; seq = read_seqcount_begin(&obj->seq); if (test_all) { struct dma_resv_list *fobj = dma_resv_shared_list(obj); - unsigned int i; - - if (fobj) - shared_count = fobj->shared_count; + unsigned int i, shared_count; + shared_count = fobj ? fobj->shared_count : 0; for (i = 0; i < shared_count; ++i) { - struct dma_fence *fence; - fence = rcu_dereference(fobj->shared[i]); ret = dma_resv_test_signaled_single(fence); if (ret < 0) @@ -641,24 +637,19 @@ bool dma_resv_test_signaled(struct dma_resv *obj, bool test_all) else if (!ret) break; } - - if (read_seqcount_retry(&obj->seq, seq)) - goto retry; } - if (!shared_count) { - struct dma_fence *fence_excl = dma_resv_excl_fence(obj); - - if (fence_excl) { - ret = dma_resv_test_signaled_single(fence_excl); - if (ret < 0) - goto retry; + fence = dma_resv_excl_fence(obj); + if (fence) { + ret = dma_resv_test_signaled_single(fence); + if (ret < 0) + goto retry; - if (read_seqcount_retry(&obj->seq, seq)) - goto retry; - } } + if (read_seqcount_retry(&obj->seq, seq)) + goto retry; + rcu_read_unlock(); return ret; } -- 2.25.1

2 13

question about error handling in ttm_bo_handle_move_mem()
by Dan Carpenter 17 Jun '21

17 Jun '21

The new version of Firefox seems to trigger a refcounting bug in my nouveau driver. I tested a v4.15 kernel and that has the bug as well. It seems like the refcounting is off if ttm_bo_evict() fails. Dmesg at the end. I tried to see if I could spot anything off and I had a question about ttm_bo_handle_move_mem(). drivers/gpu/drm/ttm/ttm_bo.c 230 static int ttm_bo_handle_move_mem(struct ttm_buffer_object *bo, 231 struct ttm_resource *mem, bool evict, 232 struct ttm_operation_ctx *ctx, 233 struct ttm_place *hop) 234 { 235 struct ttm_bo_device *bdev = bo->bdev; 236 struct ttm_resource_manager *old_man = ttm_manager_type(bdev, bo->mem.mem_type); 237 struct ttm_resource_manager *new_man = ttm_manager_type(bdev, mem->mem_type); old_man and new_man are assigned here. 238 int ret; 239 240 ttm_bo_unmap_virtual(bo); 241 242 /* 243 * Create and bind a ttm if required. 244 */ 245 246 if (new_man->use_tt) { 247 /* Zero init the new TTM structure if the old location should 248 * have used one as well. 249 */ 250 ret = ttm_tt_create(bo, old_man->use_tt); 251 if (ret) 252 goto out_err; This "goto out_err;" is a no-op. Presumably that is intentional. I think if this create succeeds then the error handling is expected to clean it up? 253 254 if (mem->mem_type != TTM_PL_SYSTEM) { 255 ret = ttm_tt_populate(bo->bdev, bo->ttm, ctx); 256 if (ret) 257 goto out_err; 258 } 259 } 260 261 ret = bdev->driver->move(bo, evict, ctx, mem, hop); On my system ->move() is returning -EINVAL 262 if (ret) { 263 if (ret == -EMULTIHOP) 264 return ret; 265 goto out_err; 266 } 267 268 ctx->bytes_moved += bo->base.size; 269 return 0; 270 271 out_err: 272 new_man = ttm_manager_type(bdev, bo->mem.mem_type); This seems like a mistake. This sets new_man to the same value as old_man. I don't understand why it needs to be re-assigned at all though so maybe I'm missing something. 273 if (!new_man->use_tt) This test seems reversed. Unfortunately, making these changes doesn't fix my crashes and I'm still investigating. 274 ttm_bo_tt_destroy(bo); 275 276 return ret; 277 } regards, dan carpenter [ 159.893081] nouveau 0000:01:00.0: Direct firmware load for nouveau/nva8_fuc084 failed with error -2 [ 159.893089] nouveau 0000:01:00.0: Direct firmware load for nouveau/nva8_fuc084d failed with error -2 [ 159.893091] nouveau 0000:01:00.0: msvld: unable to load firmware data [ 159.893092] nouveau 0000:01:00.0: msvld: init failed, -19 [ 1945.479861] [TTM] Buffer eviction failed [ 1945.479883] ------------[ cut here ]------------ [ 1945.479886] refcount_t: underflow; use-after-free. [ 1945.479900] WARNING: CPU: 7 PID: 2528 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0 [ 1945.479914] Modules linked in: bnep(E) ctr(E) ccm(E) cpufreq_conservative(E) cpufreq_userspace(E) cpufreq_powersave(E) cpufreq_ondemand(E) tun(E) uinput(E) binfmt_misc(E) ath3k(E) btusb(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) jitterentropy_rng(E) drbg(E) ansi_cprng(E) ecdh_generic(E) ecc(E) intel_rapl_msr(E) intel_rapl_common(E) snd_hda_codec_realtek(E) x86_pkg_temp_thermal(E) snd_hda_codec_generic(E) ath9k(E) intel_powerclamp(E) ledtrig_audio(E) snd_hda_codec_hdmi(E) coretemp(E) ath9k_common(E) kvm_intel(E) ath9k_hw(E) snd_hda_intel(E) snd_intel_dspcfg(E) kvm(E) snd_intel_sdw_acpi(E) ath(E) irqbypass(E) snd_hda_codec(E) mac80211(E) snd_hda_core(E) ghash_clmulni_intel(E) snd_hwdep(E) aesni_intel(E) snd_pcm_oss(E) libaes(E) snd_mixer_oss(E) crypto_simd(E) dell_smm_hwmon(E) cfg80211(E) cryptd(E) snd_pcm(E) rapl(E) iTCO_wdt(E) snd_timer(E) intel_cstate(E) intel_pmc_bxt(E) snd(E) rfkill(E) iTCO_vendor_support(E) intel_uncore(E) pcspkr(E) libarc4(E) soundcore(E) mei_me(E) watchdog(E) [ 1945.480005] sg(E) at24(E) mei(E) evdev(E) nfsd(E) loop(E) auth_rpcgss(E) msr(E) nfs_acl(E) lockd(E) parport_pc(E) ppdev(E) grace(E) lp(E) parport(E) sunrpc(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) btrfs(E) blake2b_generic(E) xor(E) raid6_pq(E) libcrc32c(E) crc32c_generic(E) ums_realtek(E) uas(E) usb_storage(E) hid_generic(E) usbhid(E) hid(E) sd_mod(E) sr_mod(E) t10_pi(E) crc_t10dif(E) cdrom(E) crct10dif_generic(E) nouveau(E) mxm_wmi(E) wmi(E) i2c_algo_bit(E) drm_ttm_helper(E) ttm(E) xhci_pci(E) drm_kms_helper(E) ahci(E) r8169(E) crct10dif_pclmul(E) crct10dif_common(E) ehci_pci(E) realtek(E) lpc_ich(E) libahci(E) mdio_devres(E) cec(E) xhci_hcd(E) crc32_pclmul(E) libphy(E) ehci_hcd(E) crc32c_intel(E) libata(E) i2c_i801(E) i2c_smbus(E) drm(E) scsi_mod(E) usbcore(E) fan(E) video(E) button(E) [ 1945.480157] CPU: 7 PID: 2528 Comm: Xorg Tainted: G E 5.12.0+ #1 [ 1945.480164] Hardware name: Dell Inc. XPS 8700/0KWVT8, BIOS A06 11/18/2013 [ 1945.480168] RIP: 0010:refcount_warn_saturate+0xa6/0xf0 [ 1945.480177] Code: 05 b9 e2 3d 01 01 e8 79 e5 42 00 0f 0b c3 80 3d a7 e2 3d 01 00 75 95 48 c7 c7 68 61 f2 b1 c6 05 97 e2 3d 01 01 e8 5a e5 42 00 <0f> 0b c3 80 3d 86 e2 3d 01 00 0f 85 72 ff ff ff 48 c7 c7 c0 61 f2 [ 1945.480183] RSP: 0018:ffffbba402fd7d30 EFLAGS: 00010286 [ 1945.480188] RAX: 0000000000000000 RBX: 0000000000000002 RCX: ffff9194fedd8588 [ 1945.480192] RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9194fedd8580 [ 1945.480196] RBP: ffff918e03c0d800 R08: 0000000000000000 R09: ffffbba402fd7b50 [ 1945.480199] R10: ffffbba402fd7b48 R11: ffffffffb24cc7c8 R12: ffffffffc08b4d20 [ 1945.480202] R13: ffff918e00c2e000 R14: ffff918e7e348c00 R15: ffff918e7e348c00 [ 1945.480206] FS: 00007fa1278f0a40(0000) GS:ffff9194fedc0000(0000) knlGS:0000000000000000 [ 1945.480211] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1945.480215] CR2: 00007f8c0802f000 CR3: 000000013f4bc003 CR4: 00000000001706e0 [ 1945.480219] Call Trace: [ 1945.480225] nouveau_gem_new+0xc1/0xf0 [nouveau] [ 1945.480451] nouveau_gem_ioctl_new+0x53/0xf0 [nouveau] [ 1945.480618] ? nouveau_gem_new+0xf0/0xf0 [nouveau] [ 1945.480779] drm_ioctl_kernel+0xaa/0xf0 [drm] [ 1945.480837] drm_ioctl+0x20f/0x3a0 [drm] [ 1945.480883] ? nouveau_gem_new+0xf0/0xf0 [nouveau] [ 1945.481058] nouveau_drm_ioctl+0x55/0xa0 [nouveau] [ 1945.481233] __x64_sys_ioctl+0x83/0xb0 [ 1945.481242] do_syscall_64+0x33/0x80 [ 1945.481251] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 1945.481262] RIP: 0033:0x7fa127d5bcc7 [ 1945.481268] Code: 00 00 00 48 8b 05 c9 91 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 99 91 0c 00 f7 d8 64 89 01 48 [ 1945.481274] RSP: 002b:00007ffe54852078 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 1945.481281] RAX: ffffffffffffffda RBX: 00007ffe548520d0 RCX: 00007fa127d5bcc7 [ 1945.481285] RDX: 00007ffe548520d0 RSI: 00000000c0306480 RDI: 0000000000000010 [ 1945.481288] RBP: 00000000c0306480 R08: 0000000000000000 R09: 000055e83020e010 [ 1945.481292] R10: 00007fa127e25b80 R11: 0000000000000246 R12: 00007ffe548520d0 [ 1945.481296] R13: 0000000000000010 R14: 000055e8302c9fd0 R15: 0000000000001000 [ 1945.481302] ---[ end trace 1717583068871a81 ]--- [ 2081.413684] [TTM] Buffer eviction failed

3 9

Change how amdgpu stores fences in dma_resv objects
by Christian König 17 Jun '21

17 Jun '21

Since we can't find a consensus on hot to move forward with the dma_resv object I concentrated on changing the approach for amdgpu first. This new approach changes how the driver stores the command submission fence in the dma_resv object in DMA-buf exported BOs. For exported BOs we now store the CS fence in a dma_fence_chain container and assign that one to the exclusive fences slot. During synchronization this dma_fence_chain container is unpacked again and the containing fences handled individually. This has a little bit more overhead than the old approach, but it allows for waiting for the exclusive slot for writes again. Regards, Christian.

4 28

← Newer
1
...
40
41
42
43
44
45
46
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021