After installing the latest CVS version provided from Fedora Development - xorg-x11-6.7.99.903-1 X would start up, but shortly after launching, X would either slow down so much that it appeared lock or would not respond at all. This is the first bug that is submitted after the problem with X not even starting. Two bug references are bug 1086 which was a duplicate of bug 1084 filed slightly earlier. As a note: if the binary driver from the earlier xorg-x11 is used with the latest X version listed above, X does not sieze up to a halt as with the latest version i810 w/ the patch to fix bug 1084 indicates. /var/log/messages displays the below xfs errors regarding the speedo font. I amnot sure if this would cause the stalling. An attached xorg.0.log file from the initial freeze, an xorg.conf file will be added to the report next. Aug 29 13:34:22 localhost xfs[3371]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) Aug 29 14:27:32 localhost xfs[3371]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) Aug 29 16:00:00 localhost xfs[3595]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable) Aug 29 16:14:59 localhost xfs[3154]: ignoring font path element /usr/X11R6/lib/X11/fonts/Speedo (unreadable)
Created attachment 768 [details] X started, worked for a few minutes, locked when sending email I was sending an email confirming X now worked and suddenly the freeze, slowdown started. Originally, I could not even seem to switch to terminal. After rebooting the computer to change kernel and see if restarting the computer would simulate the error or the error would be gon. I found that the error was very much present. I was able to successfully switch to terminals, but could not see X, startx running, gnome processes were running, but no X. This problem sees similar to the problem that I had on a computer with an 845 card, X just disappeared. With this case, it seems that gnome process are still using whatever still appears on screen 7. With the binary driver from the earlier install of a working version of X, submitted in bug 1086.
Created attachment 769 [details] current xorg.conf Basic xorg.conf used for awhile that worked until dual head change broke 810/815 intel cards.
Created attachment 770 [details] This is xorg running with the binary uploaded to bug 1086 For comparison, this is a working X with the older version driver. (from FC3T1 installation CD). This works correctly. As a note: I renamed the originally provided driver from this CVS version. It is possible for me to revert to the original for test purposes, if needed. Thanks!
The card used is below from lspci 00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics Controller] (rev 02) This should be it for awhile.
Created attachment 771 [details] Seems alright when compiled from src rpms --target i686 After having the problem with the binary rpms, I decided to recompile from the src rpms and test again. Attached is the recompiled rpms. It seems that when compiled from src rpm and i686 target, X works fairly decent. Also, glxgears seems to work quicker than with the i386 stock rpms that I'm having troubles with. At the tale of the log, I tested with tuxracer and my screen shifted into a mode where the screen was larger than normal (zoomed). You could move the mouse around to see other areas of the screen, but it was guessing, 4 times larger than normal. I assume that the very last entry in the attached log reveals what is happening with the zoom moded screen. This same behavior happens w/ tux on a computer with the i845 card. This is stock everything. No legacy binary in use.
Created attachment 772 [details] [review] This is the binary i810 from src rebuild.
Created attachment 774 [details] i686 self-compiled and xorg-x11-6.7.99.903-1 rawhide binary driver from rpm borked After closing down X with the i686 compiled i810 driver, I used the driver that is supplied with the binary rpm supplied on rawhide. When launching X, the screen had crazy stripes all over the screen. Next, the splash screen showed. X then ran for awhile, then decided to go haywire on me with this version of the driver. I then had strange items painted or not painted on the screen. With a lot of struggle, I finally was able to close down X. This attachment reveals the activity encountered. After the failure, I put the self compiled driver from the i686 rpms back. I restarted X and it acted the same horrible way. I cleared my tmp directory and rebooted the machine. Things are back to normal now. This leads me to believe that this rendition of the driver really fouls up things until rebooting computer.
I upgraded to the same Fedora Distribution today and also found that X now works on the i810. I originally filed the xorg bug 1084 Jim noted above. Unlike Jim, though, the first time I booted the machine everything went well for the first few minutes and then I kicked up the game Malestrom to see if video and audio track and much to my suprise they gradually became more and more out of sync as the interface seemed to slow dramatically. Unlike Jim, though, after rebooting the computer I haven't had a re-occurance. I've played audio CD's, watched DVD's, watched TV via xawtv, played with Glxgears but have not had a problem since the first reboot. lspci: VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics Controller] (rev 11) Mike Klinke
Created attachment 775 [details] My Xorg.log
Created attachment 782 [details] This is a screenshot of the resulting screen after the slowdown. I am beginning to think that this problem is related to the screen not updating properly. I even opened up a terminal and the screen would not refresh if xrefresh was typed. If you open an application, all of the elements are not there. If you move the mouse around the menu items, the screen will show some detail from the new action. I was able to pull up the gimp and with a lot of effort, I got this screenshot attached.
This bug seems to be resolved by the second patch in bug 1084 and in version xorg-x11-6.7.99.903-2 from Fedora development. I searched for test from the patch submitted in 1810_driver.c and similar text was in the file. I assume that the patch was applied to the CVS version. Entry into the changelog was not noticed for this patch though. Both the binaries supplied from the rpms and also the compiled for i686 arch src.rpms seem to be functioning properly. Different installations, same computer. (1 i386 binary and the other compiled i686 rpms) Thanks! Jim
There seems to be a one time reversion for the version of X that seemed to resolve the refresh prolem with X. with the latest version used in Fedora Development, the bug returned. Refer to below bug for details. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131934 Thanks!
CVS version xorg-x11-6.7.99.903-6 from Fedora seems to really know what to do now. No need for hacking using this version! Great job!!!!
Created attachment 844 [details] Attached is the results from the latest xorg-x11-6.7.99.903-6 build I have two systems on the same computer. This is a fresh installation. X worked until the computer was rebooted.
Created attachment 845 [details] This is the result of the refresh problem I am running in runlevel 5 and tested to see if this bug was fixed and after the starter relaunched, it still worked alright. After turning off the computer and booting from power off, it still has a refresh problem. As stated, I have two systems, one is an upgrade from FC2 to FC3T2 release candidate 2. The trouble is with a system which was a fresh install from the first release candidate. The upgraded system does not seem to exhibit this error with the refresh.
Sorry for the bouncing around from closed to open. A longer evaluation before closing will be tried.
Created attachment 853 [details] This attachment is my original xorg.conf file with 16 set a depth With these settings in my xorg.conf file, I get a horrible refresh rate problem. This is from a freshly installed FC3T2 release candidate. I changed the settings as what another person noted was the difference between the two files from 16 depth to 24 depth. This seems to have corrected the problem and enhanced the rosolution. Other than changing both the default depth and depth to 24, the files are identical. My next attachment will be the Xorg.0.log file and little comment.
Created attachment 854 [details] Much better looking X. Depth set to 24 as previously mentioned
Created attachment 855 [details] This is the output from glxinfo The screen looks much better now. This could be user. I enclosed glxinfo as a second opinion.
Created attachment 856 [details] xpdyinfo at 24 depth As another user informed me of this xdpyinfo program, I ran it and recieved this output.
Created attachment 873 [details] DRI testing and switching modes to higher resolution The attached is a copy of the messages from testinghow this problem happens at different resolutions and depths. I removed my xorg.conf file and ran the configuration tool to start a fresh configuration file. The tool used was system-config-display-1.0.19-0.1 from the latest rawhide release. Test 1: run tool test 2: leave default 640 x 480 resolution, see if DRI=yes. creep up to 1024 x 768 resolution, DRI still present. Check for bug related to DRI with server crashing. Confirmation of problem was successful. test 3: from the 1024 x 768 mode, run system-config-display and select 1280 x 1024 at 24 depth, exit X and restart X. The refresh problem is present. Reboot the computer to start every initializing program as booting fresh provides. Try to startx again. The problem with refreshing still there. Check xorg.conf file. See next attachment of tool generated X that causes refresh problems.
Created attachment 874 [details] This config was autogenerated by system-config-display continuation from previous attachment.
Created attachment 875 [details] This setup works great. Using this setup, there is no DRI, there is no refresh problems and is my choice for a sane default config files for xorg-x11
Created attachment 876 [details] Present state of system w/ preferred settings - copied while in X
Created attachment 877 [details] running system DMESG output
Created attachment 880 [details] This is just video tool output This file contains output from three tool to test video performance. This is 1280 x 1024 and at depth of 24, monitor and 815 Graphics controller.
Created attachment 892 [details] 845 comparison - does not have refresh problem as 815 version does As a comparison of computers that use the same i810 driver, I am submitting this log for comparison. I see some errors within the log, but none related to refresh problems. Before this CVS version series, this 845 was plagued by random crashes, triggered by screensavers as an easy way to isolate the problem. The casualty is the 815 Graphics controller, splitting and isolating the driver into 1810 and i830, at least would help correct for one card, without busting the other. Just a suggestion. Jim
Any news? Have you tested 6.8.2 lately?
(In reply to comment #29) > Any news? Have you tested 6.8.2 lately? This bug was fixed in later versions. The below bugs track the resolution. Redhat bugzilla. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132267 and another freedesk.org bug. bug 1817 I believe te bug can be marked as fixed in later versions.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.