Bug 871240 - Guest is unsuspended (S3) if remote-viewer window is closed
Guest is unsuspended (S3) if remote-viewer window is closed
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: spice (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Christophe Fergeau
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-29 22:44 EDT by Cole Robinson
Modified: 2015-03-27 08:39 EDT (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-27 08:39:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
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 <marcandre.lureau@gmail.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

Note You need to log in before you can comment on or make changes to this bug.