Bug 139175
Summary: | xterm scrolling incredibly very slow | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Wayne Walker <wwalker> | ||||||||
Component: | xorg-x11 | Assignee: | X/OpenGL Maintenance List <xgl-maint> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | |||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 3 | CC: | dickey, kai | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | i686 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2005-04-11 14:15:27 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Wayne Walker
2004-11-13 17:20:10 UTC
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 xorg.conf files. 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 X11 changes. My video hardware on Sony Vaio PCG-Z505R notebook with 366 MHz Pentiun II CPU: 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: https://bugs.freedesktop.org/show_bug.cgi?id=1877 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 gtk2 issue. 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
real 0m2.993s
user 0m0.862s
sys 0m0.348s
~> time xterm +j -e ls /usr/bin
real 0m3.079s
user 0m0.780s
sys 0m0.290s
Now I try the same with the new driver in FC3:
~> time xterm -j -e ls /usr/bin
real 0m4.391s
user 0m0.675s
sys 0m0.160s
~> time xterm +j -e ls /usr/bin
real 1m20.284s
user 0m0.811s
sys 0m0.254s
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 my Thinkpad. But i tried the patch which is attached to freedesktop's bugzilla entry: https://bugs.freedesktop.org/show_bug.cgi?id=1877 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" |