Bug 161495 - DRI enabled by default hard-locks machine with Matrox G400
DRI enabled by default hard-locks machine with Matrox G400
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
4
All Linux
medium Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-23 14:34 EDT by Michael Lee Yohe
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-27 13:09:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log generated while X is attempting to start up. (36.67 KB, text/plain)
2005-06-23 14:34 EDT, Michael Lee Yohe
no flags Details
New hard-lock problem when trying to init 5 (38.49 KB, text/plain)
2005-06-23 15:34 EDT, Michael Lee Yohe
no flags Details

  None (edit)
Description Michael Lee Yohe 2005-06-23 14:34:17 EDT
Description of problem:

Freshly installed Fedora Core 4 on a machine that used to run FC3.  I have a
dual-head Matrox Millenium G400 video card (AGP).  I had no problems with X
before.  It now, however, hard-locks the machine (no response, blinkenlights,
etc.) whenever X starts up.

Version-Release number of selected component (if applicable):
xorg-x11-6.8.2-37

How reproducible:
Always.

Steps to Reproduce:
1. Start gdm or X manually.
  
Actual results:
1. Video switches from text to graphics (though no graphics appear).
2. Machine hard locks (completely unresponsive).

Expected results:
X starts up normally.

Additional info:
See /var/log/Xorg.0.log...
Comment 1 Michael Lee Yohe 2005-06-23 14:34:18 EDT
Created attachment 115890 [details]
Log generated while X is attempting to start up.
Comment 2 Mike A. Harris 2005-06-23 14:49:44 EDT
This problem is believed to possibly be a duplicate of bug #161242.  Please
read bug #161242 and test the libvgahw.a module that is available at
the following URL:

    ftp://people.redhat.com/mharris/libvgahw.a

Make a backup copy of the original libvgahw.a module prior to replacing it
with the one from above.  Once you've replaced it, restart the X server or
reboot the system.  After doing this, please indicate if there is any change
in the problem.  You may wish to CC yourself on bug #161242 as well, assuming
this does turn out to be a duplicate.

Also, please attach your X server log from /var/log and your X server config
file /etc/X11/xorg.conf to all X related bug reports, as this makes it
easier for developers to perform a diagnosis.

Thanks in advance.
Comment 3 Michael Lee Yohe 2005-06-23 14:53:16 EDT
$ wget ftp://people.redhat.com/mharris/libvgahw.a
--13:52:42--  ftp://people.redhat.com/mharris/libvgahw.a
           => `libvgahw.a'
Resolving people.redhat.com... 66.187.233.237
Connecting to people.redhat.com[66.187.233.237]:21... connected.
Logging in as anonymous ... Logged in!
==> SYST ... done.    ==> PWD ... done.
==> TYPE I ... done.  ==> CWD /mharris ... done.
==> PASV ... done.    ==> RETR libvgahw.a ... done.
libvgahw.a: Permission denied
Comment 4 Michael Lee Yohe 2005-06-23 14:54:30 EDT
n/m - used ncftpget instead.
Comment 5 Michael Lee Yohe 2005-06-23 14:56:48 EDT
Replacing libvgahw.a with the one from people didn't fix anything.  I still get
a hard lock.  Although I highly doubt this will affect anything, but this
machine is a dual processor box.
Comment 6 Michael Lee Yohe 2005-06-23 15:06:17 EDT
As per several comments, I replaced the xorg-x11 suite from FC4 with the latest
updates from FC3.  Oddly enough, I'm still getting a hard lock.

Could this be an optimization problem with GCC 4?
Comment 7 Mike A. Harris 2005-06-23 15:08:12 EDT
(In reply to comment #3)
> $ wget ftp://people.redhat.com/mharris/libvgahw.a
> --13:52:42--  ftp://people.redhat.com/mharris/libvgahw.a
>            => `libvgahw.a'
> Resolving people.redhat.com... 66.187.233.237
> Connecting to people.redhat.com[66.187.233.237]:21... connected.
> Logging in as anonymous ... Logged in!
> ==> SYST ... done.    ==> PWD ... done.
> ==> TYPE I ... done.  ==> CWD /mharris ... done.
> ==> PASV ... done.    ==> RETR libvgahw.a ... done.
> libvgahw.a: Permission denied
> 

-r--r--r--    1 mharris  mharris     20918 Jun 21 14:10 libvgahw.a

Must be local client issue on your end (the perm problem).
Comment 8 Mike A. Harris 2005-06-23 15:10:24 EDT
(In reply to comment #5)
> Replacing libvgahw.a with the one from people didn't fix anything.  I still get
> a hard lock.  Although I highly doubt this will affect anything, but this
> machine is a dual processor box.

Ok, then it appears your problem is different from the libvgahw issue.
Thanks for testing.


>drmOpenDevice: node name is /dev/dri/card0
>drmOpenDevice: open result is -1, (Unknown error 999)
>drmOpenDevice: open result is -1, (Unknown error 999)
>drmOpenDevice: Open failed
>drmOpenDevice: node name is /dev/dri/card0
>drmOpenDevice: open result is -1, (Unknown error 999)

Try disabling DRI and see if there are any changes.
Comment 9 Michael Lee Yohe 2005-06-23 15:29:35 EDT
Yeehaw - disabling "dri" in xorg.conf fixed the problem with the FC3 xorg-x11.

So this bug should be renamed to something that has to do with X unable to open
/dev/dri/ etc hard locks machine.

So this _is_ a separate bug.

Side note: Updated back to FC4 latest and greatest xorg-x11 packages - X still
gets brought up.  However, when X exits, the screen is so badly corrupted,
console is rendered useless.  Upon applying your workaround module - the display
is no longer corrupted (must reboot first).  Your libvgahw.a patch works for the
text corruption,

Comment 10 Michael Lee Yohe 2005-06-23 15:34:07 EDT
Created attachment 115896 [details]
New hard-lock problem when trying to init 5

Woohoo - another catch! (drum-roll)

I just set the inittab to runlevel 5.  When gdm attempts to fire up, X hard
locks the machine again.
Comment 11 Michael Lee Yohe 2005-06-23 15:36:35 EDT
Alright, Mike - not trying to be a pain in your six.  Apparently, when I ran
system-config-display, it re-enabled "dri" in the file (ignoring the change). 
I'll file a separate bug.
Comment 12 Mike A. Harris 2005-06-23 17:26:30 EDT
(In reply to comment #11)
> Alright, Mike - not trying to be a pain in your six.  Apparently, when I ran
> system-config-display, it re-enabled "dri" in the file (ignoring the change). 
> I'll file a separate bug.

"system-config-display --reconfig" intentionally generates a brand new config
file from scratch, completely ignoring any previous config file.

If you leave the --reconfig off, then it should read in the existing config
and parse it.

DRI is broken on mga currently, and has been for a while now.  Hopefully
X.org developers will fix it soon so we can avoid having to disable DRI
by default to avoid the problems.

Comment 13 Michael Lee Yohe 2005-06-24 00:01:13 EDT
Agreed - especially a pain since it doesn't just core-out X itself.  Hard
locking machine is NO GOOD. :)

I filed Bug 161507 - apparently system-config-display is broken because I didn't
even know about the --reconfig parameter.  It still reverts back to defaults.

Thanks for your help!
Comment 14 Mike A. Harris 2006-06-27 13:09:37 EDT
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:

        http://fedora.redhat.com/download

If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "CURRENTRELEASE".

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