Bug 486049 - Xorg seems slower in rawhide than in F10
Summary: Xorg seems slower in rawhide than in F10
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: rawhide
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Dave Airlie
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-18 01:17 UTC by François Cami
Modified: 2009-05-06 20:37 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-06 20:37:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg log on rawhide (49.16 KB, text/plain)
2009-02-18 01:17 UTC, François Cami
no flags Details
sysprof log on F10 (31.28 KB, text/plain)
2009-02-18 01:17 UTC, François Cami
no flags Details
sysprof log on rawhide (39.83 KB, text/plain)
2009-02-18 01:18 UTC, François Cami
no flags Details
dmesg sysrq-w output (16.00 KB, text/plain)
2009-03-17 13:22 UTC, e
no flags Details

Description François Cami 2009-02-18 01:17:08 UTC
Created attachment 332319 [details]
Xorg log on rawhide

Description of problem:
During some operations (switching virtual desktops with some overlapping windows for instance), Xorg seems slower in rawhide than in F10 (nomodeset in both cases). Athlon X2 BE-2400, FireGL V7100 (X800XT) running x86_64.

Version-Release number of selected component (if applicable):
kernel-2.6.29-0.124.rc5.fc11.x86_64
mesa-libGL-7.3-2.fc11.x86_64
xorg-x11-drv-ati-6.10.0-3.fc11.x86_64
xorg-x11-server-Xorg-1.5.99.902-12.fc11.x86_64


How reproducible:
Always

Steps to Reproduce:
1. open xchat in a virtual desktop with one gnome-terminal over it
2. open gnome-term full screen in the next VD with two other gnome terms over it
3. open firefox with two tabs (any website will do)
4. open claws-mail on last virtual desktop
5. note, gnome-terminal and xchat both have transparency active
6. switch virtual desktops back and forth

Actual results:
on F10 : switching is mostly fine
on rawhide : switching can lag a lot, window redrawing is clearly visible

Expected results:
no perceptible lag

Comment 1 François Cami 2009-02-18 01:17:57 UTC
Created attachment 332320 [details]
sysprof log on F10

Comment 2 François Cami 2009-02-18 01:18:27 UTC
Created attachment 332322 [details]
sysprof log on rawhide

Comment 3 François Cami 2009-02-18 01:20:09 UTC
The two sysprof logs were taken using the same "route" accross the virtual desktops and the applications, staying about one second per desktop to make sure all windows were correctly drawn.

Comment 4 Mads Kiilerich 2009-02-18 15:52:39 UTC
I can confirm behaviour that feels similar to this but with
VGA compatible controller: ATI Technologies Inc RV516 [Radeon X1300/X1550 Series]
kernel-2.6.29-0.124.rc5.fc11.i586 (no nomodesetting but no KMS)
xorg-x11-drv-ati-6.10.0-3.fc11.i586 (no xorg.conf)

Comment 5 François Cami 2009-02-22 14:59:42 UTC

Similar to bug 486368 .
Keeping both because of different hardware (RV516 vs R420).

Comment 6 e 2009-03-17 13:20:53 UTC
I am also observing very poor performance with:

01:00.0 VGA compatible controller: ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)] (prog-if 00 [VGA controller])
	Subsystem: Giga-byte Technology Device 2106
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at 80000000 (64-bit, prefetchable) [size=128M]
	Memory at 88100000 (64-bit, non-prefetchable) [size=64K]
	I/O ports at 2000 [size=256]
	Expansion ROM at 88120000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Express Endpoint, MSI 00
	Capabilities: [80] MSI: Mask- 64bit+ Count=1/1 Enable-
	Kernel driver in use: radeon
	Kernel modules: radeon

01:00.1 Display controller: ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)] (Secondary)
	Subsystem: Giga-byte Technology Device 2107
	Flags: bus master, fast devsel, latency 0
	Memory at 88110000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Express Endpoint, MSI 00

Single DVI monitor attached. No Xorg.conf used.

Depending on what I am doing, it may take a couple of hours for the
problem to manifest. When the problem occurs:
 - the seconds display of the gnome clock applet can skip 3-4 seconds
   between updates.
 - Output from other X clients (like system monitor) is also frozen.
 - Key strokes get lost.

The applications that particularly seem to trigger it are:
 - Firefox when scrolling through a large media rich page like http://smh.com.au
 - Banshe when adjusting the separator between the artist/track panes
 - Switching between gnome-terminal tabs
 - Virtual desktop switching

I initially thought that logging out/in was fixing the problem, but it
does not. Rebooting seems to be required.

kernel-2.6.29-0.237.rc7.git4.fc11.x86_64
xorg-x11-drv-ati-6.11.0-10.fc11.x86_64

Comment 7 e 2009-03-17 13:22:12 UTC
Created attachment 335523 [details]
dmesg sysrq-w output

Two instances of the output of sysrq-w when the desktop was being unresponsive.

Comment 8 e 2009-03-19 10:47:27 UTC
More debug info:

Running kernel-2.6.29-0.237.rc7.git4.fc11.x86_64 I attached strace to the X
server when it was playing up. The trace showed the delays with two ioctl
calls taking more than 3 seconds to return!

21:25:14.742674 ioctl(9, 0xc020645e, 0x7fff6656b2e0) = 0 <0.000048>
21:25:14.742860 ioctl(9, 0xc0106466, 0x7fff6656b280) = 0 <3.000335>
21:25:17.743392 --- SIGUSR1 (User defined signal 1) @ 0 (0) ---

and another a bit later:

21:25:18.072420 ioctl(9, 0xc020645d, 0x7fff6656b570) = 0 <0.000147>
21:25:18.072718 ioctl(9, 0xc0106466, 0x7fff6656b380) = 0 <3.014397>
21:25:21.087296 --- SIGALRM (Alarm clock) @ 0 (0) ---

FD 9 is /dev/dri/card0 according to lsof.

I've now upgraded to 2.6.29-0.258.rc8.git2.fc11.x86_64. Will watch for
further problems.

Dave: Is there any debugging information/process that I can provide/follow
to help you narrow down this problem ?

Comment 9 François Cami 2009-05-06 20:37:17 UTC
Fixed as of 
kernel-2.6.29.2-129.fc11.x86_64
xorg-x11-drv-ati-6.12.2-9.fc11.x86_64
mesa-libGL-7.5-0.14.fc11.x86_64
mesa-dri-drivers-7.5-0.14.fc11.x86_64

(much earlier, in fact).

Closing.


Note You need to log in before you can comment on or make changes to this bug.