Bug 161495

Created attachment 115890 [details]
Log generated while X is attempting to start up.

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.

$ 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

n/m - used ncftpget instead.

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.

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?

(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).

(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.

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,

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.

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.

(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.

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!

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".