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
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
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):
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.
The solution may be as simple as just
knowing if and where the Virtual Terminal Modes are set when switching using
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
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
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:
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
Since xorg-x11 6.8.1 from FC3 is unaffected, it smells like 6.8.2 introduced it.
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
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 email@example.com 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.
Well, libvgahw compiled without -O2 is said to work, too.
Closs reference to
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...)