similar to: we don't synchronize in our buffer object move driver hook

This is a bit messed up because chan->cli->mutex is a different class, depending on whether it is the global drm client or not. This is because the global cli->mutex lock can be taken for eviction, so locking it before pinning the buffer objects may result in a deadlock. The locking order from outer to inner is: - &cli->mutex - ttm_bo - &drm_client_lock (global

Greetings, Kernel bound workloads seem to trigger the below for whatever reason.  I only see this when beating up NFS.  There was a kworker wakeup latency issue, but with a bandaid applied to fix that up, I can still trigger this. [ 1313.811031] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [ 1313.811035] swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152

On 12/18/17 7:06 PM, Mike Galbraith wrote: > Greetings, > > Kernel bound workloads seem to trigger the below for whatever reason. >  I only see this when beating up NFS.  There was a kworker wakeup > latency issue, but with a bandaid applied to fix that up, I can still > trigger this. Hi, i have seen this one as well with my system, but i could not find an easy way to

https://bugs.freedesktop.org/show_bug.cgi?id=111843 Bug ID: 111843 Summary: Resume fails after suspend with nouveau and Gtx 1050 ti Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: Driver/nouveau

Hello, I've noticed firefox got randomly stuck, and as sometimes that leads to a complete system lock-up, I've checked dmesg and got this: [Jan29 10:49] nouveau 0000:01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [ +0.000033] swiotlb: coherent allocation failed for device 0000:01:00.0 size=2097152 [ +0.000004] CPU: 6 PID: 1023 Comm: Xorg Not tainted 4.15.0-rc8 #1 [ +0.000003]

On Wed, Jan 31, 2018 at 9:20 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Yeah, a lot of people were getting that, as a result of some drm/ttm > hugepage usage. > > Christian, did a fix ever end up going out? If so, what kernel was it > included in? https://lkml.org/lkml/2018/1/16/106 Alex > > -ilia > > On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger

Hi Marek Thanks a lot for your rebasing work. Here is my report : - all my games that broke with temporaries patch (they were either completely black or lot of black screen flash every frame) behave badly, but in different ways : * etracer is very slow and often crash in ttm code [1] (I think this is an old bug that just resurrected, no idea why) * foobillard is very slow and still flash a bit *

Yeah, a lot of people were getting that, as a result of some drm/ttm hugepage usage. Christian, did a fix ever end up going out? If so, what kernel was it included in? -ilia On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger Sanchez <rnsanchez at gmail.com> wrote: > Hello, > > I've noticed firefox got randomly stuck, and as sometimes that leads to a > complete system

https://bugs.freedesktop.org/show_bug.cgi?id=102192 Bug ID: 102192 Summary: Dell XPS 15 9560: PU: 1 PID: 58 at drivers/gpu/drm/nouveau/nvkm/subdev/mmu/gf100.c:190 gf100_vm_flush+0x1b3/0x1c0 [nouveau] Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All)

From: Lucas Stach <dev at lynxeye.de> Signed-off-by: Lucas Stach <dev at lynxeye.de> [acourbot at nvidia.com: make conditional and platform-friendly] Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 32 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/nouveau/nouveau_bo.h | 20 ++++++++++++++++++++

From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> That is not used any more. v2: keep the NULL checks in TTM. Signed-off-by: Christian K?nig <christian.koenig at amd.com> Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/ttm/ttm_bo.c | 34 +-------- drivers/gpu/drm/ttm/ttm_bo_util.c | 113 +++--------------------------

- Use the "direct" objects that previously only the kernel fifo had. - This avoids corruption on some buffer moves. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 23 ++--------------- drivers/gpu/drm/nouveau/nouveau_object.c | 36 ++++++++++++++++++++++++++++ drivers/gpu/drm/nouveau/nouveau_state.c | 38

Am Mittwoch, den 28.08.2013, 12:43 -0400 schrieb Konrad Rzeszutek Wilk: > On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote: > > Signed-off-by: Lucas Stach <dev at lynxeye.de> > > --- > > drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++++ > > drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +++++ > > 2 files changed, 9 insertions(+) > > > >

Signed-off-by: Lucas Stach <dev at lynxeye.de> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++++ drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +++++ 2 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index af20fba..f4a2eb9 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@

On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote: > Signed-off-by: Lucas Stach <dev at lynxeye.de> > --- > drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++++ > drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +++++ > 2 files changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c > index

Am Montag, den 19.05.2014, 16:10 +0900 schrieb Alexandre Courbot: > From: Lucas Stach <dev at lynxeye.de> > > Signed-off-by: Lucas Stach <dev at lynxeye.de> > [acourbot at nvidia.com: make conditional and platform-friendly] > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drivers/gpu/drm/nouveau/nouveau_bo.c | 32

https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #8 from Nick Lee <nvlbox at gmail.com> --- Also tried: Vanilla kernel 4.15.4-300.vanilla.knurd.1.fc27.x86_64 mesa-17.3.5 wayland session reproducible Fedora-Workstation-Live-x86_64-Rawhide-20180220.n.0.iso wayland session mesa-18.0.0-0.1.rc4.fc28.x86_64 Got artefacts with dmesg output: [ 1035.437016] nouveau 0000:03:00.0:

In the trace below, swiotlb_alloc() is called with __GFP_NOWARN, it ors attrs with DMA_ATTR_NO_WARN and passes it to swiotlb_alloc_buffer(), which does NOT pass it on to swiotlb_tbl_map_single(), leading to an ever repeating warning that the caller of swiotlb_alloc() explicitly asked to be squelched. Pass the caller's request for silence onward. Xorg-3170 [006] .... 963.866098:

https://bugs.freedesktop.org/show_bug.cgi?id=105173 --- Comment #10 from Pierre Moreau <pierre.morrow at free.fr> --- (In reply to Nick Lee from comment #8) > Also tried: > > Vanilla kernel 4.15.4-300.vanilla.knurd.1.fc27.x86_64 > mesa-17.3.5 > wayland session > reproducible What exactly is reproducible? The artefacts I would assume, but which error exactly? The NULL

Greetings! I am trying to do a hot driver swap between the vfio-pci and nouveau drivers for my secondary Nvidia graphics card. I boot up with vfio-pci enabled. With this script I give control over the GPU to nouveau: echo "0000:01:00.0" > /sys/bus/pci/devices/0000\:01\:00.0/driver/unbind echo 0x10de 0x11c6 > /sys/bus/pci/drivers/nouveau/new_id echo 1 > /sys/bus/pci/rescan