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): xorg-x11-drv-mga-1.4.8-1.fc9.i386 How reproducible: Always 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)
Created attachment 302446 [details] Latest Xorg-0.log
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: xorg-x11-server-Xorg-1.3.0.0-44.fc8 xorg-x11-drv-mga-1.4.6.1-6.fc8 Fedora 8 permits me to select a resolution of 1400x1050 with "Millions of Colors".
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?
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.
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?
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: xorg-x11-server-Xorg-1.4.99.902-3.20080612.fc9 xorg-x11-server-devel-1.4.99.902-3.20080612.fc9 xorg-x11-server-common-1.4.99.902-3.20080612.fc9 I have attached the latest Xorg.0.log, in case it helps.
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.
Created attachment 310930 [details] Latest Xorg.0.log With updates from updates-testing, xorg-x11-server-Xorg-1.4.99.905-1.20080701.fc9.i386 xorg-x11-drv-mga-1.4.9-1.fc9.i386 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" to Modes "800x600" "640x480" Is there a workable way to get a higher resolution than 800x600?
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?
Created attachment 312541 [details] Latest Xorg.0.log - July 24, 2008 With xorg-x11-server-Xorg-1.4.99.905-2.20080702.fc9.i386, 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.
Created attachment 322192 [details] X config works with fc8 but not with fc9
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
Created attachment 322193 [details] Xorg-log file when everything works just fine in fc8 Resolution 2048x1536 works just fine with fc8
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).
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.
*** Bug 452615 has been marked as a duplicate of this bug. ***
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: xorg-x11-drv-mga-1.4.9-1.fc9.i386 xorg-x11-server-Xorg-1.5.3-5.fc10.i386
So let's see if I can make this an F10 problem while not attaching a file.
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.
(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.
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.
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.
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?
Yep, it does look like bug #466318 is duplicate of this one. Sorry, I don't have time to test the workaround.
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.
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.
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.
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.
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** This bug has been marked as a duplicate of bug 466318 ***