Dear Maintainer,
I would like to report a kernel bug in Debian Sid. The bug is related to
the driver for QXL virtualized graphics. The bug occurs in emulated
two-monitor QEMU machines, to which I connect using remote-viewer
(from package virt-viewer) over the SPICE protocol.
My host runs Debian Trixie. I use the following command to launch QEMU:
qemu-system-x86_64 \
-smp cores=2,threads=1,sockets=1 \
-enable-kvm \
-m 4G \
-netdev user,id=ethernet \
-device virtio-net-pci,netdev=ethernet \
-vga none \
-device qxl-vga \
-display none \
-spice unix=on,addr=/tmp/spice.sock,disable-ticketing=on \
-chardev spicevmc,id=charchannel0,name=vdagent \
-device virtio-serial-pci,id=virtio-serial0 \
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
\
-serial mon:stdio \
debian-sid-kde.qcow2
The guest disk was originally the "nocloud" cloud image, which I downloaded
from the Debian website, and then upgraded to Sid. The guest runs upstream
KDE Plasma installed using the kde-builder utility. (I was unable to
reproduce this bug using the Debian version of Plasma.) All other installed
packages, incl. Qt, SDDM and spice-vdagent, come from Debian.
To trigger this bug follow these steps:
1. Boot the VM and connect to it using remote-viewer.
2. Start an X11 Plasma session.
3. Once it loads up, make remote-viewer show the second monitor.
(Spice-vdagent will detect this and switch Plasma to a multi-monitor
layout.)
4. Log out and run a Wayland Plasma session.
After the last step, Plasma won't load, and the content of the screen
will glitch. Two scenarios may follow.
--------
In the first scenario, the glitched content of the display will usually
be static; it won't react to moving the cursor or keystrokes.
(The cursor itself is shown correctly, probably because it's emulated
by the host separately.) QEMU prints the following warning:
qemu-system-x86_64: warning: Spice:
../server/display-channel.cpp:2074:display_channel_create_surface:
condition `!display->priv->surfaces[surface_id]' failed
The kernel will then print an error message starting with the text
"[drm] driver is in bug mode"; its full text is in the attachment
sc1_msg_bug_mode.txt. The relevant part of the systemd journal is in
the attachment sc1_journal.txt (note the endless messages from
kwin_wayland_drm). Screenshots of glitched screen contents are
in sc1_scr_primary.png and sc1_scr_secondary.png.
If one attempts to kill all Wayland-related processes, a kwin_wayland
process will get stuck in uninterruptible sleep. The same will happen
to SDDM's Xorg process when one attempts to kill it. Attachments
sc1_info_wayland1.txt, sc1_info_wayland2.txt and sc1_info_xorg.txt
include some information (from /proc/) about examples of such hung
processes.
The kernel periodically prints INFO messages about blocked tasks.
See sc1_msg_task_blocked1.txt for the text of the message when
only Wayland had been killed. The file sc1_msg_task_blocked2.txt
contains the text after I additionally killed SDDM's Xorg.
There are cases when the kernel prints the "driver is in bug mode" message
only after some cursor movement. In this case, moving the cursor changes
the glitched pattern on the screen. However, after the error message,
cursor movement no longer has any effect.
Sometimes, the following messages are printed some time after
the graphics crash (the latter repeats periodically):
[ 6883.254662] qxl 0000:00:03.0: object_init failed for (3149824,
0x00000001)
[ 6883.260647] [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to
allocate VRAM BO
[ 6832.816431] [TTM] Buffer eviction failed
--------
In the much rarer second crash scenario, the kernel prints a completely
different message during the graphics crash; this message starts with
"BUG: kernel NULL pointer dereference" (see sc2_msg_nullderef.txt).
It is possible to kill all Wayland processes. Killing SDDM's Xorg results
in it being stuck briefly in D state, with the following stack trace
(from /proc/[PID]/stack):
[<0>] console_lock+0x2f/0x50
[<0>] vt_ioctl+0x520/0x1600
[<0>] tty_ioctl+0xe4/0x980
[<0>] __x64_sys_ioctl+0x97/0xe0
[<0>] do_syscall_64+0xcd/0x15f0
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
If I attempt to stop SDDM, Xorg restarts (with a new PID), and gets stuck
in uninterruptible sleep again, with the following stack trace (cf.
the trace in sc1_info_wayland2.txt):
[<0>] drm_modeset_lock+0xd0/0x120 [drm]
[<0>] drm_mode_getcrtc+0x80/0x180 [drm]
[<0>] drm_ioctl_kernel+0xae/0x100 [drm]
[<0>] drm_ioctl+0x2a8/0x550 [drm]
[<0>] __x64_sys_ioctl+0x97/0xe0
[<0>] do_syscall_64+0xcd/0x15f0
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
--------
This bug has other consequences, too. Running `systemctl poweroff` doesn't
power off the VM fully -- QEMU won't terminate. Sometimes `su -c` executes
commands with delay of tens of seconds.
Some actions (e.g. restarting SDDM after killing it and Wayland) will cause
apparent deadlocks in TTY-related kernel functionality. For example, certain
terminal-manipulating commands (e.g. `chvt`) stop working, because openat
calls on /dev/tty* files get stuck with the following stack trace:
[<0>] tty_open+0x1ef/0x740
[<0>] chrdev_open+0xad/0x240
[<0>] do_dentry_open+0x134/0x490
[<0>] vfs_open+0x30/0x100
[<0>] path_openat+0x848/0x13f0
[<0>] do_file_open+0xe3/0x190
[<0>] do_sys_openat2+0x7b/0xe0
[<0>] __x64_sys_openat+0x61/0xa0
[<0>] do_syscall_64+0xcd/0x15f0
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
`ps` hangs, too, because it attempts to open /proc/tty/drivers.
The stack trace is:
[<0>] t_start+0x19/0x30
[<0>] seq_read_iter+0x101/0x490
[<0>] proc_reg_read_iter+0x4f/0x90
[<0>] vfs_read+0x268/0x390
[<0>] ksys_read+0x73/0xf0
[<0>] do_syscall_64+0xcd/0x15f0
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
`systemctl poweroff` stops working, because systemd gets stuck in D state
with the following stack:
[<0>] console_lock+0x2f/0x50
[<0>] show_cons_active+0xb2/0x2d0
[<0>] dev_attr_show+0x1f/0x50
[<0>] sysfs_kf_seq_show+0xcc/0x120
[<0>] seq_read_iter+0x128/0x490
[<0>] vfs_read+0x268/0x390
[<0>] ksys_read+0x73/0xf0
[<0>] do_syscall_64+0xcd/0x15f0
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
Additionally, it is impossible to read from /dev/vcs*;
`cat` get stuck with the following stack trace:
[<0>] console_lock+0x2f/0x50
[<0>] vcs_open+0x22/0x50
[<0>] chrdev_open+0xad/0x240
[<0>] do_dentry_open+0x134/0x490
[<0>] vfs_open+0x30/0x100
[<0>] path_openat+0x848/0x13f0
[<0>] do_file_open+0xe3/0x190
[<0>] do_sys_openat2+0x7b/0xe0
[<0>] __x64_sys_openat+0x61/0xa0
[<0>] do_syscall_64+0xcd/0x15f0
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
--------
Thank you for considering this bug report.
Best regards,
Samuel Plavec