From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050724 Red Hat/1.0.6-1.4.1.SL3 Firefox/1.0.6 Description of problem: after updating from 45 to 49.2, there are some regressions: 1) X starts fine from a VT, but switching to a VT from X and back to X leaves me with a black screen 2) Once the X screensaver has kicked in, I cannot get back my display -- only the cursor 'comes back alive' -- the remainder of the display stays black... This is on a SONY PCG-R600HMP with an Intel 82830CGC Version-Release number of selected component (if applicable): xorg-x11-6.8.2-37-FC4.49.2 How reproducible: Always Steps to Reproduce: 1. boot to X, then switch to a VT and back 2. alternatively, wait until screensaver 'kicks in', then hit a key 3. Actual Results: black screen Expected Results: get back my desktop... Additional info: see attachements...
Created attachment 119185 [details] Xorg.0.log
Created attachment 119186 [details] dmesg
Created attachment 119187 [details] lspci
Created attachment 119188 [details] xorg.conf
Created attachment 119189 [details] version numbers of xorg rpms
I wrote: > > 2) Once the X screensaver has kicked in, I cannot get back my display -- > only the cursor 'comes back alive' -- the remainder of the display > stays black... to be more precise: if I wait long enough for the X screensaver to have switched of the display, then it does not come back alive. As long as it just displays some nice animation, things are fine. I have power management enabled under 'display power management' setting of X screensaver.
Thanks for the report. We will try to reproduce this internally.
Please edit your xorg.conf, and add the following option to the "ServerFlags" section. If there is no ServerFlags section, create a new one as such: Section "ServerFlags" Option "PciOsConfig" "1" EndSection Then save and exit, and reboot the system, then start the X server up again. Indicate wether the video problem is resolved or not. If the problem is still present, remove the above option, and replace it with the following option instead, and try again: Option "PCIProbe1" "1" Does this option resolve the issue? If not, please try the following: Option "PCIProbe2" "1" If any of these 3 options work around the problem, please update the bug report to let us know which ones. Be sure to reboot the machine before each try, to ensure a full hardware reset. This will help us to narrow down wether the problem is related to the PCI configuration changes, or elsewhere. Thanks in advance for testing. Setting status to "NEEDINFO_REPORTER" and awaiting feedback.
Created attachment 119233 [details] Xorg.0.log with Option "PciOsConfig" "1"
Created attachment 119234 [details] Xorg.0.log with Option "PciProbe1" "1"
Created attachment 119235 [details] Xorg.0.log with Option "PciProbe2" "1"
None of the three ServerFlags solves the vt switching problem -- it still persists. I've attached the Xorg.0.log files for each of them. To test the screensaver problem I changed the settings (the idea of waiting for >15 min. each time wasn't very attractive!) but after changing them I cannot reproduce the problem (sorry, I hate submitting un-reproducible bug reports and hoped that I could reproduce it, but cannot -- at least the vt switching is very much reproducible!)
Ok, we seem to have narrowed this down to an i810 driver regression. The new i945 support patch from Alan H, which is integrated into FC3/FC4/RHEL4 seems to have some regressions. Hopefully we can narrow it down soon. I'll check latest CVS head for differences, and contact Alan as well to see if he's got any ideas. For now, please try these rpms, which contain the original i810 driver: ftp://people.redhat.com/mharris/testing/unstable/xorg-x11/6.8.2-37.FC4.49.3.test_no_i945.0 Please update the bug to indicate if they work for you. TIA
I installed the following RPMS: ftp://people.redhat.com/mharris/testing/fc4/xorg-x11/6.8.2-37.FC4.49.3.test_no_i945.0/i386/xorg-x11-6.8.2-37.FC4.49.3.test_no_i945.0.i386.rpm ftp://people.redhat.com/mharris/testing/fc4/xorg-x11/6.8.2-37.FC4.49.3.test_no_i945.0/i386/xorg-x11-xfs-6.8.2-37.FC4.49.3.test_no_i945.0.i386.rpm ftp://people.redhat.com/mharris/testing/fc4/xorg-x11/6.8.2-37.FC4.49.3.test_no_i945.0/i386/xorg-x11-libs-6.8.2-37.FC4.49.3.test_no_i945.0.i386.rpm ftp://people.redhat.com/mharris/testing/fc4/xorg-x11/6.8.2-37.FC4.49.3.test_no_i945.0/i386/xorg-x11-devel-6.8.2-37.FC4.49.3.test_no_i945.0.i386.rpm ftp://people.redhat.com/mharris/testing/fc4/xorg-x11/6.8.2-37.FC4.49.3.test_no_i945.0/i386/xorg-x11-deprecated-libs-devel-6.8.2-37.FC4.49.3.test_no_i945.0.i386.rpm ftp://people.redhat.com/mharris/testing/fc4/xorg-x11/6.8.2-37.FC4.49.3.test_no_i945.0/i386/xorg-x11-deprecated-libs-6.8.2-37.FC4.49.3.test_no_i945.0.i386.rpm and the result is that yes, vt switching DOES work again! (note: fc4, not unstable, so I hope these are the ones you intended ;-) Thanks for the quick identification of the problem.
I had a chat with alanh in IRC about this issue this morning, and it turns out many i830 BIOSes are buggy. Suggested workaround, is to use the following to the Device section of the config file: Option "VBERestore" Using the 49.2 build, does this make the problem go away, or affect it at all? You can test it by downgrading just the server rpm with the latest update using "rpm -Uvh --oldpackage <package>". yum might have an option to downgrade too, but I haven't checked. Setting status to "NEEDINFO_REPORTER", and awaiting testing results.
Going back to 49.2, with VBERestore, solves 'half' the problem: I can switch back and forth between vt and X, and after switching to a vt, the vt works 'all the time', but once I've switched from X to vt to X, X stays 'black'. But switching to a vt again shows a nicely working vt.... so switching to a 'vt' works, but switching to 'X' doesn't.
*** Bug 175580 has been marked as a duplicate of this bug. ***
Since this bugzilla report was filed, there have been several major updates to the X Window System, which may resolve this issue. Users who have experienced this problem are encouraged to upgrade to the latest version of Fedora Core, which can be obtained from: http://fedora.redhat.com/download If this issue turns out to still be reproduceable in the latest version of Fedora Core, please file a bug report in the X.Org bugzilla located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your bug report to X.Org, if you paste the new bug URL here, Red Hat will continue to track the issue in the centralized X.Org bug tracker, and will review any bug fixes that become available for consideration in future updates. Setting status to "CURRENTRELEASE".