|
Description
Jim Cornette
2004-08-29 16:14:48 UTC
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! 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.