similar to: Xorg indefinitely hangs in kernelspace

> > 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

On 05.09.19 15:34, Jaak Ristioja wrote: > On 05.09.19 10:14, Gerd Hoffmann wrote: >> On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote: >>> 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

> > On 05.09.19 15:34, Jaak Ristioja wrote: > > On 05.09.19 10:14, Gerd Hoffmann wrote: > >> On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote: > >>> 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

Hello! I'm experiencing the following task hangs at least 2-3 times a day when using a Kubuntu desktop in KVM via a SPICE client. This has occurred with the stock kernels in Kubuntu since Kubuntu 18.04. This makes the VM unusable as a graphical remote desktop and the hung task prevents Kubuntu from gracefully rebooting (e.g. "reboot" via SSH). Any ideas? INFO: task Xorg:879 blocked

Hello! I'm experiencing the following task hangs at least 2-3 times a day when using a Kubuntu desktop in KVM via a SPICE client. This has occurred with the stock kernels in Kubuntu since Kubuntu 18.04. This makes the VM unusable as a graphical remote desktop and the hung task prevents Kubuntu from gracefully rebooting (e.g. "reboot" via SSH). Any ideas? INFO: task Xorg:879 blocked

On 05.09.19 10:14, Gerd Hoffmann wrote: > On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote: >> 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. > > Any change with kernel

On 05.09.19 10:14, Gerd Hoffmann wrote: > On Tue, Aug 06, 2019 at 09:00:10PM +0300, Jaak Ristioja wrote: >> 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. > > Any change with kernel

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

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]

When we disable hotplugging on the GPU, we need to be able to synchronize with each connector's hotplug interrupt handler before the interrupt is finally disabled. This can be a problem however, since nouveau_connector_detect() currently grabs a runtime power reference when handling connector probing. This will deadlock the runtime suspend handler like so: [ 861.480896] INFO: task

Using struct drm_device.pdev is deprecated. Convert qxl to struct drm_device.dev. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Acked-by: Sam Ravnborg <sam at ravnborg.org> Cc: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.c | 2 +- drivers/gpu/drm/qxl/qxl_ioctl.c | 3 ++- drivers/gpu/drm/qxl/qxl_irq.c | 3 ++-

Using struct drm_device.pdev is deprecated. Convert qxl to struct drm_device.dev. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Acked-by: Sam Ravnborg <sam at ravnborg.org> Cc: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.c | 2 +- drivers/gpu/drm/qxl/qxl_ioctl.c | 3 ++- drivers/gpu/drm/qxl/qxl_irq.c | 3 ++-

https://bugs.freedesktop.org/show_bug.cgi?id=100691 Bug ID: 100691 Summary: [4.10] BUG: KASAN: use-after-free in drm_calc_vbltimestamp_from_scanoutpos+0x625/0x740 Product: xorg Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

On Wed, Aug 01, 2018 at 05:14:57PM -0400, Lyude Paul wrote: > When we disable hotplugging on the GPU, we need to be able to > synchronize with each connector's hotplug interrupt handler before the > interrupt is finally disabled. This can be a problem however, since > nouveau_connector_detect() currently grabs a runtime power reference > when handling connector probing. This

On most systems with ACPI hotplugging support, it seems that we always receive a hotplug event once we re-enable EC interrupts even if the GPU hasn't even been resumed yet. This can cause problems since even though we schedule hpd_work to handle connector reprobing for us, hpd_work synchronizes on pm_runtime_get_sync() to wait until the device is ready to perform reprobing. Since runtime

https://bugs.freedesktop.org/show_bug.cgi?id=100545 Bug ID: 100545 Summary: BUG: null pointer dereference dma_fence_wait_timeout from nouveau_drm_ioctl (linux 4.10.5) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Keywords: have-backtrace

The warning you included happens when we're trying to execute a VBIOS script as part of DP training. Can you include your vbios? It should be available at /sys/kernel/debug/dri/0/vbios.rom Also, can you confirm how your monitors are connected to the card (and e.g. what resolution they are, anything else "funny" about them)? Finally, this warning might not have anything to do with

I have a Nvidia NVS310 installed in my Linux computer for a few years. It works well with the Nvidia driver, and not so well with the Linux nouveau driver. The Nvidia NVS310 has never worked well with Linux. In the beginning (many years ago) I decided to install Nvidia proprietary drivers, but every kernel upgrade would require an additional effort to have the driver working. That was enough