Bug 1243646

This problem was originally reported against Fedora 20 but the same problem affects SSH connections between CentOS 7 systems. The issue is almost certainly the same and is allegedly fixed in current gtk3 git. This fix should be backported to RHEL7.

+++ This bug was initially created as a clone of Bug #1172337 +++

Description of problem:
I have a CentOS 7 virtual machine running under KVM on my local machine running F21 with Intel Haswell-based integrated graphics. I'm connecting into the VM via "ssh -X" and running some graphical applications. For some reason, some apps run incredibly slowly under this setup. For example, if you start up gedit and start typing some characters, the whole window seems to mostly stall for 30-60 seconds at a time. Eclipse also exhibits these huge pauses.

This problem did not occur when I was using a Scientific Linux 6 VM from the Fedora host. I tested it with a Fedora 20 VM as well and it had the same issue. Strangely enough, connecting into a CentOS 7 physical machine over the network didn't seem to have this problem, the GUI was responsive.

It seems like the combination of an F20/F21 host OS, modern Gnome 3-based guest, and connecting into the guest via SSH is what causes the problem. Based on the network traffic showing up in ifconfig on the guest, during these pauses there's hardly any traffic going across the network connection, so I don't think it's just bottlenecked on network bandwidth (not that this should be an issue anyways with a local connection). My only real theory at this point is that the particular timing of the SSH connection to a local VM is somehow causing issues.

It appears that some apps are affected more than others. The problem is quite apparent with gedit and gnome-calculator. Some others like gvim, however, have hardly any issues.

Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.16.2-1.fc21.x86_64

How reproducible:
Every time (for me anyway)

Steps to Reproduce:
1. Create and start up CentOS 7 KVM virtual machine (or Fedora 20 VM also seems to work) using NAT networking
2. ssh -X into VM using its NAT IP address (192.168.122.x) and run gedit
3. Type, open files, etc. in gedit

Actual results:
GUI stops responding for 30-60 second intervals.

Expected results:
GUI responds properly.

Additional info:
I have no idea if the X server is the cause of the problem, or whether the issue is even in the host and not the guest OS, but I wasn't sure where else to report this.

--- Additional comment from Robert Hancock on 2014-12-11 12:22:44 EST ---

It looks like this does not only affect connections to a local VM, but connections to another real computer over the network as well. I have been able to reproduce this by running gedit over an SSH connection from two computers running F21, both of which use Intel Haswell-based integrated graphics. On another F21 machine that used Nvidia graphics with the nouveau driver, I was NOT able to reproduce the problem.

So from what I can tell this problem seems to be graphics driver dependent, though it's still possible that this is a red herring.

--- Additional comment from Robert Hancock on 2014-12-11 12:26:07 EST ---

And the CentOS 7 part was also not relevant, as F21->F21 SSH connections have the same issue.

--- Additional comment from Robert Hancock on 2014-12-19 15:28:28 EST ---



--- Additional comment from Robert Hancock on 2014-12-19 15:29:00 EST ---



--- Additional comment from Robert Hancock on 2014-12-19 15:40:31 EST ---

I've attached the output of two test cases for this. Each involves logging into a CentOS 7 machine on the network with ssh -X, then running gedit under xtrace to capture all of the X events, and typing some characters into the window. In the working case, gedit works normally. In the failing case, gedit basically stops rendering after the first key is pressed and the text window doesn't update (though it still responds to the close button).

I have no idea why it consistently works on the one machine but fails on the other. The only difference I can see is that the machine I'm logging into in the working case is a fair bit slower. The faster machine is the one where gedit doesn't work properly. There also appear to be some ordering differences between the two files: in the working one, when the program sends requests to change the window title properties after the first key is pressed (to add the star to the title), it takes 7ms to get the PropertyNotify messages back (after a bunch of other render requests have already been sent), whereas in the broken case, it only took 1ms and there are very few rendering requests sent back after that. I'm wondering if one of these timing differences is causing the problem.

It also seems to be GTK3 apps specifically which have issues. So far, it appears that gedit and virt-manager have issues, but gvim (vim-X11), which uses gtk2, seems unaffected. So I'm reassigning this to gtk3.

--- Additional comment from Robert Hancock on 2014-12-23 12:20:12 EST ---

Also reported upstream. No response there either though.

--- Additional comment from Robert Hancock on 2015-05-29 11:35:42 EDT ---

Still occurring in F22.

--- Additional comment from Robert Hancock on 2015-07-15 22:43:04 EDT ---

Said to be fixed in gtk3 git:

https://git.gnome.org/browse/gtk+/commit/?id=6504b2e53468004c7936e7f79fba03291dc58128