Red Hat Bugzilla – Bug 245356
Using virtual terminals causes unusable screens
Last modified: 2010-05-03 11:13:55 EDT
Description of problem: Using virtual terminals causes X windows to be unsusable. Version-Release number of selected component (if applicable): 2.6.18-8.1.6.el5xen 00:02.0 VGA compatible controller: Intel Corporation 82G965 Integrated Graphics Controller (rev 02) [xorg-x11-drv-i810-1.6.5-9.2.el5, kernel-xen-2.6.18-8.1.6.el5] How reproducible: Start a virtual terminal. [Allow GDM to localhost] Steps to Reproduce: 1. X :1 -query localhost 2. Switch back to first terminal [ctrl-Alt-F7] 3. Actual results: White screen. Switching back to F8 gets a solid blue screen. Expected results: Usuable virtual consoles Additional info: Have read and understood release note about greyscale rendering. Have not edited fonts. [Release note - # Logging in remotely to a Gnome desktop via gdm may cause several display issues. The login screen may hang, displaying an unusable empty screen. To prevent this from occurring, do not change the default font rendering setting of grayscale. If the default font rendering setting has been edited and you encounter this problem, run the following command: gconftool-2 --direct --config-source=$(gconftool-2 --get-default-source) --set /desktop/gnome/font_rendering/antialiasing --type string grayscale ]
xorg-x11 is not correct component for RHEL5.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 190261 [details] xorg.conf file [mgt@dwarfstar ~]$ uname -a Linux dwarfstar.stellarcore.net 2.6.18-8.1.8.el5xen #1 SMP Tue Jul 10 07:06:45 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
Created attachment 190271 [details] Xorg.0.log during test with no xorfg.conf file
Created attachment 190281 [details] Xorg.1.log from test with no xorg.conf on virtual terminal
I have submitted the attachments as requested and conducted the test of Xorg with no xorg.conf file in place. The issue is still there although in this case it took 3 terminal changes to cause the bug. I booted into init 5 and logged in. I then changed to text terminal ala Crtl-Alt-F1 and started another session with the command X :1 -query localhost. Once another graphics terminal started up I logged into that as well. Then with a Ctrl-ALT-F7 and changed to the original window movede around, CTRL-Alt-F8 to return to new terminal everything was fine. Then I went to CTRL-ALT-F1 and when I returned to CTRL-ALT-F7 the ternminal became unstable. -Mike
I was doing so further fiddling with my xorg.conf and can confirm that the issue seems to be in the i810 driver. When I switch to vesa the issue goes away. -Mike
Some more comments. I updated the motherboard BIOS [and therefor the video BIOS] was at the lastest greatest rev. [1707 in this case]. No effect. I grabbed the i810 package from the Fedora 7 tree [ xorg-x11-drv-i810-2.0.0-4.fc7.src.rpm ] and with minimal hacking I was able to build and install that. No effect the problem still exists. -Mike
Two years have passed now. Is this problem still present? Thanks.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.
I honestly have no idea if this is still the case. It was 2 years before this was even commented on so I guess I was out in the wilderness alone with this problem. I ended up having to use Xnest for my needs and eventually changed desktops [Mac Mini OSX]. I think I provided sufficient information with the original bug report that the Intel chipset had issues with the released X server driver and testing it was pretty straight forward. Hopefully it was fixed in later releases. -Mike