From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: This is a dual boot machine. FC3 x86-64 on the main disk No problems with this version so not a hardware problem ? Either FC4T1 i386 or x86-64 on 2nd disk Clean install of FC4T1 (i386 or x86-64) on Shuttle Athlon64 machine both show the same problem. Initial gdm problem solved - using kdm - system-config-display runs OK Monitor Iiyama AS4314UT Graphics Card Matrox G550 Clean Boot to run level 3. login as root in dumb terminal tty1 (=Cont/Alt/F1) Cont/Alt/F1-6 working correctly startx Clean display under control of /etc/X11/xorg.conf - no problems. Running kdm and kde. Logout from "X" - End Current Session to revert to dumb terminal Blank screen with small green border (0.1 inches maybe). Control/Alt/F2 to 6 are the same. Cont/Alt/F7 virtual terminal still active as typing startx blindly restarts X successfully. Is it X changing the "Mode" for the virtual terminals and the monitor cannot handle it. Checking /var/log/Xorg.0.log shows that both the graphics card and monitor have been identified correctly. Booting to run level 5 and then Control/Alt/F1 does the same. Version-Release number of selected component (if applicable): xorg-x11-6.8.2-7 How reproducible: Always Steps to Reproduce: 1.reboot to run level 3 - VTs OK 2.startx and then logout or Cont/Alt/Backspace 3.All Virtual Terminals blank with green border but still active, no detectable errors. Additional info: The solution may be as simple as just knowing if and where the Virtual Terminal Modes are set when switching using Cont/Alt/Fn
This is also happening on a bog standard x86 laptop (Toshiba Satellite Pro A10)
Please file a bug report in X.Org bugzilla to track this issue, which is located at http://bugs.freedesktop.org in the "xorg" component. Once you've filed your report to X.Org, if you paste the URL here, Red Hat will track the issue in X.Org bugzilla with upstream developers, and will review any fixes that become available for potential inclusion in future Fedora Core updates.
Setting status to "NEEDINFO", awaiting upstream bug URL for tracking.
*** Bug 151252 has been marked as a duplicate of this bug. ***
I have now down loaded FC4T2 i386 and x86-64 DVDs The graphical installer gives corrupt/unreadable display for both i386 and x86-64!!!! Unusable !!!! I have carried out a text install of the i386 version only Clean install (apart from DVD verify failure) Run level 3 boot is fine, startx gives a corrupt screen a multiple image effect with things blurring just by moving the mouse the same problem of a green bordered blank screen when switching back to VTs 1-6. The machine is a Shuttle SN85G with no onboard graphics using a Matrox G550 card. Machine still works correctly with FC3!!!! Repeating i386 install on older machine with Matrox G450 graphics card Graphics Install is OK on this machine Clean boot to run level 5 and Gnome/kde run with no problem BUT the Cont/Alt/Fx problem is still there !!!! A blank screen with a green border Bug now submitted to bugs.freedesktop.org Bug 2991
https://bugs.freedesktop.org/show_bug.cgi?id=2991
During installation of FC4T2 (with config from bug 151252) it's a blue border which appears and surrounds the [otherwise working] virtual consoles. After reboot, it's same as described in bug 151252. Bright green screen, then bright green border surrounding black and hence disabled virtual consoles.
We're now tracking this issue in the upstream X.Org bug tracker located at: https://bugs.freedesktop.org/show_bug.cgi?id=2991 Please put all future updates/comments in the X.org tracker so they're centrally tracked, and so all upstream developers will see the comments.
Is this bug still present with later versions of X? I got the blue border with an Intel 815 video card on early test versions. I'll test theIntel with the latest version later. I was hoping this bug was fixed. Anyway, I get readable text in the center. The only missing part is the area frame around the screen that is blue. The text in the was normal. It waa not blank as described by others with different cards.
Similar problem with black screen, no blue or green border. My computer: IBM NetVistat, VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) Display: Samsung SyncMaster 170T
Can we please track problems with Intel chipsets and chipsets other than Matrox in separate tickets?
FC4T3 i386 !!!! Both the CONTROL-ALT-Fx and the corrupt screen problem still there on Matrox G550, Athlon64 machine. Corrupt screen both during and after installation
(In reply to comment #13) > Can we please track problems with Intel chipsets and chipsets other than Matrox > in separate tickets? Indeed, I totally agree. No need to worry though, this bug was filed for Matrox G550 originally, and from other bug reports it seems to be a general problem with the mga driver. As such, we're going to treat this bug report exclusively as a mga driver problem. Any comments about similar sounding problems on other non-matrox hardware, while interesting, will be considered entirely separate problems and we will not be tracking them in this bug report. Just so everyone is on the same page. We requested that a bug be filed upstream, and someone did file it upstream, which is where we are tracking the issue for Matrox right now. Anyone experiencing this problem, should carbon copy themselves on the X.Org bugzilla bug report and add their comments to that bug, not this one, as X.Org developers probably aren't going to see comments that get added here. The upstream bug is: https://bugs.freedesktop.org/show_bug.cgi?id=2991 Anyone having problems that sound similar but are using non-Matrox hardware, should file a separate bug report for their issue in X.Org bugzilla as well. Once X.Org developers determine what the Matrox G550/G450 problem is and fix it, if it turns out to be a general X server bug and happens to fix similar problems for Intel i8xx users or people using any other video hardware too, then we can conclude that it is a generic X server bug that applied to the server, rather than a specific driver. At this point however, from the details I have seen, I consider this to be a Matrox mga specific driver bug, probably introduced in 6.8.x, and that any other "me too" comments from people using other non-Matrox hardware, are completely separate issues that should be filed seprately to X.Org bugzilla so that someone is aware of the problems on other hardware too. The general idea being, to not glom 10 different but similar sounding bug reports into one bug report. It is easier to treat each issue as a separate issue, and once the problem is discovered and well known, decide if separate bug reports are duplicates, than it is to have 10 bug reports crammed into one, fix the original issue, have the original reporter say "your fix works for me", close the bug report, and have 10 other people say "I still have the problem, don't close this yet", when their problem wasn't even related to the original bug report in the first place, except that it had similar sounding symptoms. To be clear, I'm not saying that every person reporting "me too" for different hardware here, is a different bug. I'm saying that there is no proof it is the same bug right now, and that until there is greater evidence to show that it is the same issue exactly 100%, all the "me too"'s should file separate bugs in X.Org bugzilla so that their issues do not get lost when the mga issue eventually gets fixed (assuming it does in fact turn out to be a mga specific issue like I believe it is). Non-mga comments in this bug report right now, just more or less make it harder to review the bug report. Please only add comments if you are using mga hardware and having the exact 100% problem indicated in comment #0. Just pointing this stuff out, so that everyone knows the best way to file bug reports, and their problems don't just fall between the cracks due to being reported incorrectly or tacked on to some other bug report, and forever lost when the bug gets closed. Hope this helps.
I've updated the version to fc4test3 to indicate it's still a problem in the latest test release. Also, as we're tracking this in X.Org bugzilla, rather than in our bugzilla, I'm setting bug status back to "UPSTREAM".
Since xorg-x11 6.8.1 from FC3 is unaffected, it smells like 6.8.2 introduced it. Or gcc4. Is anyone from the mga driver team able to reproduce this? Would it be possible to build FC4's xorg-x11 on FC3?
Since fc4 is soon coming up, and there is still just a workaround (comment #32) but no real fix in the X.Org bugzilla, would it be feasible to put that workaround into fc4?
Our rpms are built from source code. We do not include any precompiled binaries in the src.rpm of our packages, so comment #32's solution of copying the binary module from FC3 is not a viable solution to include in FC4. People are free to use that as a manual temporary workaround in the mean time if it works however. The only solution acceptable for inclusion into Fedora Core is a patch to the xorg-x11 source code that is known to fix the issue. Assuming the problem is a bug in the libvgahw source code, once a patch that fixes the real problem is available, we will consider adding it to xorg-x11 in an FC4 update. If the problem turns out to be a compiler bug, we'll fix the compiler, and a future xorg-x11 update built afterward will fix the issue. Unfortunately, for the time being, Fedora Core 4 is pretty much frozen, which means it is going to ship with this bug present. If there are any volunteers interested in debugging the problem down to the root cause, please work with X.org developers on xorg mailing list and the Xorg bug report. If the problem isn't resolved in the next month or so, it will eventually make its way into our work queues and we'll try to reproduce and investigate it directly.
Regarding the xorg-x11 version that was just added to the test repo. If this version does the same failures, would it determine whether the bug is with the xorg-x11 or with the compiler?
Tried 6.8.2-1.FC3.34 on FC4T3-i386 mg550 Athlon64 Corrupt at F7, kdm/kde Corrupt at F1-6 but no green border Reverted to 6.8.2-1.FC3.13.i368 to be able to use the machine
(In reply to comment #20) > Regarding the xorg-x11 version that was just added to the test repo. If this > version does the same failures, would it determine whether the bug is with the > xorg-x11 or with the compiler? It would suggest (but not conclude 100%) a bug in the Xorg code introduced between 6.8.2 release in FC3, and current FC4, either by upstream, or by patches nominated upstream for 6.8.3. However, the only way a conclusion can be made either way, is to narrow the problem down, and debug it until the true problem can be determined. That will happen sometime during Fedora Core 5 development if someone in the community doesn't determine the root cause sooner. Hope this helps. TTYL
Well, libvgahw compiled without -O2 is said to work, too.
Closs reference to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157556
Reopening for closer tracking, as the issue seems quite widespread now, and also seems to be linked to a common problem with libvgahw.a which causes problems on other hardware as well.
Tracking libvgahw issue in master bug #161242. People experiencing the problem described here, which is resolved by using FC3's libvgahw.a might want to CC themselves on the tracker bug #161242. Everyone who has tried replacing libvgahw.a from FC3 and restarting X to find that it does not resolve their problem, most likely is experiencing a different bug that is likely unrelated to the libvgahw issue. If that is the case, please search bugzilla for existing bug reports that describe your problem adequately and add your details to them. Be sure to search bugs in all open states, as well as the UPSTREAM state. Alternatively if you do not find a pre-existing bug describing your problem and replacing libvgahw.a with FC3's does not solve the issue, file a new bug report against FC4 detailing the problem.
*** Bug 161756 has been marked as a duplicate of this bug. ***
It's not just mga chipsets with this problem. The laptop uses the Intel 845 (or 865) chipset and I'm getting the same.
*** This bug has been marked as a duplicate of 161242 ***
I have the same problem, however I don't know if it is a X problem. If I compile a custom kernel (or use my custom compiled kernel that was working fine on FC3) I get a blurried screen. pixels change from positions/color changes a little bit. It start to change when the graphical boot screen comes up (that is where the partitions are mounted, just after initializing hardware...)