[Bug 1924914] Re: Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver)
>From the dmesg above: [ 573.935889] Oops: [#1] PREEMPT SMP PTI [ 573.935892] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.11.11-arch1-1 #1 [ 573.935896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.14.0-1 04/01/2014 [ 573.935899] Workqueue: events_unbound commit_work [drm_kms_helper] [ 573.935949] RIP: 0010:dma_fence_wait_timeout+0x20/0x110 [ 573.935953] Code: 5c 41 5d 41 5e 41 5f c3 66 90 0f 1f 44 00 00 41 54 55 53 48 83 ec 08 48 85 d2 0f 88 da 00 00 00 48 89 fd 89 f3 0f 1f 44 00 00 <48> 8b 45 08 0f b6 f3 48 89 ef 48 8b 40 28 48 85 c0 0f 84 ac 00 00 [ 573.935956] RSP: 0018:bbf100043db0 EFLAGS: 00010206 [ 573.935958] RAX: 0001 RBX: 0001 RCX: 0001 [ 573.935959] RDX: 7fff RSI: 0001 RDI: [ 573.935961] RBP: R08: 0001 R09: 90631e171bc0 [ 573.935962] R10: 0001 R11: 0001 R12: 906408336000 [ 573.935964] R13: 906380260cc0 R14: 90640170 R15: 0005 [ 573.935966] FS: () GS:90643bc0() knlGS: [ 573.935967] CS: 0010 DS: ES: CR0: 80050033 [ 573.935969] CR2: 0008 CR3: 00011ed86000 CR4: 06f0 [ 573.935973] DR0: DR1: DR2: [ 573.935974] DR3: DR6: fffe0ff0 DR7: 0400 [ 573.935976] Call Trace: [ 573.935983] ? virtio_gpu_notify+0x46/0x60 [virtio_gpu] [ 573.935995] virtio_gpu_cursor_plane_update+0x1c3/0x2a0 [virtio_gpu] [ 573.936005] drm_atomic_helper_commit_planes+0xb7/0x220 [drm_kms_helper] [ 573.936024] drm_atomic_helper_commit_tail+0x42/0x80 [drm_kms_helper] [ 573.936038] commit_tail+0xce/0x130 [drm_kms_helper] [ 573.936050] process_one_work+0x214/0x3e0 [ 573.936054] worker_thread+0x4d/0x3d0 [ 573.936056] ? rescuer_thread+0x3c0/0x3c0 [ 573.936058] kthread+0x133/0x150 [ 573.936061] ? __kthread_bind_mask+0x60/0x60 [ 573.936064] ret_from_fork+0x22/0x30 [ 573.936072] Modules linked in: cfg80211 rfkill ghash_generic gf128mul cryptd gcm ccm algif_aead des_generic libdes cbc ecb algif_skcipher cmac md4 algif_hash af_alg ppdev pktcdvd parport_pc parport i2c_piix4 joydev mousedev mac_hid psmouse qemu_fw_cfg pcspkr pkcs8_key_parser speakup_soft speakup fuse bpf_preload ip_tables x_tables overlay squashfs loop isofs sr_mod cdrom ata_generic pata_acpi virtio_gpu virtio_dma_buf drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm intel_agp intel_gtt serio_raw e1000 virtio_pci ata_piix agpgart floppy [ 573.936161] CR2: 0008 [ 573.936163] ---[ end trace 0f1e24b3ea0a35cd ]--- [ 573.936165] RIP: 0010:dma_fence_wait_timeout+0x20/0x110 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1924914 Title: Running sway in a QEMU VM results in a GPU hang of the guest (virtio- gpu driver) Status in QEMU: New Bug description: System is Arch Linux (guest and host OS). Problem: Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. This is the command I use to run my guest: qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 This doesn't happen when I use X with i3-wm. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1924914/+subscriptions
[Bug 1924914] Re: Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver)
-cpu host -smp 4 makes the hang/freeze go away. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1924914 Title: Running sway in a QEMU VM results in a GPU hang of the guest (virtio- gpu driver) Status in QEMU: New Bug description: System is Arch Linux (guest and host OS). Problem: Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. This is the command I use to run my guest: qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 This doesn't happen when I use X with i3-wm. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1924914/+subscriptions
[Bug 1924914] Re: Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver)
I can't reproduce it with weston. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1924914 Title: Running sway in a QEMU VM results in a GPU hang of the guest (virtio- gpu driver) Status in QEMU: New Bug description: System is Arch Linux (guest and host OS). Problem: Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. This is the command I use to run my guest: qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 This doesn't happen when I use X with i3-wm. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1924914/+subscriptions
[Bug 1924914] Re: Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver)
I can't get it to happen with -vga qxl. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1924914 Title: Running sway in a QEMU VM results in a GPU hang of the guest (virtio- gpu driver) Status in QEMU: New Bug description: System is Arch Linux (guest and host OS). Problem: Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. This is the command I use to run my guest: qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 This doesn't happen when I use X with i3-wm. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1924914/+subscriptions
[Bug 1924914] [NEW] Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver)
Public bug reported: System is Arch Linux (guest and host OS). Problem: Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. This is the command I use to run my guest: qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 This doesn't happen when I use X with i3-wm. ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "dmesg of the guest VM when the crash occurs" https://bugs.launchpad.net/bugs/1924914/+attachment/5489500/+files/dmesg-sway-qemu-crash -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1924914 Title: Running sway in a QEMU VM results in a GPU hang of the guest (virtio- gpu driver) Status in QEMU: New Bug description: System is Arch Linux (guest and host OS). Problem: Basically, when using sway on a guest and running certain applications via Xwayland (on the guest), the GUI will freeze and won't be usable anymore, I can still ssh to the guest and run commands. This is the command I use to run my guest: qemu-system-x86_64 -enable-kvm -cdrom ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga virtio -nic user,hostfwd=tcp::10022-:22 This doesn't happen when I use X with i3-wm. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1924914/+subscriptions
[Bug 1892581] Re: QEMU 5.1 no longer says anything about inaccessible devices
** Changed in: qemu Status: Incomplete => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1892581 Title: QEMU 5.1 no longer says anything about inaccessible devices Status in QEMU: Invalid Bug description: Previously, with QEMU 5.0.0 running a VM with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb- host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio Would display something like the following: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. With insufficient permissions. QEMU 5.1.0 no longer displays anything. I did a git bisect and this is the result: [diego@thinkpad qemu]$ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) [diego@thinkpad qemu]$ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1892581/+subscriptions
[Bug 1892581] Re: QEMU 5.1 no longer says anything about inaccessible devices
I no longer need this (it's no longer an issue for me), feel free to reopen if this issue affects you. ** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1892581 Title: QEMU 5.1 no longer says anything about inaccessible devices Status in QEMU: Incomplete Bug description: Previously, with QEMU 5.0.0 running a VM with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb- host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio Would display something like the following: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. With insufficient permissions. QEMU 5.1.0 no longer displays anything. I did a git bisect and this is the result: [diego@thinkpad qemu]$ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) [diego@thinkpad qemu]$ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1892581/+subscriptions
Re: Slow video output from webcam with qemu-xhci but smooth with usb-ehci
On Sat, Dec 12, 2020 at 1:28 PM Diego Viola wrote: > > Hi, > > I'm experiencing a lot of choppiness in the video output when I pass > through my USB webcam to the guest using qemu-xhci as follows: > > qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio > -device qemu-xhci,id=xhci -device > usb-host,bus=xhci.0,hostdevice=/dev/bus/usb/002/004 > > My webcam is: > > Bus 002 Device 004: ID 04f2:b449 Chicony Electronics Co., Ltd Integrated > Camera > > I am using mpv /dev/video0 from the guest. > > It works fine if I use usb-ehci instead, e.g.: > > qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio > -device usb-ehci,id=ehci -device > usb-host,bus=ehci.0,hostdevice=/dev/bus/usb/002/004 > > In this case, the video output from mpv /dev/video0 is not choppy. > > My QEMU version is 5.2.0 -- I am running Arch Linux on the host and guest. > > Any ideas please? > > Thanks, > Diego OK, I just noticed that it's mostly at the beginning (when I first run mpv) that the video is jerky/choppy, looks like mpv is still buffering at that stage, after buffering gets to 99% the video is smoother (with xhci). Now I don't understand why buffering with ehci happens a lot faster/smoother. Nevermind, not an issue after all. Diego
Re: Slow video output from webcam with qemu-xhci but smooth with usb-ehci
On Sun, Dec 13, 2020 at 4:30 PM Diego Viola wrote: > > Not sure it's related but I'm seeing this on the guest now when I use > mpv --vo=drm on a tty: mpv --vo=drm /dev/video0
Re: Slow video output from webcam with qemu-xhci but smooth with usb-ehci
Not sure it's related but I'm seeing this on the guest now when I use mpv --vo=drm on a tty: [ 28.918606] xhci_hcd :00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 28.919816] xhci_hcd :00:04.0: Looking for event-dma 00012a8c7d80 trb-start 00012a8c7d70 trb-end 00012a8c7d70 seg-start 00012a8c7000 seg-end 00012a8c7ff0 [ 28.919818] xhci_hcd :00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 28.921019] xhci_hcd :00:04.0: Looking for event-dma 00012a8c7d90 trb-start 00012a8c7d70 trb-end 00012a8c7d70 seg-start 00012a8c7000 seg-end 00012a8c7ff0 [ 28.921023] xhci_hcd :00:04.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 28.922203] xhci_hcd :00:04.0: Looking for event-dma 00012a8c7da0 trb-start 00012a8c7d70 trb-end 00012a8c7d70 seg-start 00012a8c7000 seg-end 00012a8c7ff0 Video is then a bit smoother. Diego On Sat, Dec 12, 2020 at 1:28 PM Diego Viola wrote: > > Hi, > > I'm experiencing a lot of choppiness in the video output when I pass > through my USB webcam to the guest using qemu-xhci as follows: > > qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio > -device qemu-xhci,id=xhci -device > usb-host,bus=xhci.0,hostdevice=/dev/bus/usb/002/004 > > My webcam is: > > Bus 002 Device 004: ID 04f2:b449 Chicony Electronics Co., Ltd Integrated > Camera > > I am using mpv /dev/video0 from the guest. > > It works fine if I use usb-ehci instead, e.g.: > > qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio > -device usb-ehci,id=ehci -device > usb-host,bus=ehci.0,hostdevice=/dev/bus/usb/002/004 > > In this case, the video output from mpv /dev/video0 is not choppy. > > My QEMU version is 5.2.0 -- I am running Arch Linux on the host and guest. > > Any ideas please? > > Thanks, > Diego
Slow video output from webcam with qemu-xhci but smooth with usb-ehci
Hi, I'm experiencing a lot of choppiness in the video output when I pass through my USB webcam to the guest using qemu-xhci as follows: qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio -device qemu-xhci,id=xhci -device usb-host,bus=xhci.0,hostdevice=/dev/bus/usb/002/004 My webcam is: Bus 002 Device 004: ID 04f2:b449 Chicony Electronics Co., Ltd Integrated Camera I am using mpv /dev/video0 from the guest. It works fine if I use usb-ehci instead, e.g.: qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio -device usb-ehci,id=ehci -device usb-host,bus=ehci.0,hostdevice=/dev/bus/usb/002/004 In this case, the video output from mpv /dev/video0 is not choppy. My QEMU version is 5.2.0 -- I am running Arch Linux on the host and guest. Any ideas please? Thanks, Diego
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
This bug is now fixed with Linux 5.9-rc5, thank you. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
Re: Help with usb-host hostdevice property
On Thu, Aug 27, 2020 at 5:01 AM Gerd Hoffmann wrote: > > Hi, > > > usb 1-1: Invalid ep0 maxpacket: 64 > > usb usb1-port1: unable to enumerate USB device > > https://patchwork.ozlabs.org/project/qemu-devel/patch/20200826145239.6077-18-kra...@redhat.com/ That helps indeed, thanks Gerd! Tested-by: Diego Viola > > HTH, > Gerd > Diego
Help with usb-host hostdevice property
Hi, I'm trying to use the new usb-host hostdevice property that was added here: https://git.qemu.org/?p=qemu.git;a=commit;h=9f815e83e983d247a3cd67579d2d9c1765adc644 This is the command line that I am using: qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device qemu-xhci,id=xhci -device usb-host,bus=xhci.0,hostdevice=/dev/bus/usb/002/004 -device intel-hda -device hda-duplex -vga virtio My user has permissions to access /dev/bus/usb/002/004 -- I am trying to pass-through this device: Bus 002 Device 004: ID 04f2:b449 Chicony Electronics Co., Ltd Integrated Camera When I boot up the guest I get this: usb 1-1: Invalid ep0 maxpacket: 64 usb usb1-port1: unable to enumerate USB device This works though: qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device qemu-xhci,id=xhci -device usb-host,bus=xhci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio I am using QEMU 5.1.0 on Arch Linux. Arch Linux is running on the guest as well as on the host. Any ideas what I'm doing wrong here please? Thanks, Diego
[Bug 1882851] [PATCH] drm/virtio: fix unblank
From: Gerd Hoffmann
When going through a disable/enable cycle without changing the
framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio:
skip set_scanout if framebuffer didn't change") causes the screen stay
blank. Add a bool to force an update to fix that.
v2: use drm_atomic_crtc_needs_modeset() (Daniel).
Cc: 1882...@bugs.launchpad.net
Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't
change")
Signed-off-by: Gerd Hoffmann
Tested-by: Jiri Slaby
Tested-by: Diego Viola
---
drivers/gpu/drm/virtio/virtgpu_display.c | 11 +++
drivers/gpu/drm/virtio/virtgpu_drv.h | 1 +
drivers/gpu/drm/virtio/virtgpu_plane.c | 4 +++-
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c
b/drivers/gpu/drm/virtio/virtgpu_display.c
index af55b334be2f..35b5c80f5d85 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -123,6 +123,17 @@ static int virtio_gpu_crtc_atomic_check(struct drm_crtc
*crtc,
static void virtio_gpu_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
+ struct virtio_gpu_output *output = drm_crtc_to_virtio_gpu_output(crtc);
+
+ /*
+* virtio-gpu can't do modeset and plane update operations
+* independant from each other. So the actual modeset happens
+* in the plane update callback, and here we just check
+* whenever we must force the modeset.
+*/
+ if (drm_atomic_crtc_needs_modeset(crtc->state)) {
+ output->needs_modeset = true;
+ }
}
static const struct drm_crtc_helper_funcs virtio_gpu_crtc_helper_funcs = {
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 9ff9f4ac0522..4ab1b0ba2925 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -138,6 +138,7 @@ struct virtio_gpu_output {
int cur_x;
int cur_y;
bool enabled;
+ bool needs_modeset;
};
#define drm_crtc_to_virtio_gpu_output(x) \
container_of(x, struct virtio_gpu_output, crtc)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 52d24179bcec..65757409d9ed 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -163,7 +163,9 @@ static void virtio_gpu_primary_plane_update(struct
drm_plane *plane,
plane->state->src_w != old_state->src_w ||
plane->state->src_h != old_state->src_h ||
plane->state->src_x != old_state->src_x ||
- plane->state->src_y != old_state->src_y) {
+ plane->state->src_y != old_state->src_y ||
+ output->needs_modeset) {
+ output->needs_modeset = false;
DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n",
bo->hw_res_handle,
plane->state->crtc_w, plane->state->crtc_h,
--
2.28.0
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1882851
Title:
QEMU video freezes with "Guest disabled display" (virtio driver)
Status in QEMU:
New
Bug description:
I am using Arch Linux as my Guest and Host OS, after starting qemu
with the following command:
$ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga
virtio
and waiting for a screen blank, I get this message:
Guest disabled display
And nothing happens after that, I can move the mouse or hit any key,
and the message is still there.
I can still reboot the VM but that's not optimal.
I can reproduce this with the latest QEMU release (5.0.0) or git master,
I also tried this with older releases (4.0.0, 3.0.0) and the issue is still
there.
I can't reproduce this with other video drivers (std, qxl).
With std/qxl the screen will blank a bit and then continue as normal.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1892581] Re: QEMU 5.1 no longer says anything about inaccessible devices
I was changing the /dev file permissions based on the output from above, that's why I decided to submit this bug report. Either way, the output from lsusb works too. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1892581 Title: QEMU 5.1 no longer says anything about inaccessible devices Status in QEMU: New Bug description: Previously, with QEMU 5.0.0 running a VM with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb- host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio Would display something like the following: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. With insufficient permissions. QEMU 5.1.0 no longer displays anything. I did a git bisect and this is the result: [diego@thinkpad qemu]$ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) [diego@thinkpad qemu]$ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1892581/+subscriptions
[Bug 1892581] Re: QEMU 5.1 no longer says anything about inaccessible devices
Not sure this is a bug. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1892581 Title: QEMU 5.1 no longer says anything about inaccessible devices Status in QEMU: New Bug description: Previously, with QEMU 5.0.0 running a VM with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb- host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio Would display something like the following: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. With insufficient permissions. QEMU 5.1.0 no longer displays anything. I did a git bisect and this is the result: [diego@thinkpad qemu]$ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) [diego@thinkpad qemu]$ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1892581/+subscriptions
[Bug 1892581] Re: QEMU 5.1 no longer says anything about inaccessible devices
The previous commit is fine, it displays the USB errors: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1892581 Title: QEMU 5.1 no longer says anything about inaccessible devices Status in QEMU: New Bug description: Previously, with QEMU 5.0.0 running a VM with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb- host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio Would display something like the following: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. With insufficient permissions. QEMU 5.1.0 no longer displays anything. I did a git bisect and this is the result: [diego@thinkpad qemu]$ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) [diego@thinkpad qemu]$ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1892581/+subscriptions
[Bug 1892581] Re: QEMU 5.1 no longer says anything about inaccessible devices
My system is Arch Linux. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1892581 Title: QEMU 5.1 no longer says anything about inaccessible devices Status in QEMU: New Bug description: Previously, with QEMU 5.0.0 running a VM with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb- host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio Would display something like the following: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. With insufficient permissions. QEMU 5.1.0 no longer displays anything. I did a git bisect and this is the result: [diego@thinkpad qemu]$ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) [diego@thinkpad qemu]$ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1892581/+subscriptions
[Bug 1892581] Re: QEMU 5.1 no longer says anything about inaccessible devices
** Attachment added: "bisect-log.txt" https://bugs.launchpad.net/qemu/+bug/1892581/+attachment/5403655/+files/bisect-log.txt -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1892581 Title: QEMU 5.1 no longer says anything about inaccessible devices Status in QEMU: New Bug description: Previously, with QEMU 5.0.0 running a VM with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb- host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio Would display something like the following: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. With insufficient permissions. QEMU 5.1.0 no longer displays anything. I did a git bisect and this is the result: [diego@thinkpad qemu]$ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) [diego@thinkpad qemu]$ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1892581/+subscriptions
[Bug 1892581] [NEW] QEMU 5.1 no longer says anything about inaccessible devices
Public bug reported: Previously, with QEMU 5.0.0 running a VM with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb- ehci,id=ehci -device usb- host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio Would display something like the following: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. With insufficient permissions. QEMU 5.1.0 no longer displays anything. I did a git bisect and this is the result: [diego@thinkpad qemu]$ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) [diego@thinkpad qemu]$ ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1892581 Title: QEMU 5.1 no longer says anything about inaccessible devices Status in QEMU: New Bug description: Previously, with QEMU 5.0.0 running a VM with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -device usb-ehci,id=ehci -device usb- host,bus=ehci.0,vendorid=0x04f2,productid=0xb449 -device intel-hda -device hda-duplex -vga virtio Would display something like the following: libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. libusb: error [_get_usbfs_fd] libusb couldn't open USB device /dev/bus/usb/002/004: Permission denied libusb: error [_get_usbfs_fd] libusb requires write access to USB device nodes. With insufficient permissions. QEMU 5.1.0 no longer displays anything. I did a git bisect and this is the result: [diego@thinkpad qemu]$ git bisect bad 9f815e83e983d247a3cd67579d2d9c1765adc644 is the first bad commit commit 9f815e83e983d247a3cd67579d2d9c1765adc644 Author: Gerd Hoffmann Date: Fri Jun 5 14:59:52 2020 +0200 usb: add hostdevice property to usb-host The new property allows to specify usb host device name. Uses standard qemu_open(), so both file system path (/dev/bus/usb/$bus/$dev on linux) and file descriptor passing can be used. Requires libusb 1.0.23 or newer. The hostdevice property is only present in case qemu is compiled against a new enough library version, so the presence of the property can be used for feature detection. Signed-off-by: Gerd Hoffmann Message-Id: <20200605125952.13113-1-kra...@redhat.com> hw/usb/host-libusb.c | 75 ++-- hw/usb/trace-events | 1 + 2 files changed, 62 insertions(+), 14 deletions(-) [diego@thinkpad qemu]$ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1892581/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
Will the patch make it for 5.8? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
Yeah, I can reproduce the same exact behavior outside of QEMU with sway and it's consistent to what I observed in QEMU. > Hmm, happens with xorg only. I think you were right all along about this, sorry. Thanks for fixing this bug, feel free to close this bug as fixed. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
It looks like sway requires swayidle to wake up from sleep[1]. This works: swayidle timeout 2 'swaymsg "output * dpms off"' resume 'swaymsg "output * dpms on"' 1. https://github.com/swaywm/sway/issues/2914 ** Bug watch added: github.com/swaywm/sway/issues #2914 https://github.com/swaywm/sway/issues/2914 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
Sway log after the crash. ** Attachment added: "swaylog.txt" https://bugs.launchpad.net/qemu/+bug/1882851/+attachment/5383276/+files/swaylog.txt -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
Gerd, thanks. I can confirm your patch fixes the problem with X, but Wayland (sway) is still affected. I tested X and wayland, and while the "Guest disabled display" no longer hangs on X, it still does hangs under wayland. Should I bisect again? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
I just sanity checked, and can confirm the bad commit causes it, and going back one commit makes it work. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
** Attachment added: "bisectlog.txt" https://bugs.launchpad.net/qemu/+bug/1882851/+attachment/5383160/+files/bisectlog.txt -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
OK, I was able to bisect, here is the result: [diego@arch-zoom linux]$ git bisect bad 3954ff10e06e4fbc548fc02ff1fcaaac3228fed5 is the first bad commit commit 3954ff10e06e4fbc548fc02ff1fcaaac3228fed5 Author: Gerd Hoffmann Date: Thu Dec 12 13:53:44 2019 +0100 drm/virtio: skip set_scanout if framebuffer didn't change v2: also check src rect (Chia-I Wu). Signed-off-by: Gerd Hoffmann Reviewed-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20191212125346.8334-2-kra...@redhat.com drivers/gpu/drm/virtio/virtgpu_plane.c | 35 -- 1 file changed, 21 insertions(+), 14 deletions(-) [diego@arch-zoom linux]$ -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
I can reproduce it with current linux git master[1]. 1. git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
Gerd: I tried the LTS kernel on Arch Linux (5.4.46-1-lts) and I can't reproduce the bug with this kernel. It works as expected: `xset dpms force off' triggers the "Guest disabled display" and it disappears after moving the mouse. Could it be a regression in virtio_gpu? I guess I'll try the latest linux git and if it's an issue in master, I'll bisect it. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
> Hmm, happens with xorg only. Nope, I can reproduce it with sway as well (which is another Wayland compositor). To reproduce it with sway, just do: swaymsg "output * dpms off" and then should you see "Guest disabled display", at that point I'm unable to get back image. I tried the sendkey ctrl-alt-f2 and then switch back to TTY1 but the "Guest disabled display" remains. Can you please tell me which compositor you used? Thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
I can't wake up the screen after hitting keys or moving the mouse after turning off the screen with sway. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
`xset dpms force off' on the guest is a good way to reproduce it. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
My bad, the workaround works, it's just a bit tricky. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
Strange, that workaround doesn't work anymore. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] Re: QEMU video freezes with "Guest disabled display" (virtio driver)
OK, I found a workaround: sendkey ctrl-alt-f1 from the QEMU console (ctrl alt 2) then I can switch back to X and continue from where I left off. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Bug 1882851] [NEW] QEMU video freezes with "Guest disabled display" (virtio driver)
Public bug reported: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1882851 Title: QEMU video freezes with "Guest disabled display" (virtio driver) Status in QEMU: New Bug description: I am using Arch Linux as my Guest and Host OS, after starting qemu with the following command: $ qemu-system-x86_64 -enable-kvm -hda arch-zoom.qcow2 -m 4G -vga virtio and waiting for a screen blank, I get this message: Guest disabled display And nothing happens after that, I can move the mouse or hit any key, and the message is still there. I can still reboot the VM but that's not optimal. I can reproduce this with the latest QEMU release (5.0.0) or git master, I also tried this with older releases (4.0.0, 3.0.0) and the issue is still there. I can't reproduce this with other video drivers (std, qxl). With std/qxl the screen will blank a bit and then continue as normal. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1882851/+subscriptions
[Qemu-devel] [Bug 1781515] Re: Resolution switch leads to the screen/image being corrupted
Switching the resolution with -vga std was working fine before, I'm not sure on which version it started having this issue, but it should be on a recent version. I use the intel i915 drivers on the host OS. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1781515 Title: Resolution switch leads to the screen/image being corrupted Status in QEMU: New Bug description: I am currently using QEMU on a Arch Linux host, the guest OS is also Arch Linux. The QEMU version is currently 2.12.0-2 packaged by Arch Linux, the command line I'm using to fire an Arch VM is: $ qemu-system-x86_64 -enable-kvm -hda archlinux.qcow2 -m 4G -smp 4 The problem I'm currently having is, after firing the VM and running startx I want to change the resolution to the native resolution, which is 1366x768 on my ThinkPad T450, however, after changing the resolution the image on the guest gets corrupted and it's impossible to see anything. At this point I can only turn off the VM. The only workaround I found is to start the VM with -vga virtio. The problem in this case occurs with -vga std which is the default video driver. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1781515/+subscriptions
[Qemu-devel] [Bug 1781515] [NEW] Resolution switch leads to the screen/image being corrupted
Public bug reported: I am currently using QEMU on a Arch Linux host, the guest OS is also Arch Linux. The QEMU version is currently 2.12.0-2 packaged by Arch Linux, the command line I'm using to fire an Arch VM is: $ qemu-system-x86_64 -enable-kvm -hda archlinux.qcow2 -m 4G -smp 4 The problem I'm currently having is, after firing the VM and running startx I want to change the resolution to the native resolution, which is 1366x768 on my ThinkPad T450, however, after changing the resolution the image on the guest gets corrupted and it's impossible to see anything. At this point I can only turn off the VM. The only workaround I found is to start the VM with -vga virtio. The problem in this case occurs with -vga std which is the default video driver. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1781515 Title: Resolution switch leads to the screen/image being corrupted Status in QEMU: New Bug description: I am currently using QEMU on a Arch Linux host, the guest OS is also Arch Linux. The QEMU version is currently 2.12.0-2 packaged by Arch Linux, the command line I'm using to fire an Arch VM is: $ qemu-system-x86_64 -enable-kvm -hda archlinux.qcow2 -m 4G -smp 4 The problem I'm currently having is, after firing the VM and running startx I want to change the resolution to the native resolution, which is 1366x768 on my ThinkPad T450, however, after changing the resolution the image on the guest gets corrupted and it's impossible to see anything. At this point I can only turn off the VM. The only workaround I found is to start the VM with -vga virtio. The problem in this case occurs with -vga std which is the default video driver. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1781515/+subscriptions
[Qemu-devel] [Bug 1781515] Re: Resolution switch leads to the screen/image being corrupted
Hi Francisco, thanks for your quick reply. I've tried `xrandr --output Virtual-1 --mode 1360x768' with -vga std and I also get a corrupted image. I'm attaching a screenshot of what the screen corruption looks like after changing the resolution. Thanks. ** Attachment added: "qemu.png" https://bugs.launchpad.net/qemu/+bug/1781515/+attachment/5163111/+files/qemu.png -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1781515 Title: Resolution switch leads to the screen/image being corrupted Status in QEMU: New Bug description: I am currently using QEMU on a Arch Linux host, the guest OS is also Arch Linux. The QEMU version is currently 2.12.0-2 packaged by Arch Linux, the command line I'm using to fire an Arch VM is: $ qemu-system-x86_64 -enable-kvm -hda archlinux.qcow2 -m 4G -smp 4 The problem I'm currently having is, after firing the VM and running startx I want to change the resolution to the native resolution, which is 1366x768 on my ThinkPad T450, however, after changing the resolution the image on the guest gets corrupted and it's impossible to see anything. At this point I can only turn off the VM. The only workaround I found is to start the VM with -vga virtio. The problem in this case occurs with -vga std which is the default video driver. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1781515/+subscriptions
