Fedora Account System
Red Hat Associate
Red Hat Customer
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Description of problem: As experienced since the initial introduction of the CVS head for the upcoming xorg-x11 version, I have been having errors related to X not starting during the beginning. I now have a refresh problem, where the menu items are not visible until the mouse is hovered over the hat or other items. Applications miss a lot of details also. Another note is that X will not come up to do a graphical installation with the 815 version of the intel graphics controller. Version-Release number of selected component (if applicable): xorg-x11-6.7.99.903-5 How reproducible: Always Steps to Reproduce: 1. Install a CVS version of xorg-x11 2. Launch X via startx at runlevel 3 3. Navigate the menus, observe applications Actual Results: 1. Installed without error 2. Would launch, but did not seem to refresh the screen 3. applications have many transparent or not drawn elements, menu items do not show without hovering the mouse over them. Expected Results: Expected to be able to install through graphical mode. Expected a fully functional X. Additional info: Since X does not work properly with the latest driver, I have reverted to the i810_drv.0 from FC2 and replaced the version from the CVS head. The driver is overwritten with the next installation and tests can be made. Another pecularity is that once the driver from this version is launched once, X will not start correctly until a relaunch is completed. After a reboot, X works again with the FC2 binary driver. A few bugs were submitted to the xorg website and a patch was submitted. Afterwards, an improved patch was submitted. As a note: This CVS version works fine for a machine with the 845 card. The problem arises with the 815 graphics controller. I believe the submitted patch helps out the user of the 810 card and some 815 cards seem to work most of the time. During the testing phase, I compiled the src rpms using i686 arch and the versions seemed to function normally. I did not change any spec file parameter, just ran rpmbuild --rebuild --target i686 xorg<version>.src.rpm This might indicate that the development and release candidate binary rpms have special compilation options on tweety compared to my attempts. Of course this is a wild guess. Jim
Created attachment 103521 [details] This file is trying to launch X initially This is the xorg log during my first launching of X, after a clean install.
Created attachment 103522 [details] This is xorg log using the FC2 binary driver described. This does not seem to be needed if building from the src rpm. I am running the stock rpms now. This step is needed to run decent on the X server
Created attachment 103523 [details] Current Xorg configuration file.
/proc/mtrr normally looks like the below when X starts. It seems that the original driver never adds the last line to the file. I'll close X, reinstitute the original driver to see if the X refresh problem is gone with the reg02: line added. This seems to stick around after the first sucessful starting of X. cat mtrr reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1 reg01: base=0x1ff00000 ( 511MB), size= 1MB: uncachable, count=1 reg02: base=0xf8000000 (3968MB), size= 64MB: write-combining, count=2 lspci info: lspci 00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) 00:02.0 VGA compatible controller: Intel Corp. 82815 CGC [Chipset Graphics Controller] (rev 02) 00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corp. 82801AA IDE (rev 02) 00:1f.2 USB Controller: Intel Corp. 82801AA USB (rev 02) 00:1f.3 SMBus: Intel Corp. 82801AA SMBus (rev 02) 00:1f.5 Multimedia audio controller: Intel Corp. 82801AA AC'97 Audio (rev 02) 01:00.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 74) 01:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS)
Created attachment 103524 [details] bad guess - killed right away refresh This is the var/log messages from reinstalling the original, launching X and then reinstalling the original driver before rebooting. I then rebooted the system with the FC2 i810 driver and X seems to be working again.
Created attachment 103525 [details] This is how bad the refreshproblem seems to be Screenshot for original driver and refresh problem.
Created attachment 103669 [details] Now! this is more like it! This seems to also improved the general responsiveness that X can do. Thanks a lot for the efforts. I hope this is not a fluke. Jim
After rebooting the computer completely, this bug with refreshing the computer resurfaced. I supposed that ctl-alt-backspace would be enough to simulate the failure. This was not the case, the bug is still here. The fluke is that the driver that is loaded will cause the refresh problem until X is fully reset. If a good driver is used from a pre-CVS release, X will work. X will still work with runlevel 5 gdm console reset. Anyway, back to the reported problem.
Created attachment 103712 [details] This is the message log from xorg-x11-6.7.99.903-6 w/ refresh problem. I logged into a terminal and pulled messages while the X server was running along limping.
Created attachment 103713 [details] This is an Xorg log with the version xorg-x11-6.7.99.903-6 installed. I have another installation that is upgraded from FC2 that seemed to work when I had it running. This is a clean install from release candidate 1 w/ up2date ran to retrieve the latest packages.
Created attachment 103714 [details] Of course the picture of the cute beast is needed This should be the last screenshot.
Created attachment 103715 [details] back to the hack fix - binary i810 driver w/ xorg-x11-6.7.99.903-6 running
Created attachment 103735 [details] On upgradedsystem - No refresh w/ same version X As a comparison for the fresh install system that has the refresh problem, I include the Xorg.0.log from the same computer that has an upgraded from FC2 to release candidate 2 installed. This system is different in the fact that X seems to work correctly. No fresh rawhide upgrades were applied to the system yet. I'll attach the upgrade log also to this report.
Created attachment 103736 [details] This is the log from the original system installation in jan 2004
Created attachment 103737 [details] This is the syslog from the Jan 2004 installation
Created attachment 103738 [details] The previous logs were from the installation, this is the upgrade log The first logs were from when the system was setup Jan 12th. This is the log from the upgrade completed on 9/9/04
Created attachment 103739 [details] the compliment syslog from the 9/9/04 upgrade. after submittal, I'll correct the references to the previous two logs submitted.
A puzzling discovery has been determined since submitting this bug. If I change my depth for color from 16 to 24, before launching X, I do not seem to be effected by this refresh error. If my depth is set to 16, I get this messy refresh problem. I tried on two different installations on the same computer. I'll attach a few outputs from x related programs.
Created attachment 103745 [details] problems with refresh at 16 depth
Created attachment 103746 [details] this is glxinfo at 16 depth After getting the initial refresh problem, teliniting to another runlevel, in this case, 3 to 5 did not get the screen back to normal. I reset xorg.conf to 24 depth and had the same refresh problem that 16 depth causes.
Created attachment 103747 [details] This is what /var/log/messages says is going wrong As stated,X was started at 16 depth, I got a refresh problem. I then ran glxinfo and the other listed py* program. I then closed X in runlevel 3, changed depth back to 24 which works if I boot with this depth selection. It exhibited the same errors with refresh. Not included in the messages was that I telinit from rl3 to rl5 and still had the refresh problem. I telinit to 1 then tried to telinit back to 3 and the computer seemed to lockup on the HAL portion of the runlevel initialization. I then ctl-alt-del to runlevel 6 for reboot and now X is back to working order.
Created attachment 103748 [details] This is from 16 to 24 and no reboot for xdpyinfo Bad, very bad
Created attachment 103749 [details] And of course a working 24 depth after rebooting the computer This looks good
Created attachment 103750 [details] 16 depth to 24 depth, still refresh is bad, no reboot
Created attachment 103751 [details] and this one looks good glxinfo, 24 after reboot no refresh problem encountered
Created attachment 103809 [details] 845 to compare with 815 log For comparison, this does not happen with the 845 card and same graphics controller. The xorg.conf has similar settings.
Created attachment 103810 [details] 845 config for setting comparisons The settings are 16 depth, 1280 x 1024.The differences other than the 845 card having DRI active are all noticed.
As comparison, the GUI installation was possible with the Dell that used the i810 driver also. The 15 hung during a GUI install attemptdescribed earlier.
Thanks for the report. In order to minimize bug report duplication, we are tracking this issue and/or very similar issues in a single centralized bug report. Please provide any follow up comments or status changes in the centralized bug report, where we will track them going forward. Setting status to "DUPLICATE". Thanks. *** This bug has been marked as a duplicate of 132267 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.