Description of problem: Redrawing windows is visibly faster when booting with radeon.modeset=0. Scrolling text input areas in Firefox is particularly slow without that. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.6.99-36.20090814.fc12.x86_64 xorg-x11-drv-ati-6.12.2-21.fc12.x86_64 kernel-2.6.31-0.162.rc6.git2.fc12.x86_64 How reproducible: 100% Steps to Reproduce: 1.Boot as normal (i.e. without radeon.modeset=0). 2.Drag windows around the screen. 3.Boot with radeon.modeset=0 on the kernel command line 4.Compare Actual results: Much faster with radeon.modeset=0. Expected results: Fast even with modesetting. :-)
Created attachment 358197 [details] Xorg.0.log-drm.debug=1 Xorg.0.log from a boot with drm.debug=1 (and not radeon.modeset=0).
Created attachment 358198 [details] dmesg dmesg from booting with drm.debug=1 (and not radeon.modeset=0).
Created attachment 358200 [details] /var/log/messages /var/log/messages from booting with drm.debug=1 (and not radeon.modeset=0). Rsyslog is configured to store debug level messages there too.
Created attachment 358201 [details] Xorg.0.log-radeon.modset=0 Xorg.0.log from booting with radeon.modeset=0
seeing similar behaviour here on T60p with V5200 graphics. 200-600 FPS with kernel modesetting, back to 1300-1500 when disabled
Further "general use" with kms enabled results in extremely slow UI response. Window movements are very jerky (redraw), just minimizing takes > 1s to repaint. Effectively near unusable. glxgears (albeit artifical test) appears to get slower the longer the system up / more windows open. Currently mine's down to ~150. Can provide additional logs if required, but sounds like the same issue. Did note that with kms disabled (radeon.modeset=0) that after a suspend/resume cycle "vbetool" would be spinning cpu cycles, and if killed would just call another suspend. Will try to reconfigure around it. Currently using kernel-2.6.31-0.190.rc8.fc12.i686 xorg-x11-drv-ati-6.13.0-0.2.20090821gitb1b77a4d6.fc12.i686 tried backing driver off to xorg-x11-drv-ati-6.12.2-21.fc12.i686 (alpha level) but made no difference System is F12 alpha, updated with rawhide updates with no packages held back due to dependency issues, ie updates running clean as of 2 Sep 0630 UTC+1
Further observation. Went back to having modeset enabled, and got vbetool spinning. Moved /usr/sbin/vbetool to vbetool.bad No longer any spinning. After resume could unlock X, although VT switching did not work However even with modesetting enabled, prior to suspend/resume was getting 2000 fps in glxgears, now getting ~800 with nothing else significant running.
Have been running back with KMS enabled for a few weeks now, and this performance problem has not re-appeared, so looks like it's now fixed.
Thank you for reporting back.