Red Hat Bugzilla – Bug 139175
xterm scrolling incredibly very slow
Last modified: 2007-11-30 17:10:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
run a command like ls -l in both xterm and gnome-terminal
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open a gnome-terminal
2. cd /usr/bin
3. time ls -l
4. Open an xterm
5. Turn off jump scroll (Cntl-Middle mouse menu )
6. cd /usr/bin
7. time ls -l
Expected Results: The times should be on par with each other. xterm
was faster than gnome-terminal in FC2
Thinkpad 600X w/ 320 MB RAM and 650 MHz P3
To shut up my office mate, I reloaded from scratch insteadof the
upgrade I had had. The problem still exists.
Ihave tested on other machines, and the problem doesn't exist. I've
tested with other terminal emulators (aterm, eterm) on this machines.
No problem with them either. But I've been using xterm as my
emulator since 1990, so I'm sticking with it.
I was also hit by the same problem: after upgrading to FC3 from FC2
xterm stared to work incredibly slow on my 366 MHz Vaio notebook with
128 MB. Running it with nice -20 helps somewhat but still it is slower
then it was in FC3. Note that running "nice -20 ls" does not help at all.
It also seems that gnome-terminal scrolls slower then it was in FC2
but that is perhaps subjective.
I just tried xterm executable from FC2 and it experience the same slow
scrolling. So the problem is not in xterm changes.
When this is happening, the X process is using 96+% of the CPU, so the
problem must be in the X server. I will attach lspci output and my
Created attachment 107152 [details]
lspci -v output from a Thinkpad 600x
Created attachment 107153 [details]
xorg.conf from a Thinkpad 600x
Created attachment 107154 [details]
log from a Thinkpad 600x
Although there are PM events in the log the problem is present even from a
clean boot before any suspend events. So I doubt there are any problems
associated with power management.
I also switched from 24 planes to 16 planes. That had no appreciable
effect on the performance in xterm scrolling.
I booted with the last kernel from FC2 just to exclude the kernel
issue: it did not change scroll behaviour at all. On the other hand I
also see almost 100% CPU usage by X server. So the bug is related to
My video hardware on Sony Vaio PCG-Z505R notebook with 366 MHz Pentiun
NeoMagic MagicMedia 256AV (laptop/notebook)
I use 64K colors as with FC2 configuration.
In my case it is neomagic driver issue:
when I replaced /usr/X11R6/lib/modules/drivers/neomagic_drv.o with the
file from FC2 distro it made xterm to fly again. Restarting Xorg with
the FC3 version of the driver restored slow scrolling.
I reported the issue to freedesktop.org as:
I also had some scrolling issues on my Thinkpad 600x. I replaced the
neomagic driver with the one from fc2 (xorg-x11-6.7.0). Xterm is not
really faster than with the fc3 driver (it actually "looks" like, but
i can not measure any improvements with "time ls -la")
But i could increase scrolling speed in mozilla/firefox. With the fc3
driver i had some delays when scrolling in mozilla (xft/gtk2 build,
not in non-xft/gtk2 build). But with the old fc2 driver mozilla just
acts like i would expect.
So i think this is not only a Xorg driver issue but also a xft and/or
Kai Hambrecht wrote:
> Xterm is not really faster than with the fc3 driver (it actually
"looks" like, but i can not measure any improvements with "time ls -la")
xtrem use so called jump-scrolling by default, with the old driver I
have if I enable (-j option) / disable it (+j option):
~> time xterm -j -e ls /usr/bin
~> time xterm +j -e ls /usr/bin
Now I try the same with the new driver in FC3:
~> time xterm -j -e ls /usr/bin
~> time xterm +j -e ls /usr/bin
So the new driver caused "xtrem +j" which messures the real scrolling
performance to scroll 1m20s/3s = 17 times slower.
I've seen some comments that blame it on the changes to
scheduling in 2.6 kernels - but when I've tried to reproduce
it, have not seen the problem. If I could see it, there are
a few things that I could try to improve xterm's performance
based on those comments, but without something to measure
against, it's hard...
The fc2 driver, which is really several times faster than the fc3 one,
is not the best solution. Sometimes X freezes and i had to power-cycle
But i tried the patch which is attached to freedesktop's bugzilla
This patch greatly improves performance, so maybe it's worth it to
update the xorg-x11 packages.
We don't supply xterm in the xorg-x11 packages, it is it's own
standalone rpm. Changing component to xterm...
How does the saying go? "Assumption is the mother of evil"?
Due to the last few comments I assumed the patch being referenced
was an xterm patch, and commented first before reading the upstream
bug report. Immediately then I read the bug report to find a
non-xterm patch. ;o)
Reassigning back to xorg-x11. ;)
Can everyone CC'd on this bug report who experienced this problem
please indicate wether or not they are using "neomagic" video
hardware? If this is the case, this patch makes sense to go into
the upstream XORG-6_8-branch if it fixes the problem and does not
incur regression of any kind.
We'll review this again once everyone has repsponded letting us
know their video hardware.
Thanks again folks.
Boy, aren't I the observant one today. The last comment in the
upstream report clearly indicates this is already in the upstream
6.8 CVS branch. Duh.
Clearly there is something awry with my water filter.
Since we are going to be providing 6.8.2 as an update to FC3, this
problem should be fixed automatically when we update, at least for
neomagic users. I'll leave this open for now however so everyone
can still provide their video hardware info, and so I can get
everyone to test 6.8.x from rawhide, or when we release the
erratum in the next month or so.
Sorry for all the noise. ;)
This is my hardware:
IBM Thinkpad 600X
(--) PCI:*(1:0:0) Neomagic Corporation NM2360 [MagicMedia 256ZX] rev 0
(II) NEOMAGIC(0): VESA VBE Total Mem: 4032 kB
We've released 6.8.2 as an update to FC3 now, so this issue should be
resolved. If the problem recurs however, please report a bug in X.Org
bugzilla at http://bugs.freedesktop.org in the "xorg" component.
Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.
Setting status to "ERRATA"