similar to: locking warnings in drm/virtio code

Hello! I'm writing to report a crash in the QXL / DRM code in the Linux kernel. I originally filed the issue on LaunchPad and more details can be found there, although I doubt whether these details are useful. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813620 I first experienced these issues with: * Ubuntu 18.04 (probably kernel 4.15.something) * Ubuntu 18.10 (kernel

Hello! I'm writing to report a crash in the QXL / DRM code in the Linux kernel. I originally filed the issue on LaunchPad and more details can be found there, although I doubt whether these details are useful. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813620 I first experienced these issues with: * Ubuntu 18.04 (probably kernel 4.15.something) * Ubuntu 18.10 (kernel

> > On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja <jaak at ristioja.ee> > > Hello! > > > > I'm writing to report a crash in the QXL / DRM code in the Linux kernel. > > I originally filed the issue on LaunchPad and more details can be found > > there, although I doubt whether these details are useful. > > > >

On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja <jaak at ristioja.ee> > Hello! > > I'm writing to report a crash in the QXL / DRM code in the Linux kernel. > I originally filed the issue on LaunchPad and more details can be found > there, although I doubt whether these details are useful. > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813620

On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja <jaak at ristioja.ee> > Hello! > > I'm writing to report a crash in the QXL / DRM code in the Linux kernel. > I originally filed the issue on LaunchPad and more details can be found > there, although I doubt whether these details are useful. > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1813620

In case queuing virtio commands fails (can happen when the device got unplugged) pass up the error. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 36 +++++++++++++++-------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index

I hit this while testing HMM with nouveau on linux-5.5-rc5. I'm not a lockdep expert but my understanding of this is that an invalidation callback could potentially call kzalloc(GFP_KERNEL) which could cause another invalidation and recursively deadlock. Looking at the drivers/gpu/drm/nouveau/nvkm/ layer, I do see a number of places where GFP_KERNEL is used for allocations and I don't see

With lightweight desktoping, the atomic modesetting seems far from robust. BUG: unable to handle kernel NULL pointer dereference at 0000000000000021 IP: dma_fence_wait_timeout+0x36/0xf0 ... Oops: 0000 [#1] SMP Modules linked in: ... nouveau ... CPU: 0 PID: 6895 Comm: Xorg Not tainted 4.10.5-1001.fc24.x86_64 #1 ... Call Trace: drm_atomic_helper_wait_for_fences+0x48/0x120 [drm_kms_helper]

Drop the virtio_gpu_{disable,enable}_notify(). Add a new virtio_gpu_notify() call instead, which must be called whenever the driver wants make sure the host is notified needed. Drop automatic notification from command submission. Add virtio_gpu_notify() calls after each command query instead. This allows more fine-grained control over host notification and can move around the notify calls in

Drop the virtio_gpu_{disable,enable}_notify(). Add a new virtio_gpu_notify() call instead, which must be called whenever the driver wants make sure the host is notified needed. Drop automatic notification from command submission. Add virtio_gpu_notify() calls after each command query instead. This allows more fine-grained control over host notification and can move around the notify calls in

Add helper function to handle the submission of fenced control requests. Make sure we initialize the fence while holding the virtqueue lock, so requests can't be reordered. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 40 +++++++++++++++++++++++++++++----- 2 files changed, 35

Add helper function to handle the submission of fenced control requests. Make sure we initialize the fence while holding the virtqueue lock, so requests can't be reordered. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 40 +++++++++++++++++++++++++++++----- 2 files changed, 35

Add helper function to handle the submission of fenced control requests. Make sure we initialize the fence while holding the virtqueue lock, so requests can't be reordered. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 40 +++++++++++++++++++++++++++++----- 2 files changed, 35

Add helper function to handle the submission of fenced control requests. Make sure we initialize the fence while holding the virtqueue lock, so requests can't be reordered. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 40 +++++++++++++++++++++++++++++----- 2 files changed, 35

Add helper function to handle the submission of fenced control requests. Make sure we initialize the fence while holding the virtqueue lock, so requests can't be reordered. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 40 +++++++++++++++++++++++++++++----- 2 files changed, 35

Add helper function to handle the submission of fenced control requests. Make sure we initialize the fence while holding the virtqueue lock, so requests can't be reordered. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 40 +++++++++++++++++++++++++++++----- 2 files changed, 35

Factor function in preparation to generating scatterlist prior to locking. Signed-off-by: David Riley <davidriley at chromium.org> --- drivers/gpu/drm/virtio/virtgpu_vq.c | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 7fd2851f7b97..5a64c776138d 100644 ---

Move virtio_gpu_notify() to higher-level functions for virtio_gpu_cmd_create_resource(), virtio_gpu_cmd_resource_create_3d() and virtio_gpu_cmd_resource_attach_backing(). virtio_gpu_object_create() will batch commands and notify only once when creating a resource. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 1 +

Hi, I get a warning in the domU kernels when I pass-through the ehcu/uhci devices. The usb-ports seem to work. I can use usb-sticks and a sundtek DVB-C stick. A microsoft usb-mouse is not recognized. Can I ignore the warning or do I have some serious issue/misconfiguration? Dom0: xm info: host : luna release : 3.1.0-rc5+ version : #6 SMP Sat Sep

Currently; we're grabbing all of the modesetting locks before adding MST connectors to fbdev. This isn't actually necessary, and causes a deadlock as well: ====================================================== WARNING: possible circular locking dependency detected 4.17.0-rc3Lyude-Test+ #1 Tainted: G O ------------------------------------------------------ kworker/1:0/18 is