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
Created attachment 332320 [details] sysprof log on F10
Created attachment 332322 [details] sysprof log on rawhide
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.
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)
Similar to bug 486368 . Keeping both because of different hardware (RV516 vs R420).
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
Created attachment 335523 [details] dmesg sysrq-w output Two instances of the output of sysrq-w when the desktop was being unresponsive.
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 ?
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.