Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Guest is unsuspended (S3) if remote-viewer window is closed|
|Product:||[Fedora] Fedora||Reporter:||Cole Robinson <crobinso>|
|Component:||spice||Assignee:||Christophe Fergeau <cfergeau>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||alexl, amit.shah, berrange, cfergeau, dblechte, dwmw2, hdegoede, itamar, jforbes, kem, knoel, kraxel, marcandre.lureau, pbonzini, ricardo.arguello, rjones, scottt.tw, uril, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-03-27 08:39:41 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Cole Robinson 2012-10-29 22:44:49 EDT
On F18 with an F18 guest: - Open virt-manager, start the VM, log in. - Run pm-suspend - Watch the guest pause and stop, but leave the spice window open. - Close the spice window - The guest resumes Doesn't seem like a good thing to me, since it basically means you can't leave virt-manager without unsuspending your guest.
Comment 1 Cole Robinson 2012-10-29 22:45:27 EDT
Using spice + qxl FWIW
Comment 2 Cole Robinson 2013-09-09 10:16:59 EDT
I can still reproduce with rawhide qemu and remote-viewer, using this command line: ./x86_64-softmmu/qemu-system-x86_64 -m 4096 -enable-kvm -cpu host -cdrom /mnt/data/devel/media/Fedora-18-x86_64-Live-Desktop.iso -vga qxl -spice port=5901,disable-ticketing However it doesn't seem to reproduce using cirrus and vnc. So not sure if this is remote-viewer, spice-gtk, spice, or qemu which is causing this. Reassigning to spice-gtk
Comment 3 Marc-Andre Lureau 2013-09-09 11:43:32 EDT
I can reproduce easily, though I don't think spice-gtk is reponsible, since killing it just resume the guest as well, it's probably some server behaviour, but I haven't found the root cause yet.
Comment 4 Marc-Andre Lureau 2013-10-03 10:46:26 EDT
There seems to be the cause. Working on a fix. #0 runstate_set (new_state=RUN_STATE_RUNNING) at vl.c:606 #1 0x00007f926f0bdb18 in qemu_system_wakeup_request (reason=reason@entry=QEMU_WAKEUP_REASON_OTHER) at vl.c:1882 #2 0x00007f926f007b82 in ps2_put_keycode (opaque=0x7f9271e96c20, keycode=56) at hw/ps2.c:158 #3 0x00007f9268e471bf in inputs_channel_handle_parsed () from /lib64/libspice-server.so.1 #4 0x00007f9268e4e4be in red_channel_client_receive () from /lib64/libspice-server.so.1 #5 0x00007f9268e5055c in red_channel_client_event () from /lib64/libspice-server.so.1 #6 0x00007f926f04fca7 in qemu_iohandler_poll (readfds=readfds@entry=0x7f926f9e14c0 <rfds>, writefds=writefds@entry=0x7f926f9e1440 <wfds>, xfds=xfds@entry=0x7f926f9e13c0 <xfds>, ret=ret@entry=1) at iohandler.c:159 #7 0x00007f926f05554e in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:417 #8 0x00007f926ef2f9e5 in main_loop () at vl.c:2001 #9 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4326 Breakpoint 3, inputs_channel_on_disconnect (rcc=0x7f9271ef6840) at inputs_channel.c:482 482 inputs_relase_keys(); (gdb) bt #0 inputs_channel_on_disconnect (rcc=0x7f9271ef6840) at inputs_channel.c:482 #1 0x00007f9268e4e6b1 in red_peer_handle_incoming (handler=0x7f9271efa950, stream=0x7f9271e9e290) at red_channel.c:300 #2 red_channel_client_receive (rcc=rcc@entry=0x7f9271ef6840) at red_channel.c:309 #3 0x00007f9268e5055c in red_channel_client_event (fd=<optimized out>, event=1, data=0x7f9271ef6840) at red_channel.c:1436 #4 0x00007f926f04fca7 in qemu_iohandler_poll (readfds=readfds@entry=0x7f926f9e14c0 <rfds>, writefds=writefds@entry=0x7f926f9e1440 <wfds>, xfds=xfds@entry=0x7f926f9e13c0 <xfds>, ret=ret@entry=1) at iohandler.c:159 #5 0x00007f926f05554e in main_loop_wait (nonblocking=<optimized out>) at main-loop.c:417 #6 0x00007f926ef2f9e5 in main_loop () at vl.c:2001 #7 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4326
Comment 5 Marc-Andre Lureau 2013-10-03 10:52:23 EDT
So it is not so obvious what should be the solution. Otoh, qemu wakes up on keyboard events, which sounds reasonable. Otoh, spice-server make sure to release modifiers keys. Perhaps the server should track modifier state and only release when necessary?
Comment 6 Marc-Andre Lureau 2013-10-04 10:15:05 EDT
Doing testing, I noted that win7 will go to sleep even when keyboard is pressed, and a key release event will wakeup the VM, but win7 doesn't process that event. So it will remain as if the key was pressed... I wonder if a bare-metal win7 behaves similarly.
Comment 7 Marc-Andre Lureau 2013-10-04 12:52:08 EDT
proposed solution: http://lists.freedesktop.org/archives/spice-devel/2013-October/014741.html
Comment 8 Cole Robinson 2013-12-17 15:44:07 EST
Upstream as: commit 2d28da3c17f115fb1be4e5045e4a7a67fd1158b9 Author: Marc-André Lureau <email@example.com> Date: Fri Oct 4 18:48:41 2013 +0200 server: release all pressed keys on client disconnect
Comment 9 Hans de Goede 2014-03-17 05:03:18 EDT
Resetting all spice bugs to their default assignee, as I'm no longer in the Spice team.
Comment 10 Hans de Goede 2014-03-17 05:09:42 EDT
(In reply to Hans de Goede from comment #9) > Resetting all spice bugs to their default assignee, as I'm no longer in the > Spice team. Ok that does not work, as it seems I'm still the owner lets fix that first.
Comment 11 Fedora Admin XMLRPC Client 2014-03-17 05:25:35 EDT
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 12 Cole Robinson 2015-03-27 08:39:27 EDT
Pretty sure this is long since in f20+, so closing