After installing the latest CVS version provided from Fedora Development -
xorg-x11-188.8.131.523-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: ignoring font path element
Aug 29 14:27:32 localhost xfs: ignoring font path element
Aug 29 16:00:00 localhost xfs: ignoring font path element
Aug 29 16:14:59 localhost xfs: ignoring font path element
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]
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.
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
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-184.108.40.2063-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
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
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.
VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics Controller]
Created attachment 775 [details]
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
I was able to pull up the gimp and with a lot of effort, I got this screenshot
This bug seems to be resolved by the second patch in bug 1084 and in version
xorg-x11-220.127.116.113-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)
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.
CVS version xorg-x11-18.104.22.1683-6 from Fedora seems to really know what to do now.
No need for hacking using this version!
Created attachment 844 [details]
Attached is the results from the latest xorg-x11-22.214.171.1243-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
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
Created attachment 856 [details]
xpdyinfo at 24 depth
As another user informed me of this xdpyinfo program, I ran it and recieved
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
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.
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.
and another freedesk.org bug.
I believe te bug can be marked as fixed in later versions.