========= Problem =============== Logging into init level 5 graphical login screen, open up a terminal session, press: <CTRL><ALT><F1> init level 3 login screen is displayed press: <CTRL><ALT><F7> Instead of being taken back to the terminal session I left, I am presented with a new init level 5 graphical login screen. This is recorded in /var/log/messages: gpm[2841]: *** info [mice.c(1766)]: gpm[2841]: imps2: Auto-detected intellimouse PS/2 kernel: [drm:i810_wait_ring] *ERROR* space: 65520 wanted 65528 kernel: [drm:i810_wait_ring] *ERROR* lockup gconfd (root-3715): Received signal 15, shutting down cleanly gdm[3365]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 gdm(pam_unix)[3365]: session closed for user root gconfd (root-3715): Exiting This is a Fedora Core 3 Test 1 OS on a Sony VAIO Laptop.
Created attachment 849 [details] Xorg.0.log
Created attachment 850 [details] dmesg log
Created attachment 851 [details] Xorg.0.log.old
The Fedora packages for xorg-x11* and kernel are: xorg-x11-6.7.99.903-6 kernel-2.6.8-1.541
I cannot use this driver at all for it loses refreshing functionality. This was when booting up in runlevel 5 and then logging into X as a regular user. This is most likely from a similar cause that Mike is experiencing w/ DRI enabled. I'll litter this report with my Xorg.0.log file that can be compared with the terminal to GUI screen F7 or F8
Created attachment 852 [details] situation bad refresh,may be DRI related? The same xorg-x11 version and similar kernel used. Both Intel 815 cards.
Created attachment 857 [details] Logs for: 16 Bit - DRI = No
Created attachment 858 [details] Logs for: 16 Bit - DRI = Yes
Created attachment 859 [details] Logs for: 24 Bit
Created attachment 860 [details] Further Test Descriptions for various graphic modes Descripton of attachments in comments 7, 8, and 9 with test results for various graphic configurations.
Comment on attachment 860 [details] Further Test Descriptions for various graphic modes > >Tested three different graphics configurations: >(all are at 1024x768) > >16 Bit, DRI = No. >16 Bit, DRI = Yes. >24 Bit. > >***************** >16 Bit, DRI = No. >***************** > >Open up a terminal session > >The sequence: ><CTRL><ALT><F1> > >Took me to the text login screen. > ><CTRL><ALT><F7> > >Brought me back to the terminal session I left. > >During the terminal session I ran glxgears and an odd thing happened when >I exited the program. Notice the last line here: > >------------------------------------- >[root@linmaster log]# glxgears >771 frames in 5.0 seconds = 154.200 FPS >600 frames in 5.0 seconds = 120.000 FPS >720 frames in 5.0 seconds = 144.000 FPS >600 frames in 5.0 seconds = 120.000 FPS >600 frames in 5.0 seconds = 120.000 FPS >720 frames in 5.0 seconds = 144.000 FPS >600 frames in 5.0 seconds = 120.000 FPS >600 frames in 5.0 seconds = 120.000 FPS >600 frames in 5.0 seconds = 120.000 FPS >X connection to :0.0 broken (explicit kill or server shutdown). >--------------------------------------- > >The attachment in comment # 7 >contains; xorg.conf, Xorg.0.log, and dmesg > > >****************** >16 Bit, DRI = Yes. >****************** > >This is my normal setup mode. I have booted this computer 100's >of times into this mode without problem until today (after the >24 Bit test below) > >Open up a terminal session > >The sequence: ><CTRL><ALT><F1> > >Took me to the text login screen. > ><CTRL><ALT><F7> > >Caused the computer to lock up without re-displaying the graphical >login screen. I had to reboot. > >The attachment in comment # 8 >contains; xorg.conf, Xorg.0.log, and dmesg > > >****** >24 Bit >****** > >This was a disaster. All the nastiness described in >https://freedesktop.org/bugzilla/show_bug.cgi?id=1232 >occurred;i.e. the slowness and refresh problems. > >The attachment in comment # 9 >contains; xorg.conf, Xorg.0.log, and dmesg > >What's also puzzling, is that even the 16Bit, DRI=Yes mode >above was a problem after running this configuration >(slowness and refresh problems). I finally had >to do a cold boot in order to restore things to working condition. >(Mounting the root partition on another OS (FC1) and copying the 16 Bit, >DRI=Yes Xorg.conf file into place and then reboot into Fedora Core 3 > >Also of note is the fact that I am certain that I've run 24 Bit >graphics on an earlier version of Xorg-X11 software without problems. If >it will be of use to troubleshoot this problem I'll be happy to roll back >to earlier versions of Xorg-X11* software. >
Created attachment 865 [details] At 1024x768 things are better for performance Though I prefer 1280 x 1024 mode, the 1024 x 768 mode enables DRI. Refer to attached file for details regarding glxinfo, glxgears and xdpyinfo. To help with confirming 815 behavior similar to the ctl-alt-Fn to terminal crash, I wanted to get DRI activated. After attachment submitted, I'll try the ctl-alt-Fn to a mingetty terminal. I am running in runlevel 3.
Created attachment 866 [details] Confirming DRI connection. This happened to me with DRI enabled and at 1024 x 768 resolution. Refer to Xorg.0.log attached
Created attachment 868 [details] Mode switching causes refresh problem. The history of this log covers switching resolutions via system-config-display to 1280 x 1024 after DRI testing at 1024 x 768. A later attachment regarding this tools reconfiguration of the Xorg.conf file will be posted along with information with another xorg.conf file that was manually edited for 1280 x 1024. The config file created with the tool bombed and caused the refresh problem indicated. Reverting back and rebooting was the only solution to get back to the working server condition.
Created attachment 869 [details] This setting of the xorg.conf file causes a refresh problem. This file was transitional from testing. It was generated from system-conf-display and is very bad. I used the tool to select default depth of 24 and 1280 x 1024 resolution.
Created attachment 870 [details] This configuration rocks! This file is from initial setup of the system and was set to 24 depth originally. This is an ideal setup and exhibits no problems. The server for the 815 card looks great.
Created attachment 871 [details] These are the performance related information items for the 1280 x 1024 mode This should complete my testing
Created attachment 872 [details] All the known tools - gears etc
I rolled the version of Xorg back to the Fedora package xorg-x11-6.7.99.903-5 and the problems I noted with the 24 bit configuration above in "Further Test Descriptions for various graphic modes" (Comment #10) have disappeared although it didn't fix the problem switching from graphic to text mode logins. I'll attach the xorg.conf and xorg.0.log ... Mike Klinke
Created attachment 885 [details] xorg.conf for rolled back version
Created attachment 886 [details] xorg.0.log for rolled back xorg
Created attachment 888 [details] This file is from an 845 graphics controller. Test is to see if DRI is causing lockups for all versions of Graphics controllers that use the i810 driver. The test was basically starting X from runlevel 3, then ctl-alt-Fn to a terminal. The crash did not happen. DRI was active and resolution was 1280 x 1024. Other attachments that will be included are DMESG, glxinfo and the xorg.conf from the Dell with the 845 card.
Created attachment 889 [details] comparative xorg.conf for 845 Graphics controller
Created attachment 890 [details] This is performance for comparison of 845 GC
Created attachment 891 [details] DMESG output from running system. Now that the problem is comparatively isolated to the 815 chipset and the 845 card is working fine, I hope the corrections can be made to the driver or split the driver into 810/815 for one driver type and 830/845 for a secondary card w/ later chipsets following suit.
It is very likely that these problems are gone in 6.8.2. Please test.
Today the 6.8.2 version was released to Fedora Core 3 as: xorg-x11-6.8.2-1.FC3.13 and as, has been suggested, this problem doesn't exist any longer, at least on my laptop. Swithing back and forth works fine. Regards, Mike Klinke
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.