Red Hat Bugzilla – Bug 124028
Screen corruption using Matrox Millenium MGA 2064W
Last modified: 2007-11-30 17:10:43 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Description of problem:
As soon as the graphical installation starts off, I'm confronted with
irritating screen-corruption. Blocks of the screen have pixels from
other blocks. Scrolling windows corrupt the screen even more (eg. in
the package-selection windows, scrolling will put the bullet-points at
another location then where you actually have to click)
The system is actually a dualhead system, with a PCI Matrox Mystique
1064SG and a PCI Matrox Millenium 2064W.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
After the installation the screen-corruption is still there. There
seems to be no screen-corruption on the MGA Mystique. Mostly blocks
that are updated with the wrong info (either older data or data from
another position). When X starts off, the initial location of the
mouse leaves a black box.
With FC2 and previous Red Hat release (since around 7.3) no such
screen-corruption happened. This is the first release that introduces
Yes, but is this also the first release you've tried to use the cards
on x86_64 as well?
I'm getting what sounds like the same corruption on an i586 system
with only a Matrox Mystique. Occurred during installation and is
still there after install during normal use.
Further to my comment a few minutes ago: it looks like this is
probably the same problem, and the solution to it:
Haven't had time to try it yet, though.
Jeremy, yes. In the past it ran on i386 HW and the last months on
x86_64 HW with an i386 Fedora Core 1. The corruption only started with
FC2/x86_64 on x86_64, I will start the installer with a FC2/i386 on
x86_64 to see if FC2 is affected on both architectures or it just is
Although the other comments seem to indicate it's a widespread problem.
Ah that explains why my Millenium doesnt work
Alan investigated this a bit deeper after comment #6 above, and
sent me a technical description of the problem via email:
On the MGA1064 waiting for MGA busy to clear after checking DMA is
quiescent and before flushing the cache causes a hang and must be
worked around. The existing code does this. However this workaround
should only be applied to Chips with revision 0-2 on later chips it
leads to corruption problems instead.
I've examined X.Org CVS as to when the problem was introduced from
a previous mga patch, and have modified MGAStormSync() to not
call MGAISBUSY() in the while loop on Mystique models of revision
0 through 2.
I haven't tested this on real hardware yet, however I have commited
the fix to our rpms as patch xorg-x11-6.7.0-mga-storm-sync-fix.patch
which I'll commit to CVS once someone can confirm wether it works
Patch is present in xorg-x11-6.7.0-5, which is a Fedora Core 2
update candidate. I'll release fedora-testing packages soon which
include this fix. Please test ASAP and provide feedback.
The xorg-x11-6.7.0-5 update certainly fixed the problem for my
Mystique, which is reported as being revision 3, on i686. Thanks Mike.
Yes, the screen-corruption is gone (fc2/x86_64) !
Though I still have problems using Xinerama and overlay, that I can't
remember having before in fc1. If I use Xawtv, it only displays the
actual overlay on 1 screen (my Mystique), when moving the window to
the other screen, it moves at the same position but stays on the same
So having the xawtv-window right in the middle (half on one, and half
on the other screen), the content of both halfs are only displayed on
my right screen (mystique)
Ok, thanks for the testing feedback guys, closing Mystique corruption
bug as fixed in 'RAWHIDE' now.
*** Bug 122110 has been marked as a duplicate of this bug. ***
*** Bug 123946 has been marked as a duplicate of this bug. ***