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) Gecko/20040510 Galeon/1.3.14 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): How reproducible: Always Steps to Reproduce: 1. Install 2. 3. Additional info:
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 the screen-corruption.
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: http://freedesktop.org/bugzilla/show_bug.cgi?id=687 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 x86_64. 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 or not. 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 screen. 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. ***