Bug 442533 - Black display with drv-mga
Black display with drv-mga
Status: CLOSED DUPLICATE of bug 466318
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-mga (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
: 452615 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-04-15 08:45 EDT by Fred New
Modified: 2009-11-18 02:53 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-18 02:53:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Latest Xorg-0.log (24.07 KB, text/plain)
2008-04-15 08:45 EDT, Fred New
no flags Details
Xorg.0.log from Fedora 8 (49.06 KB, text/plain)
2008-04-28 09:56 EDT, Fred New
no flags Details
Xorg.0.log with the monitor attached to the digital port (35.87 KB, text/plain)
2008-06-04 08:30 EDT, Fred New
no flags Details
Xorg.0.log after recent xorg-x11-server-* updates (24.19 KB, text/plain)
2008-06-16 03:11 EDT, Fred New
no flags Details
Latest Xorg.0.log (33.62 KB, text/plain)
2008-07-03 11:08 EDT, Fred New
no flags Details
Latest Xorg.0.log - July 24, 2008 (28.53 KB, text/plain)
2008-07-24 07:07 EDT, Fred New
no flags Details
X config works with fc8 but not with fc9 (1.33 KB, text/plain)
2008-11-01 19:15 EDT, Tommi R.
no flags Details
Xorg-log file when everything works just fine in fc8 (45.73 KB, text/plain)
2008-11-01 19:20 EDT, Tommi R.
no flags Details
X-log file with fc9, does not work (32.83 KB, text/plain)
2008-11-01 19:25 EDT, Tommi R.
no flags Details
Fedora 10 Xorg.0.log (36.75 KB, text/plain)
2008-12-01 06:50 EST, Fred New
no flags Details

  None (edit)
Description Fred New 2008-04-15 08:45:08 EDT
Description of problem:
Similar to bug 320711, but worse (and for Fedora 9 beta).  I think the summary
describes it all.  I am filing this, since bug 320711 is for F8 and probably
below the radar right now.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install F9-beta, fresh installation
Actual results:
My display resolution is set at 800 x 600 and flickering at 60 Hz.

Expected results:
At least 1024 x 768 @ 75 Hz like in Fedora 8.

Additional info:
lspci for my video controller -
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01)
Comment 1 Fred New 2008-04-15 08:45:08 EDT
Created attachment 302446 [details]
Latest Xorg-0.log
Comment 2 Fred New 2008-04-28 09:56:38 EDT
Created attachment 303977 [details]
Xorg.0.log from Fedora 8

I re-installed Fedora 8 on this same system so I could see if there is anything
to compare between the two Xorg.0.log files (F8 vs. F9).  The package versions
responsible for this (F8) log:
Fedora 8 permits me to select a resolution of 1400x1050 with "Millions of
Comment 3 Fred New 2008-04-29 10:39:23 EDT
One thing that stands out for me in the F9 log is the line
    (II) MGA(0): VESA VBE DDC read failed
Could this be an indicator of where the problem lies?  Where is the "already
built-in" ddc module?   
Comment 4 Bug Zapper 2008-05-14 05:28:46 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 5 Fred New 2008-06-04 08:30:20 EDT
Created attachment 308335 [details]
Xorg.0.log with the monitor attached to the digital port

The ddc/i2c probe works when I attach the monitor to the digital port of the
video card.  "Latest Xorg-0.log" was with the monitor attached to the analog
port.  GRUB and the kernel seem to treat the analog port as primary, though.
The digital side doesn't show the GRUB messages, nor do I see any early boot
messages.  And when my system finally finishes booting into runlevel 5, my
(digital) display is black.  I have better luck on the analog side where I get
the 800 x 600 display I've been complaining about.
Comment 6 Fred New 2008-06-10 08:53:55 EDT
As further research into this problem, I would like to build the xorg-x11-server
RPMs with the DEBUG flag.  That is, I would like to compile everything with the
"#ifdef DEBUG" paragraphs.  Can someone give me a pointer how to do this?
Comment 7 Fred New 2008-06-16 03:11:59 EDT
Created attachment 309464 [details]
Xorg.0.log after recent xorg-x11-server-* updates

This problem is still present with the latest updates to xorg-x11-server:
I have attached the latest Xorg.0.log, in case it helps.
Comment 8 Tim Malnati 2008-06-20 15:32:12 EDT
This issue is confirmed during upgrade installation as well.  The issue is worse
in this situation where the machine boots up to a monitor invalid scan frequency
making it impossible for the user to login.  Only known workaround is to either
boot single user or disconnect monitor during boot so xorg defaults to 800x600
(unknown monitor).  

Where this issue prevents normal user login it should be upgraded to at least High.
Comment 9 Fred New 2008-07-03 11:08:28 EDT
Created attachment 310930 [details]
Latest Xorg.0.log

With updates from updates-testing,
the log looks better, but I ended up with a black screen after Ctrl-Alt-Bkspace
and also after reboot.	I also complicated things by running
system-config-display once and selecting 1152x864.  I was able to get back to a
usable display by editing xorg.config and changing

		Modes	 "1152x864" "1024x768" "800x600" "640x480"
		Modes	 "800x600" "640x480"

Is there a workable way to get a higher resolution than 800x600?
Comment 10 Fred New 2008-07-04 06:56:42 EDT
If I add the "1024x768" resolution back to the Modes line in xorg.conf, it works
but the image quivers.  (Display = Samsung SyncMaster 203B LCD; Video card =
"Matrox Graphics, Inc. MGA G550 AGP")  Is it possible that the refresh rate is
set at a marginally acceptable value?
Comment 11 Fred New 2008-07-24 07:07:34 EDT
Created attachment 312541 [details]
Latest Xorg.0.log - July 24, 2008

With xorg-x11-server-Xorg-, my resolution
defaults to 1024x768, but as noted in comment #10, the image quivers.  I wonder
if this is healthy for my display.  Here's the latest Xorg.0.log.
Comment 12 Tommi R. 2008-11-01 19:15:36 EDT
Created attachment 322192 [details]
X config works with fc8 but not with fc9
Comment 13 Tommi R. 2008-11-01 19:18:30 EDT
I have same problem when upgraded to fc9, nothing better than 800x600 resolution does not work. 
My monitor is old PanaSync/Pro P110. Supported resolution from monitor spec is 1800x1440 and 1600x1200. However with fc8  I can get even 2048x1536 with single head and it works just fine. But normally I have used dual head and 1600x1200 (it is the highest I can get with dual head). But with fc9 I can not get higher than poor 800x600 what ever I try. I tried different Modelines from working Xorg.0.log from fc8 with no luck. Higher resolutions are always totally messed. 
I reinstalled fc8 system from backup and I have debugged this a lot but no success. Now I have dual boot to both fc8 and fc9.

As debugging I disconnected other monitor to get problem as simply as I can. Also I changed xorg.conf configuration to single head. Attached xorg.conf which works just fine with fc8 but not with fc9.

My old graphics controller specs by lspci -vv:

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01) (prog-if 00 [VGA controller])
        Subsystem: Matrox Graphics, Inc. Millennium G550 Dual Head DDR 32Mb
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (4000ns min, 8000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at f8000000 (32-bit, prefetchable) [size=32M]
        Region 1: Memory at fa000000 (32-bit, non-prefetchable) [size=16K]
        Region 2: Memory at fb000000 (32-bit, non-prefetchable) [size=8M]
        [virtual] Expansion ROM at fa020000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [f0] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1
        Kernel modules: matroxfb_base

Attached Xorg.0.log.single.fc8 from fc8 installation which works fine and also 
Xorg.0.log.single.fc9 which does not work. I can not find anything which could explain the difference. 

I would really appreciate anything which would help to fix this. Otherwise I need to still work by fc8 with this old "fellow", but I would like to uppgrade the whole stuff to fc9 and kde4. 

Some versions (the latest from fc9):
xorg-x11-server-Xorg.i386                1.5.0-2.fc9    
xorg-x11-drv-mga.i386                    1.4.9-1.fc9
Comment 14 Tommi R. 2008-11-01 19:20:52 EDT
Created attachment 322193 [details]
Xorg-log file when everything works just fine in fc8

Resolution 2048x1536 works just fine with fc8
Comment 15 Tommi R. 2008-11-01 19:25:26 EDT
Created attachment 322194 [details]
X-log file with fc9, does not work

This is log-file with fc9 when every resolution higher than 800x600 is totally messed up. Single head, one PanaSync/Pro P110 monitor connected to analog connector (DVI does not work any better).
Comment 16 Tim Malnati 2008-11-02 00:57:35 EDT
Here is the deal as I see it.  This issue has not received any attention from support.  Why is anyone's guess.  In my case I had to go back to FC8 (still there).  The history of this issue suggests that it will not be fixed in FC9 where FC10 is on the horizon.  I'm not sure if other video cards have been impacted in FC9 (non Matrox) but moving to a different vendor may be the only solution if you really need to work with FC9.
Comment 17 Will Woods 2008-11-14 12:46:47 EST
*** Bug 452615 has been marked as a duplicate of this bug. ***
Comment 18 Fred New 2008-12-01 06:50:54 EST
Created attachment 325222 [details]
Fedora 10 Xorg.0.log

I am now attempting to make this a Fedora 10 problem. (I don't know if Bugzilla will allow me to do it.) After upgrading to F10, it got much worse: I can see the ICBM graphical boot screen just fine, but then it's as if one of the missiles hits the observation satellite - everything goes black.  The only keys that do anything on the keyboard are Num Lock, Caps Lock and Scroll Lock - they turn their respective LEDs on and off.  I cannot reboot without using the reset button.

Current package versions:
Comment 19 Fred New 2008-12-01 06:52:29 EST
So let's see if I can make this an F10 problem while not attaching a file.
Comment 20 Tim Malnati 2008-12-02 12:01:12 EST
Probably the more important thing to change would be the severity.  At this point both version 9 and 10 are broken and version 8 is going out of support in a couple of weeks.  The people that are supposed to support this issue have not responded.  I certainly should not be expected to replace my video card because someone has trashed the code that supports it (it works fine in v8).  As things are looking at this point, it appears that I'll need to move to a different distro pretty soon.
Comment 21 Adam Jackson 2008-12-02 17:14:17 EST
(In reply to comment #20)
> Probably the more important thing to change would be the severity.  At this
> point both version 9 and 10 are broken and version 8 is going out of support in
> a couple of weeks.  The people that are supposed to support this issue have not
> responded.  I certainly should not be expected to replace my video card because
> someone has trashed the code that supports it (it works fine in v8).  As things
> are looking at this point, it appears that I'll need to move to a different
> distro pretty soon.

Pretty sure they're all going to be running mga 1.4.9 eventually, so, that's not really going to save you any heartache.
Comment 22 Fred New 2008-12-03 14:00:18 EST
Is there a patch we could add to this driver so that it logs the refresh rates it is actually attempting to use?  Or better yet, a hex dump of the refresh-rate bits it is sending to the adapter along with the address where it is sending those bits?  And a similar patch for the F8 driver would give us something to compare.
Comment 23 Fred New 2009-02-11 02:30:34 EST
As a work-around for this problem I have installed CentOS 5.  It doesn't have the great variety of packages available in Fedora, but at least my two desktop systems are working with up-to-date software.
Comment 24 Moritz Barsnick 2009-02-16 06:59:31 EST
Sounds very much like bug #466318: "Unable to boot Fedora 10Beta in graphics mode with Matrox MGA G550 graphics card."

There are workarounds suggested there. Perhaps this bug is a dupe of that one?
Comment 25 Fred New 2009-02-16 07:15:22 EST
Yep, it does look like bug #466318 is duplicate of this one.  Sorry, I don't have time to test the workaround.
Comment 26 Tim Malnati 2009-02-16 20:53:40 EST
I'm perplexed with the handling of this bug.  If this driver does not work (it doesn't), then why has the code not reverted back to the last know good?????  It would seem that distributing something that works is superior to something that's new.
Comment 27 Fred New 2009-02-17 05:25:05 EST
I think the problem is that the xorg-x11 base got upgraded, so the old driver no longer works.  The new xorg-x11 is working well for most people and they and the developers don't want to go back.  The mga driver is just one of the loose ends.
Comment 28 Tim Malnati 2009-02-17 17:14:43 EST
The xorg-x11 base could very well be the cause but there has been no verification of this that I'm aware of.  But there is no similar issue that I've seen reported in anything other than Fedora.  This tends to suggest that the Fedora implementation is more likely the issue.  If I remember correctly, the mga driver package was changed in some way too when this issue came to be.  It's certainly not clear if the original driver components will work or not with RH's way of doing things, but it seems to work fine with the other vendors.  But the idea that this issue is peculiar to Fedora now will only cause the problem to spread to the main RedHat product some day.  If RedHat is willing to decline supporting Matrox customers, then it is certainly their choice.  But I've certainly not seen enough input to this bug from RedHat Support and QA to know this is the case.  If anything, the lack of input gives me the impression that neither Support or QA care much about the issue.
Comment 29 Fred New 2009-06-17 06:39:20 EDT
I have added "vga=0x318" to my kernel boot line for Fedora 11 (and removed rhgb) and I am able to boot into runlevel 5 successfully.  Since I reported this problem, I believe this can be closed as a duplicate of bug # 466318.
Comment 30 Bug Zapper 2009-11-18 02:45:24 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 31 Fred New 2009-11-18 02:53:52 EST

*** This bug has been marked as a duplicate of bug 466318 ***

Note You need to log in before you can comment on or make changes to this bug.