Red Hat Bugzilla – Bug 125762
machine freezes with matrox millennium card
Last modified: 2007-11-30 17:10:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
When X is started, and the Matrox Millennium graphics card is
configured, the machine freezes (black screen, no response to
keyboard, stops responding to pings).
The machine is dual-head, and if only the other graphics card is
configured, it works fine. If only the Matrox card is configured,
the freeze still happens.
If I replace the files "mga_drv.o" and "mga_dri.o" with their
equivalents from RH8.0 (XFree86-4.2.1-23), the problem goes away. (I
replaced these driver files rather than installing the full package
since dependency issues make it hard to downgrade to that version of
It does seem to indicate that the problem is in one of these driver
files, since everything else (configuration files, HW setup etc) is
The same problem existed in FC1 but not in RH8.0.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Ensure the Matrox Millennium card is configured in XFree86
2. Type 'startx' or set the runlevel to 5
Actual Results: The screen turns black, and there is no response to
or network. A reboot is necessary.
Expected Results: The desktop or graphical login screen should appear.
I shall attempt to gather the X server logfiles from when the
system is working / not working.
Created attachment 101049 [details]
Xorg.0.log from when the system is working
This is the X server log from when the machine is working (i.e. when the
FC2 'mga*.o' files have been overwritten with the RH8.0 versions).
Created attachment 101050 [details]
Xorg.0.log from when the system crashes
This is the X server log file from when the system crashes (i.e. when
the unmodified FC2 packages are installed).
Created attachment 101051 [details]
My X configuration
For the attached X server logs, did you reboot into text mode
after the crash, and make backup copies of the X server logs,
or did you start the X server up, and then attach the logs found
in /var/log afterward?
Curious, because the log files both show the X server starting
up, but without any crash information in it. If you crash, and
then start up X again, the new log file overwrites the log file
from the crash.
Nothing stands out as being wrong in either log.
Please try the following:
Upgrade to the latest xorg-x11 release for FC2 (6.7.0-5), and then
Configure your multihead this way, then save the configuration,
and restart. Does the problem go away?
Created attachment 101700 [details]
The correct logfile for the "crash" case
Many thanks for looking into this.
I did indeed start up in text mode and copy the log file; however I seem to
have managed to add entirely the wrong log file. I'm attaching the correct one
This file does not appear to have any crash information in it either - but this
may be consistent with the fact that the machine froze entirely (rather than
just the X server process). (I had mounted the filesystem with "sync" to ensure
that as much of the log as possible got written to disk before the system
I am currently downloading the latest xorg-x11 packages; I will try out your
suggestion and post the results.
Created attachment 102121 [details]
Server log with xorg-x11 version 6.7.0-5
Simply upgrading to the latest xorg-x11 (6.7.0-5), without changing the
X configuration, resulted in exactly the same symptoms as before - machine
freezes, does not respond to keyboard or network, must be power cycled.
The new server log is attached - again, there does not appear to be any crash
Created attachment 102122 [details]
Output of "system-config-display --reconfig"
Running "system-config-display --reconfig" as suggested produces the attached
errors, and does not create an xorg.conf file.
Created attachment 102123 [details]
xorg.conf produced by system-config-display --reconfig -noui
Running "system-config-display --reconfig -noui" does produce an xorg.conf
file, which is attached.
This configuration file does not work, due to the lack of a "BusID" line. Once
the appropriate BusID line has been added, the machine freezes in the same
manner as always - no response to keyboard or network.
One more data point: if I replace just the mga_drv.o file with the one
from RH8.0 (XFree86-4.2.1-23), the problem goes away - suggesting the
problem lies within this file (rather than mga_dri.o, which I was
also replacing before).
Please let me know if there is any more information I can provide.
I can confirm this bug. I herd about 7 older machines with G200 cards
and VIA VT82C598 chipsets. After upgrading to FC1, these machines
began to freeze solid on X startup -- but only about half the time.
When this happened, X logs terminated in the middle without any
additional information (usually shortly after the DDC probing).
Sometimes a reboot would bring the machines up, sometimes they would
hang again before showing the gdm login screen. FC2 exhibited the
I could also often get the machines to hang by running
system-config-display, so I think it has something to do with the
Following the suggestions above, I copied mga_drv.o from a RH9
machine, and the problem appears to be solved. I would note that my
situation differs from the above only in that the systems didn't
freeze every time X started, but seemed to hang randomly about half of
I will be happy to provide any additional information that might be
This problem, which occurs on certain Millenium and Mystique models
is fixed in rawhide xorg-x11 184.108.40.2062, which I believe to be the
same problem described here. Please upgrade xorg to the rawhide
version to confirm if the problem is fixed for you.
Setting status to "RAWHIDE". If the issue persists after testing
this version, please file a bug report in X.Org bugzilla and paste
the URL here and reopen this report and we will track the issue
in the upstream bugzilla.
http://bugs.freedesktop.org - xorg component
Thanks for testing.
I installed the Rawhide xorg-x11 (xorg-x11-220.127.116.112-4.i386.rpm and
friends), but saw exactly the same problem, same symptoms. I have
raised the issue on the x.org bugzilla:
Ok thanks, we'll track the issue in the upstream bug report now.
Thanks for the feedback and testing.