Bug 871240 - Guest is unsuspended (S3) if remote-viewer window is closed
Summary: Guest is unsuspended (S3) if remote-viewer window is closed
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: spice
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Christophe Fergeau
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-30 02:44 UTC by Cole Robinson
Modified: 2015-03-27 12:39 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-27 12:39:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Cole Robinson 2012-10-30 02:44:49 UTC
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-30 02:45:27 UTC
Using spice + qxl FWIW

Comment 2 Cole Robinson 2013-09-09 14:16:59 UTC
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 15:43:32 UTC
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 14:46:26 UTC
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 14:52:23 UTC
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 14:15:05 UTC
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 16:52:08 UTC
proposed solution:
http://lists.freedesktop.org/archives/spice-devel/2013-October/014741.html

Comment 8 Cole Robinson 2013-12-17 20:44:07 UTC
Upstream as:

commit 2d28da3c17f115fb1be4e5045e4a7a67fd1158b9
Author: Marc-André Lureau <marcandre.lureau>
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 09:03:18 UTC
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 09:09:42 UTC
(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 09:25:35 UTC
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 12:39:27 UTC
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.