Red Hat Bugzilla – Bug 477234
libdrm-2.4.3-0.1.fc11.x86_64.rpm does not allow gnome/X to start up
Last modified: 2009-11-05 14:19:46 EST
Description of problem:
libdrm-2.4.3-0.1.fc11.x86_64.rpm seems to "break" X/gdm/????
Sorry, but my efforts to restore have erased the crumbs.
Is this known? Should I reinstall and recreate the trail?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install updates.
2. Black screen of death after plymouth
3. Power reset/reboot to recover; revert libdrm.
Sorry, forgot to mention: Thinkpad X61, intel 965 graphics.
I'm not sure, but this may have something to do with symbolic links maybe...:
/usr/bin/glx_tfp_test: error while loading shared libraries: libdrm.so.2: cannot open shared object file: No such file or directory
(II) Loading /usr/lib64/xorg/modules/extensions//libdri.so
dlopen: libdrm.so.2: cannot open shared object file: No such file or directory
(EE) Failed to load /usr/lib64/xorg/modules/extensions//libdri.so
(II) UnloadModule: "dri"
I think I get this when I revert to libdrm-2.4.0-0.21.fc10.x86_64. Believe I 'fixed this' by running /sbin/ldconfig manually.
There is a problem here.....
Here are lines from /var/log/messages after I updated libdrm and logged out:
Dec 20 09:58:58 tlondon gdm-simple-slave: DEBUG(+): GdmSlave: Creating proxy for /org/gnome/DisplayManager/Display1
Dec 20 09:58:58 tlondon gdm-simple-slave: DEBUG(+): GdmSlave: Got display id: /org/gnome/DisplayManager/Display1
Dec 20 09:58:58 tlondon gdm-simple-slave: DEBUG(+): GdmSignalHandler: Adding handler 11: signum=10 0x40c840
Dec 20 09:58:58 tlondon gdm-simple-slave: DEBUG(+): GdmServer: Starting X server process: /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-IS7nMQ/database -nolisten tcp vt1
Dec 20 09:58:58 tlondon gdm-simple-slave: DEBUG(+): GdmServer: Opening logfile for server /var/log/gdm/:0.log
Dec 20 09:58:58 tlondon gdm-simple-slave: DEBUG(+): GdmServer: Started X server process 4964 - waiting for READY
Dec 20 09:58:58 tlondon gdm-simple-slave: DEBUG(+): GdmSimpleSlave: Started X server
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): GdmServer: child (pid:4964) done (status:127)
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): GdmSimpleSlave: server exited with code 127#012
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): slave finished
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): GdmSimpleSlave: Stopping simple_slave
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): GdmSlave: Stopping slave
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): GdmSlave: Disconnected from display
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): GdmSignalHandler: Removing handler 10: signum=11 0x40c840
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): GdmSlave: Stopping slave
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): GdmSignalHandler: Finalizing signal handler
Dec 20 09:58:59 tlondon gdm-simple-slave: DEBUG(+): Slave finished
Dec 20 09:58:59 tlondon gdm-binary: WARNING: GdmDisplay: display lasted 0.728944 seconds
This appears to repeat over and over again with the display "number" incrementing from 0, 1, 2, ....
I attach a more complete snippet of /var/log/messages, as well as one of the Xorg.0.log files.
Created attachment 327548 [details]
More complete snippet from /var/log/messages with libdrm/X failing
entries from /var/log/messages when X fails to start.
Created attachment 327550 [details]
Xorg.0.log generated when X fails to start
Xorg.0.log when server fails to "start".
There are several of these, Xorg..log, appears mostly the same.....
Reverting libdrm "makes it work for me".
Again, system is Thinkpad X61 w/ Intel 965 graphics.
Also, I have compiz enabled....
the same problem here with hp nx6125 ati radeon xpress 200 i386.
please fix it asap.
same with intel driver and i386 system
OK, with updates from today's rawhide (and/or koji), all seems to work for me (Thinkpad X61, Intel 965 graphics).
Here are the packages that I updated today:
Dec 21 09:59:01 Updated: libdrm-2.4.3-0.1.fc11.x86_64
Dec 21 09:59:09 Updated: mesa-dri-drivers-7.3-0.2.fc11.x86_64
Dec 21 09:59:09 Updated: mesa-libGL-7.3-0.2.fc11.x86_64
Dec 21 09:59:10 Updated: mesa-libGLU-7.3-0.2.fc11.x86_64
Dec 21 09:59:26 Updated: xorg-x11-drv-i810-220.127.116.11-0.1.fc11.x86_64
Dec 21 10:00:03 Updated: glx-utils-7.3-0.2.fc11.x86_64
Dec 21 10:00:11 Installed: libdrm-devel-2.4.3-0.1.fc11.x86_64
Dec 21 10:00:11 Installed: libXdamage-devel-1.1.1-5.fc11.x86_64
Dec 21 10:00:12 Installed: libXxf86vm-devel-1.0.2-1.fc10.x86_64
Dec 21 10:00:22 Updated: mesa-libGL-devel-7.3-0.2.fc11.x86_64
Dec 21 10:00:24 Updated: mesa-libGLU-devel-7.3-0.2.fc11.x86_64
Also, updated this yesterday:
Dec 20 16:45:47 Installed: libXvMC-1.0.4-5.fc10.x86_64
Not sure which of these (or others) made this work.....
I do notice a difference in behavior: graphical login screen (gdm and friends) now come up in higher resolution (believe 1400x1050), and the background does not flicker and resize several times as gnome comes up. The same background stays displayed. I had to down-res to 1280x1024 since my monitor wasn't doing a perfect job displaying 1400x1050.
This is quite good!!!!!
works for me too .. i965 and i386
works also for me with i386 and and driver intel.
after this morning updates my system is not working any more again:
I reverted to a previous release of intel-driver: no luck.
I tried to revert to a previous release of libdrm but due to dependency problems I didn't succeed.
No idea how to proceed.
Created attachment 327647 [details]
Xorg.0.log after this morning updates
I don't know if libdrm is causing this...
system is o.k and working reverting to:
I do not know what is causing the problem, and if problem will start
also on other systems: no time for experiments now, someone else will
carry out such tests.
my system still not working (in the last two weeks) even with the latest libdrm and the rawhide's xorg ati package fail because it has different xorg version then the other packages.
even the downgrade didn't help he. at least if someone tell me exactly which package to downgrade...?
And here we are with backtrace:
0: /usr/bin/X(xorg_backtrace+0x3b) [0x812d07b]
1: /usr/bin/X(xf86SigHandler+0x51) [0x80bf9f1]
3: /usr/bin/X(xf86CrtcSetModeTransform+0x1e7) [0x80e7527]
4: /usr/bin/X(xf86CrtcSetMode+0x36) [0x80e7eb6]
5: /usr/lib/xorg/modules/drivers//intel_drv.so(i830GetLoadDetectPipe+0x15d) [0x1df7cd]
6: /usr/lib/xorg/modules/drivers//intel_drv.so [0x1fd22d]
7: /usr/bin/X(xf86ProbeOutputModes+0x1a0) [0x80e8270]
8: /usr/bin/X(xf86InitialConfiguration+0x132) [0x80e8df2]
9: /usr/lib/xorg/modules/drivers//intel_drv.so [0x1e4f09]
10: /usr/lib/xorg/modules/drivers//intel_drv.so [0x1e7385]
11: /usr/bin/X(InitOutput+0xe13) [0x80a8813]
12: /usr/bin/X(main+0x1e1) [0x806b5d1]
13: /lib/libc.so.6(__libc_start_main+0xe5) [0x71f6d5]
14: /usr/bin/X [0x806ac61]
I think you could try to fiddle with xorg-x11-drv-i810 and xorg-x11-server-Xorg -- that looks like where are fun happens.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command
yum upgrade --enablerepo='*-updates-testing'
Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .
Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.
If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Closing as fixed in Rawhide.