xorg is terribly slow after Intrepid -> Jaunty upgrade

Bug #334066 reported by Iain Lane
36
This bug affects 3 people
Affects Status Importance Assigned to Milestone
xorg (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: xorg

After upgrading the xserver is unbearably slow - so slow as to make the desktop almost unusable. Actions which involve redrawing windows seem to be particularly slow - resizing windows, moving them, switching back to a desktop with windows.

This happens both with -ati and -fglrx drivers and with kernels 2.6.26 and 2.6.28. Downgrading to Intrepid's xserver resolves the issue. I would bisect but I have trouble building the git versions (dependency problems).

CPU usage seems to hover around 20-30% when I'm not interacting with anything, jumping to 85% when I am.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
NonfreeKernelModules: fglrx
Package: xserver-xorg 1:7.4~5ubuntu12
ProcEnviron:
 PATH=(custom, user)
 LANG=en_GB.UTF-8
 SHELL=/usr/bin/zsh
ProcVersion: Linux version 2.6.28-8-generic (buildd@yellow) (gcc version 4.3.3 (Ubuntu 4.3.3-3ubuntu5) ) #25-Ubuntu SMP Tue Feb 24 01:50:03 UTC 2009
SourcePackage: xorg
Uname: Linux 2.6.28-8-generic x86_64
XorgConf:
 Section "ServerFlags"
  Option "DontZap" "False"
 EndSection
glxinfo:

Revision history for this message
Iain Lane (laney) wrote :
Revision history for this message
Iain Lane (laney) wrote :

I ran strace for a little while while moving windows around and interacting with my gnome-do dock - actions which run particularly slowly.

laney@chicken> sudo strace -v -f -c -p 6314 ~
Process 6314 attached - interrupt to quit
^CProcess 6314 detached
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
 87.66 0.012273 1 15313 238 select
  9.11 0.001275 0 17477 6132 read
  1.97 0.000276 0 8432 writev
  0.92 0.000129 0 13416 setitimer
  0.13 0.000018 1 31 stat
  0.12 0.000017 1 31 accept
  0.09 0.000013 0 3448 241 rt_sigreturn
  0.00 0.000000 0 31 close
  0.00 0.000000 0 238 poll
  0.00 0.000000 0 1687 rt_sigprocmask
  0.00 0.000000 0 5 ioctl
  0.00 0.000000 0 31 shutdown
  0.00 0.000000 0 62 fcntl
------ ----------- ----------- --------- --------- ----------------
100.00 0.014001 60202 6611 total

description: updated
Revision history for this message
Iain Lane (laney) wrote :

Not an xorg bug. If I disable metacity compositing then speed is normal once more.

Changed in xorg:
status: New → Invalid
Revision history for this message
j.scott.gwin@gmail.com (j.scott.gwin) wrote :

I have the same problem in jaunty kubuntu. kde-workspace is very slow after upgrade from intrepid. CPU% minus HTOP hovers around 20-25%.

Revision history for this message
Tim Holy (holy-wustl) wrote :

Seemingly the same issue. Jaunty Kubuntu, Thinkpad T60 core duo, happens only when desktop effects are enabled. I'm running with no xorg.conf, using the radeon driver.

The system becomes so slow that it responds only to the power button :-).

I was able to SSH in from another machine, and got something along the lines of the following from "top":
Xorg: 100%cpu
hald-addon-stor: 50%cpu
top: 50%cpu

Obviously, nothing else was using significant CPU. I was surprised at top needing half a CPU (usually it's a few percent). No noteworthy memory usage by anything.

Revision history for this message
Tim Holy (holy-wustl) wrote :

I should also have specified two other things:
1. By saying "same thing here" I meant "system becomes unbearably slow"; since I'm not running Gnome, I don't think the metacity thing is related to my problem.

2. Here's the output of lspci:
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express PCI Express Root Port (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400
02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
15:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller

Revision history for this message
Dana Goyette (danagoyette) wrote :

This also happens for me (Mobility HD3650 with fglrx): any sort of new window creation -- including simple un-minimizing -- takes about 1 full second of doing nothing, during which time compiz or metacity-with-composite hangs, and Xorg eats 100% of one CPU core. Oddly enough, the animations themselves work fine. This seems relatively recent -- it has only started happening for me within the last month.

Revision history for this message
Tim Holy (holy-wustl) wrote :

Just to clarify: for me, it essentially locks the machine hard. It doesn't respond to anything: CTRL-ALT-DELETE, CTRL-ALT-BACKPACE, or even the SysRq keys. I've waited as long as 15 minutes to see if it would eventually respond to one of these key combinations before hitting the power button.

However, I can SSH in to the machine successfully; it's slow, but I can execute command-line functions (I didn't try X forwarding, assuming it wouldn't work).

Revision history for this message
Richard Smith (richard-launchpad) wrote :

I have an ATi Mobility X1400 GPU (Thinkpad Z61m) and I see the following:

* The fglrx driver refuses to start, saying "No screens found"
* With the radeon / ati driver plus the 2.6.28 kernel, I get a hard lockup in X shortly after it starts. My system responds to SysRq.
* Rolling back to the 2.6.27 kernel which I was using with intrepid, I have a working X environment, but only if I disable Xinerama and DRI.
* With Xinerama enabled, using the radeon driver and a 2.6.27 kernel, I get a segfault on X startup:

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x26) [0x4f1b66]
1: /usr/bin/X(xf86SigHandler+0x41) [0x485a61]
2: /lib/libc.so.6 [0x7f1a98db1040]
3: /usr/bin/X(dixLookupPrivate+0x4) [0x4347f4]
4: /usr/bin/X(xf86RandR12CreateScreenResources+0x50) [0x4b58e0]
5: /usr/bin/X [0x4abb8f]
6: /usr/bin/X(main+0x264) [0x433c34]
7: /lib/libc.so.6(__libc_start_main+0xe6) [0x7f1a98d9c5a6]
8: /usr/bin/X [0x433219]
Saw signal 11. Server aborting.

I also got a similar segfault (slightly different backtrace mentioning DRI) with 'Option "DRI"' in my xorg.conf -- but I can't be sure that wasn't also triggered by Xinerama.

I'm attaching the failsafeX tarball from the segfaulting run.

Revision history for this message
Richard Smith (richard-launchpad) wrote :

The hard lockup in X I'm seeing is always just after the KWallet dialog appears asking me for my passphrase. Perhaps this is triggering some kind of composite event which is causing the lockup?

Revision history for this message
deric (barton-tomas) wrote :

Same issue on Dell Latitude D620 (Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller) Jaunty Kubuntu

top:
VIRT | RES | SHR | S | %CPU | %MEM | TIME+ | COMMAND
690m | 165m | 8400 | R | 65 | 8.2 | 90:10.59 | Xorg

Rendering windows is unbeareably slow especially when swiching desktop

Revision history for this message
deric (barton-tomas) wrote :

after disabling desktops effects it is possible to work...

this one is quite bad :-/
$ glxgears

351 frames in 5.1 seconds = 68.535 FPS
631 frames in 5.0 seconds = 126.155 FPS
662 frames in 5.0 seconds = 132.250 FPS
596 frames in 5.1 seconds = 117.785 FPS
353 frames in 5.0 seconds = 70.579 FPS

Revision history for this message
Andy Walker (walkeraj) wrote :

I am running xubuntu with no kind of compositing enabled whatsoever and am experiencing dramatically reduced performance after upgrading to jaunty on my Thinkpad X31. Re-opening bug.

Changed in xorg (Ubuntu):
status: Invalid → New
Revision history for this message
Andy Walker (walkeraj) wrote :

On second thought, I'm going to submit this as an Xubuntu-specific bug. I can get xorg to spike to %50+ usage simply by holding down enter in a session of xfce4-terminal, yet it does not do this with xterm.

Changed in xorg (Ubuntu):
status: New → Invalid
Revision history for this message
David Huggins-Daines (dhuggins) wrote :

I can't see why this would be xubuntu specific. I am having this exact problem with GNOME on a Thinkpad X31. X is horribly slow after upgrading, to the point where there is a delay in drawing letters as I type this, and the CPU usage is spiking to 100%.

And it looks like others are experiencing it too. Why is it invalid?

Here is my Xorg.0.log for what it's worth.

Revision history for this message
David Huggins-Daines (dhuggins) wrote :

Another data point - this isn't Gnome related. When running icewm it's not quite as bad since there aren't as many things using the X server, but just running 'top' in a terminal takes 20-30% of CPU. As I said before, it seems as if X is not using any acceleration on radeon cards.

Changed in xorg (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
busymind (ailuparu) wrote :

Kubuntu instaled the processor was 90% on Xorg. Clean reinstall Jaunty Jackalope Gnome xorg very slow. Changed the window appearence (Clearlooks) an no picture on desktop. Seems to go faster but not at the speed on Intrepid.

00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01)
01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 Go AGP 8x] (rev a1)
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705M Gigabit Ethernet (rev 01)
02:01.0 CardBus bridge: Texas Instruments PCI7510 PC card Cardbus Controller (rev 01)
02:01.1 CardBus bridge: Texas Instruments PCI7510,7610 PC card Cardbus Controller (rev 01)
02:01.2 FireWire (IEEE 1394): Texas Instruments PCI7410,7510,7610 OHCI-Lynx Controller
02:01.3 System peripheral: Texas Instruments PCI7410,7510,7610 PCI Firmware Loading Function

Revision history for this message
Jussi Talaskivi (jptalask) wrote :

I'm not sure this bug is a duplicate. At least the fix in the parent bug doesn't fix this (by using Mesa found in radeon crack -meta testing ppa). Only thing I've managed to do to prevent the locking is to disable DRI with NoDRI optin in the xorg.conf.

Revision history for this message
Tormod Volden (tormodvolden) wrote :

Jussi, this bug report has just become a sink for all kind of issues, and the original reporter did not mention any locking. Please file a new bug.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.