Created attachment 343269 [details] Xorg.0.log for savage driver 2.2.1 with DRI enabled Description of problem: After updating to version 2.2.1 of the "savage" driver, DRI is not broken anymore. However, X is very sluggish now and consumes about 2/3 of CPU load on an otherwise idle system keeping the CPU running at its maximum speed of 1200 MHz most of the time. The mouse cursor disappears while being moved. A GNOME menu literally takes seconds to open. Version-Release number of selected component (if applicable): xorg-x11-drv-savage-2.2.1-1.fc11.i586 How reproducible: Always. Steps to Reproduce: 1. Boot system into run level 5. 2. Start GNOME session. Actual results: System is very sluggish and high CPU load caused by X. Expected results: System responds normally, and X causes a few percent of CPU load at most on an otherwise idle system. Additional info: Normal behaviour is restored by adding '"Option DRI" "off"' to the driver section of xorg.conf.
Where does sysprof say you're spending time? % sudo yum -y install kernel-devel % sudo debuginfo-install -y xorg-x11-server-Xorg xorg-x11-drv-savage % git clone git://git.gnome.org/sysprof % cd sysprof % ./autogen.sh % make % sudo make install % sudo sysprof & Click start, do some stuff that's slow, click profile. Almost certainly we're doing excessive amounts of memcpy for some reason, but it's worth knowing how we're getting there.
For current "rawhide", I am unfortunately facing a certain regression: before, booting into run level 5 would leave me with a mouse pointer and a spinning throbber smearing out as successive images are overlayed until X froze completely. This occurred in front of a black background. Nevertheless, I was still able to bring up GNOME from run level 3 by executing 'startx'. Right now, 'startx' leads to the same freeze. If, by chance, I manage to launch GNOME, I will carry out the profiling.
Created attachment 345201 [details] Sysprof output for "SuperSavage/IXC 64" Output of 'sysprof' command on IBM ThinkPad T23 which sports a "SuperSavage/IXC 64" graphics engine. Installed packages [Koji] include: - kernel-PAE-2.6.29.3-159.fc11.i686 - mesa-*-7.5-0.15.fc11.i586 - xorg-x11-drv-savage-2.2.1-1.fc11.i586 - xorg-x11-server-Xorg-1.6.1.901-1.fc11.i586 The system was so slow that it was very tedious to get the log file. Rendering a window including decorations takes at least a minute. At first glance, the following section looks particularly suspicious [huge value of "self"]: <object id="666"> <name>"ShadowWait"</name> <total>14153</total> <self>14127</self> </object>
Disabling option "ShadowStatus" in xorg.conf allows to restore normal system load even when DRI is enabled. The downside is a freeze of X after a couple of seconds after launching any GL based application like 'glxgears' or selecting "Juggler3D" in the screensaver preview panel.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Disabling DRI and setting option "ShadowStatus" to "on" in xorg.conf allows normal operation of X. The issue is thus directly related to the use of DRI and not of the shadow status register as such.
Sadly, disabling DRI with the savage driver did not work with my Thinkpad T23; the boot hangs when graphics mode is entered. I am only able to use Fedora-11 with the vesa driver. Fedora-10 works perfectly.
(In reply to comment #7) 1. Are you sure DRI is effectively disabled by your xorg.conf? 2. Even when DRI is enabled, adding 'Option "ShadowStatus" "off"' to xorg.conf allows to use the "savage" driver without performance penalty. However, you should avoid using any 3D related application then.
I can confirm the bug with Fedora 11 on a brandless system and this Savage chip: VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] Disabling DRI seems to cure it. F10 did work w/o this problem.
(In reply to comment #9): My father has a 1.1 GHz Duron machine (Microtel SYSMAR561) with a Gigabyte GA-7VKMLS motherboard with the same integrated video (S3 Inc. VT8375 [ProSavage8 KM266/KL266]). After adding the line Option "DRI" "off" in xorg.conf in the Device section, his problem is also solved. Prior to this, when running top in gnome-terminal, Xorg used ~50% of the CPU when doing nothing, and almost 100% while moving the mouse. We were unable to do a GUI install due to the fact that the window "creating filesystem on /dev/sda1" would show the progress bar going back and forth, without ever finishing, and going to a VT showed Xorg using almost 100%. We eventually did a text-based install and added the extra packages manually, which is a pain. Is there a way to control the DRI option in the installer, in case this bug isn't fixed by F12? This machine was previously able to run normally every version from RH 9 to Fedora 10 without this issue ever appearing.
Suggest that the Summary be changed to "[savage] Performance regression makes X unusable when DRI is enabled", since it's not limited to the OP's hardware.
Believe I'm seeing this on my wife's (old) Compaq athlon box with ProsavageDDR KM266 when I upgraded her system from F9 to F11. Following the "F11 common bugs" instructions, I tried in sequence: 1. nomodeset on boot line 2. Option "AccelMethod" "XAA" 3. Option "AccelDFS" "off" 4. Option "DRI" "off" Only the last (4) provided a usable system.
Re Comment #7, I should have said that the savage driver works fine now on my Thinkpad T23 under Fedora-11 after adding 'Option "ShadowStatus" "off"' to /etc/xorg.conf .
(In reply to comment #13) What happens when you run 'glxgears'? Does X freeze as described in comment #4? Check that hardware rendering is actually working by looking at the output of 'glxinfo'. The reported renderer must the Savage one and not the software rasterizer.
I can confirm that disabling ShadowStatus when leaving DRI enabled results in a usable X, but freezes when running an GL based app such as glxgears. Disabling DRI seems to be the only way to get a usable crash-free system. This is on a Thinkpad T23 with an S3 SuperSavage IX/C This worked as expected with Fedora 10.
I can confirm the same issue on F11 a ProSavage8 KM266/KL266 card and savage driver except for the fact that it was enough to disable ShadowStatus (i.e. I just disabled ShadowStatus and can run glxgears with DRI enabled).
Created attachment 355965 [details] Xorg.0.log for Ubuntu 9.10 snapshot of 2009-08-02 Ubuntu 9.10 as of 2009-08-02 provides a functional X environment on my IBM ThinkPad T23 including the possibility to run 3D apps like 'glxgears'. Btw, current "rawhide" will end up with a black screen on the same system when booting into run level 5 unless driver "vesa" is chosen.
I upgraded from Fedora 10 to 11 yesterday and had this same problem. I have an Averatec 3150HW laptop. It has the ProSavage8 video card; lspci shows: 01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] just as in the case of Comment #16. And as in that case, turning off ShadowStatus is sufficient to fix the problem. With that off, all is well and glxgears runs fine.
I have a gBox P4 system and recently tried booting the Fedora 11-i686 live CD on it. It booted successfully, unlike earlier versions, for which the system was unable to find an appropriate display mode. Display controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] Monitor: Samsung SyncMaster 570S TFT (max resolution 1024x768) In this case, the screen came up in 800x600 mode, with the cursor problem reported above. My first approach was to insert an xorg.conf file, with screen resolutions defined, with settings based on an xorg.conf file that works with recent Ubuntu releases on this computer. This was done by mounting the disk volume with the Ubuntu root directory on it, copying its xorg.conf file to /etc/X11 in the live CD ram image, commenting out unnecessary sections, then switching to a text console, and killing the Xorg process. When Xorg automatically restarted, the system came up in 1024x768 resolution, and the System>Preferences>Display dialog showed the range of resolutions specified by the new xorg.conf. But the cursor problem remained. After a search, I found this bug report. I added 'Option "Shadowstatus" "off"' to the section for the savage drive, and restarted Xorg again. This seems to have solved the problem. I haven't looked at any DRI issues that were mentioned above, however. Section "Device" Identifier "S3 Inc. VT8375 [ProSavage8 KM266/KL266]" Driver "savage" Option "Shadowstatus" "off" BusID "PCI:1:0:0" EndSection Section "Monitor" Identifier "Generic Monitor" Option "DPMS" HorizSync 28-51 VertRefresh 43-60 EndSection Section "Screen" Identifier "Default Screen" Device "S3 Inc. VT8375 [ProSavage8 KM266/KL266]" Monitor "Generic Monitor" DefaultDepth 24 ... various subsections omitted ... SubSection "Display" Depth 24 Modes "1024x768" "800x600" "640x480" EndSubSection EndSection
Today I download the Fedora 12 alpha live CD, Fedora version 11.91, and tried to boot that version. After some time, during which a colored line at the bottom of the screen showing version 11.91, the screen goes blank and no X display comes up, after waiting several minutes.
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
I booted the beta version live CD - Fedora release 11.92 (Rawhide) uname -a output: Linux localhost.localdomain 2.6.31.1-56.fc12.i686 #1 SMP Tue Sep 29 16:32:02 EDT 2009 i686 i686 i386 GNU/Linux This now comes up in 800x600 mode. I haven't tried adding an xorg.conf file, as before, but I think that would work and get this system to come up on 1024x768 mode. I'll append the Xorg.0.log for this case.
Created attachment 367769 [details] Xorg.0.log after starting Fedora release 11.92 (Rawhide) live CD See previous comment #22
I'm still experiencing the same behavior as before. Currently running (after updating xorg*, kernel, and installing pixman manually as it wasn't listed in the deps for Xorg from rawhide): xorg-x11-drv-savage-2.3.1-1.fc12.i686 xorg-x11-server-Xorg-1.7.1-7.fc12.i686 kernel-PAE-2.6.31.5-127.fc12.i686 With ShadowStatus disabled and DRI enabled, X is usable, glxinfo reports Direct Rendering as available, but running an app such as glxgears crashes the machine immediately. Disabling DRI entirely is the only way to get a crash-free system as before. By crash I mean X freezes, no responses to keyboard input, dead on the network, etc. If there are any suggestions of how to get a backtrace or any sort of debugging output when it crashes I'd be willing to try them.
At least F12 is not affected by this issue anymore; I will report on an updated F11 shortly.
On a fresh F12 install on a thinkpad t23 I'm no longer seeing performance issues or crashes in Xorg.
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.