Bug 140141

Summary: large amounts of scrolling data over an ssh conenction cause 100% util.
Product: [Fedora] Fedora Reporter: Gordon Ewasiuk <gewasiuk>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-05 15:44:22 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
dmesg, rpm versions, uname, ssh_config none

Description Gordon Ewasiuk 2004-11-19 21:11:01 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
Scrolling large amounts of data through ssh while connected to a
remote server results in 100% CPU and scrolling text to repeat itself
over and over.  The only way to stop the text is to kill the
gnome-terminal from which ssh was started.

From my desktop (FC3), I ssh'ed to another FC3 server.  I ran 'amadmin
standard info'.  The resulting output is very large and caused 100%
cpu util on my desktop.  The output also stopped scrolling data and
repeated a small portion of the data over and over.

From my desktop (FC3), I ssh'ed to the same remote FC3 server.  I ran
'ls -laR' from / on the remote server.  The resulting output caused
the same 100% cpu util and repeating data.

From my desktop (FC3), I run 'ls -laR' from a gnome-terminal as root.
 No problems observed.

From my desktop (FC3), I ssh'ed to an FC2 server.  I ran the same 'ls
-laR' from / on the FC2 server.  The resulting output caused the same
100% cpu util and repeated a portion of the output over and over.

From my desktop (FC3), I ssh'ed to an FC1 server.  Same commands were
run.  Same results.

From my desktop (FC3), I ssh'ed to an RH9 server running 2.4.20-31.9
and openssh-3.5p1-11.  Same commands were run.  No problems observed.
 Output scrolled cleanly and without error or repeating data.  CPU
utilization on my desktop was normal.

From a remote FC3 box, I connected to an FC2 box.  Ran same commands.
 Got 100% cpu utilization and output problems again.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. ssh to a remote Fedora server
2. run 'ls -laR' from /

Actual Results:  100% cpu utilization 
 2811 root      25   0 31488  21m  13m R 42.6  4.3  57:58.71 X
13521 gewasiuk  16   0 46524  21m  21m S 24.5  4.3   0:48.14
14012 gewasiuk  15   0  6404 1820 3832 S 18.5  0.4   0:06.98 ssh

Expected Results:  output should scroll cleanly without repeating a
portion of the data
cpu utilization should not spike

Additional info:

Can reproduce problem from my FC3 desktop when connecting to a Sun
server running Solaris 2.7 and openssh 3.0.2p1.
Comment 1 Gordon Ewasiuk 2004-11-19 21:14:50 EST
Created attachment 107109 [details]
dmesg, rpm versions, uname, ssh_config

file contains dmesg, uname, rpm versions of modules involved, and my
Comment 2 Sitsofe Wheeler 2004-11-20 12:50:05 EST
Do you have the same high cpu load when you use a plain old xterm? If
not then this is a gnome-terminal bug.
Comment 3 Gordon Ewasiuk 2004-11-23 21:25:34 EST
Ugh.  I should have checked gnome-terminal first.  Looks like it is a
gnome-terminal bug.  I tested by ssh'ing to an FC3 server then ssh'ing
from that FC3 server to another FC3 server.  Xterm was used
throughout.  No problems noted with scrolling text.

Comment 4 Sitsofe Wheeler 2004-11-25 11:11:56 EST
This was the closest matching bug that I could find was bug 132770
(although it doesn't explicitly mention network/ssh traffic)
Comment 5 Gordon Ewasiuk 2004-12-28 17:56:04 EST
please close this bug.  problem is fixed with gnome-terminal 2.8.0
Comment 6 Gordon Ewasiuk 2005-02-03 04:28:45 EST
problem still exists.  problem isn't specific to gnome-terminal or
xterm.  both will hang.  ssh from FC3 GNOME desktop to a remote FC3,
FC3, FC1, or RH9 server.  cd to /.  ls -lR results in session hanging
and the same text repeating over and over.  CPU utilization on FC3
desktop spikes to 70-80%.  Session will display same text over and
over until session is killed.  this problem is specific to ssh.  the
problem does NOT exist when using the same servers and telnet.

tried disabling X11 forwarding on local and remote host.  same problem.

problem exists in KDE and XFCE.  Problem isn't specific to a
particular video card or server.  Tried ATI and Nvidia.

I'm stumped.  This is a damned annoying problem...but I haven't found
any reports from other people with the same symptoms.
Comment 7 Tomas Mraz 2005-04-05 15:44:22 EDT
I too cannot reproduce it, I'm sorry. You could try to upgrade to openssh-4.0p1
from FC development. However you will need to rebuild it on your machine.
Otherwise you would have to upgrade many more packages to FC development.
Comment 8 Gordon Ewasiuk 2005-04-05 21:26:27 EDT
I just tested this from RHEL4 WS.  The bug is there, I swear. :)  Using
gnome-terminal-2.7.3-1, openssh-3.9p1-8.RHEL4.1, and xterm-192-1.  Steps to

ssh from RHEL4 WS to fc3 server
cd /
ls -lR
screen will display same text over and over.  CPU on RHEL4 WS spikes to 75%

ssh from RHEL4 WS to fc1 server
login as root, cd /
ls -lR
same result

now, get this:

ssh from FC3 workstation to RHEL4 WS
login as root, cd /
ls -lR
everything works properly.

what gives?
Comment 9 Tomas Mraz 2005-04-06 03:31:38 EDT
As I cannot reproduce it -> cannot fix it, I'm really sorry. 
Could you try to install the latest kernel from FC3 updates and openssh from FC3
updates on the RHEL4 WS and try if one of these packages solve the problem. Also
if these don't help you could try to rebuild the openssh-4.0p1 from FC
development on your system and install this and try again.
Comment 10 Tomas Mraz 2005-04-06 03:36:25 EDT
And another question - are these machines on the same ethernet or are between
them any routers? And is the problematic machine always the same (first with FC3
then with RHEL4 WS?)
Comment 11 Gordon Ewasiuk 2005-04-07 04:21:26 EDT
Hi Tomas.  Thank you for looking into this problem.  It has been very annoying.
 :)  The problem is solved with FC4 T1.  The machines are on the same IP
network.  They are connected to same switch.  I didn't do FC3 kernel/openssh
upgrade to my RHEL4 WS because my workstation is in production and I didn't want
to mix development RPMs with production RPMs.  I am satisfied with FC4 being the
fix if you want to close this... Thanks again.