Bug 169238

Created attachment 119242 [details]
Log of messages containing kdm failure to open

Changes summary to reflect problem more accurately.

Enabled selinux and auditd. Upgraded to xorg-x11-6.8.2-37.FC4.49.2. Problem is
repeatable. 

> rm: cannot remove "/var/run/xdcmtl/dcmtl" : Is directory

Did you cut and paste this from somewhere, or did you type it in by hand
manually?  Is that the real dirname/filename, or could you have made a
typographical error manually typing it in?

The reason I ask, is because I'm unable to find any reference in the OS
to this directory/file "/var/run/xdcmtl/dcmtl", and google doesn't find
it anywhere either.  Google suggests "xdmctl".

Either way, I'm not sure what that is, or why you'd be seeing that error,
but I think it is not related to the problem you are experiencing.

Please paste the output of "rpm -qa |grep xorg-x11 | sort".

Thanks in advance.

Setting status to "NEEDINFO_REPORTER"

[root@fc4i386 etc]# grep -r xdmctl *
grep: alternatives/jaxp_parser_impl: No such file or directory
grep: httpd/run/sdp: No such device or address
grep: httpd/run/dbus/system_bus_socket: No such device or address
grep: httpd/run/acpid.socket: No such device or address
selinux/targeted/contexts/files/file_contexts:/var/run/xdmctl(/.*)?            
system_u:object_r:xdm_var_run_t
grep: X11/X.rpmsave: No such file or directory
grep: X11/X: No such file or directory

I typed the error message in by hand.  There's a typo: "xdcmtl/dcmtl" should be
"xdmctl/dmctl". 

The install xorg-x11 rpms are as follows:

 xorg-x11-Mesa-libGLU-6.8.2-37.FC4.49.2
 xorg-x11-deprecated-libs-devel-6.8.2-37.FC4.49.2
 xorg-x11-devel-6.8.2-37.FC4.49.2
 xorg-x11-libs-6.8.2-37.FC4.49.2
 xorg-x11-xauth-6.8.2-37.FC4.49.2
 xorg-x11-deprecated-libs-6.8.2-37.FC4.49.2
 xorg-x11-xdm-6.8.2-37.FC4.49.2
 xorg-x11-Mesa-libGL-6.8.2-37.FC4.49.2
 xorg-x11-xfs-6.8.2-37.FC4.49.2
 xorg-x11-tools-6.8.2-37.FC4.49.2
 xorg-x11-6.8.2-37.FC4.49.2
 xorg-x11-font-utils-6.8.2-37.FC4.49.2
 xorg-x11-twm-6.8.2-37.FC4.49.2

I performed some additional testing.  The following combination of packages works:

xorg-x11-6.8.2-37.FC4.49.2
xorg-x11-deprecated-libs-6.8.2-37.FC4.49.2
xorg-x11-deprecated-libs-devel-6.8.2-37.FC4.49.2
xorg-x11-devel-6.8.2-37.FC4.49.2
xorg-x11-font-utils-6.8.2-37.FC4.45
xorg-x11-libs-6.8.2-37.FC4.49.2
xorg-x11-Mesa-libGL-6.8.2-37.FC4.45
xorg-x11-Mesa-libGLU-6.8.2-37.FC4.45
xorg-x11-tools-6.8.2-37.FC4.45
xorg-x11-twm-6.8.2-37.FC4.49.2
xorg-x11-xauth-6.8.2-37.FC4.49.2
xorg-x11-xdm-6.8.2-37.FC4.49.2
xorg-x11-xfs-6.8.2-37.FC4.49.2


Upgrading the FC4.45 to FC4.49.2 release of any of these packages causes GDM or
KDM to fail to start:

xorg-x11-font-utils
xorg-x11-Mesa-libGL
xorg-x11-Mesa-libGLU
xorg-x11-tools

Please disregard previous post.  System is very unstable with the updated
FC4.49.2 upgrade packages.  Upgrading to xorg-x11-6.8.2-37.FC4.49.2 with its
required xorg-x11-xxx.FC4.49.2 dependenency packages I can get X to start when
switching from runlevel 3 to runlevel 5.  However, X fails to start when the
system is rebooted. 

I have a card with radeon 7000 on three  Athlon 64 bit systems---three different
monitors, but same problem on all three as described above.  More precisely, the
chip, as reported by the system, is

ATI Radeon RV100 QY [Radeon 7000/VE]

The last of the three systems was installed 1 week ago, and was working fine
with original FC4 of the DVD, but after running 'yum update', I started to see
the problem.  Here is what I _can_ do:

When the machine boots (I already disabled 'rhgb quiet'), I press 'i' for
interactive mode.  Right after the local service starts, I hold down Alt-F1, and
after the monitor flickering just once a bit, I get virtual console 1.  I now
press Alt-F7, and  I see the gdm greeting screen, and all is well.  I do not
always succeed in getting to VC1, but almost always; I guess "it" (whatever it
is) just has to get the Alt-F1 at the right time.

Here is the gdm log file

# cat \:0.log

X Window System Version 6.8.2
Release Date: 9 February 2005
X Protocol Version 11, Revision 0, Release 6.8.2
Build Operating System: Linux 2.6.9-22.ELsmp x86_64 [ELF]
Current Operating System: Linux localhost.localdomain 2.6.14-1.1653_FC4 #1 Tue
Dec 13 21:34:16 EST 2005 x86_64
Build Date: 21 September 2005
Build Host: hs20-bc1-5.build.redhat.com

        Before reporting problems, check http://wiki.X.Org
        to make sure that you have the latest version.
Module Loader present
OS Kernel: Linux version 2.6.14-1.1653_FC4 (bhcompile.redhat.com)
(gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Tue Dec 13 21:34:16 EST 2005
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 20 01:33:42 2005
(==) Using config file: "/etc/X11/xorg.conf"
Could not init font path element /usr/lib/X11/fonts/CID, removing from list!

Two comments:

Despite the fact that I have the commented

#       Load  "dri"

line in /etc/X11/xorg.conf, the xorg logfile reports

(WW) RADEON(0): Direct Rendering is disabled by default on Radeon VE/7000
        hardware due to instability, but has been forced on with
        "Option "dri" in xorg.conf.  You may experience instability.

So I double checked:

]# grep -i option /etc/X11/xorg.conf
#       Option  "Xleds"         "1 2 3"
#       Option  "XkbDisable"
#       Option  "XkbModel"      "pc102"
#       Option  "XkbModel"      "microsoft"
#       Option  "XkbLayout"     "de"
#       Option  "XkbLayout"     "de"
#       Option  "XkbVariant"    "nodeadkeys"
#       Option  "XkbOptions"    "ctrl:swapcaps"
#       Option  "XkbOptions"    "ctrl:nocaps"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "us"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "yes"
        Option      "dpms"

The other remark is that the system is usable otherwise.  For example, the sequence

C-M-F1
C-M-Del

reboots it.

I am having the same problem.  gdm cannot start x upon entering RL 5.

however, i can start x manually from an RL 3 login with startx.  

following rpms installed:
xorg-x11-doc-6.8.2-37.FC4.49.2
xorg-x11-sdk-6.8.2-37.FC4.49.2
xorg-x11-xdm-6.8.2-37.FC4.49.2
xorg-x11-xfs-6.8.2-37.FC4.49.2
xorg-x11-deprecated-libs-devel-6.8.2-37.FC4.49.2
xorg-x11-xauth-6.8.2-37.FC4.49.2
xorg-x11-font-utils-6.8.2-37.FC4.49.2
xorg-x11-Xdmx-6.8.2-37.FC4.49.2
xorg-x11-Xnest-6.8.2-37.FC4.49.2
xorg-x11-twm-6.8.2-37.FC4.49.2
xorg-x11-libs-6.8.2-37.FC4.49.2
xorg-x11-Mesa-libGLU-6.8.2-37.FC4.49.2
xorg-x11-deprecated-libs-6.8.2-37.FC4.49.2
xorg-x11-6.8.2-37.FC4.49.2
xorg-x11-tools-6.8.2-37.FC4.49.2
xorg-x11-Mesa-libGL-6.8.2-37.FC4.49.2
xorg-x11-devel-6.8.2-37.FC4.49.2
xorg-x11-Xvfb-6.8.2-37.FC4.49.2


the gdm log stops at this line:
(==) Using config file: "/etc/X11/xorg.conf"

completely consistent behavior -- always happens on entry to RL 5.

i telnetted in and captured an Xorg.0.log during the fail.  and compared it to
the one from my manual startx.  the only significant difference (i.e. not
timestamp) was:
48c48
< (++) using VT number 7
---
> (--) using VT number 7

the second line (--) is from the log of the successful manual startx.

Created attachment 123066 [details]
syslog showing initial failure, wait 2 minutes, second failure

here's the syslog of a failure, which i grabbed from a telnet session while gdm
was hung trying to start.

it initially failed to start after ?6 tries, presented a message box to say it
would wait 2 minutes, and then tried again.   the log shows this period.

Created attachment 123132 [details]
side by side diff of failed and successful X startups

i switched back to the nv driver to be sure that it was not something to do
with the nvidia driver.  i copied off an Xorg.0.log while the system was
attempting (and failing) to boot into RL 5.  then i rebooted into RL 3, logged
in and manually did a startx from a non-root user.  as usual, this time X
started.  

i have attached a side by side diff of the two logs.  what seems interesting to
me  is that the left (failed side) does not appear to be able to identify the
monitor, while the right (successful manual invocation) side does seem to be
able to do so.

note the section of differences beginning with:
<snip>
(II) NV(0): Probing for EDID on I2C bus A...			(II) NV(0):
Probing for EDID on I2C bus A...
(II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0.	(II) NV(0): I2C
device "DDC:ddc2" registered at address 0xA0.
(II) NV(0): I2C device "DDC:ddc2" removed.			(II) NV(0): I2C
device "DDC:ddc2" removed.
(II) NV(0):   ... none found				      | (--) NV(0): DDC
detected a CRT:
							      > (II) NV(0):
Manufacturer: HIQ  Model: 91da	Serial#: 8060
							      > (II) NV(0):
Year: 2005  Week: 28
							      > (II) NV(0):
EDID Version: 1.3
							      > (II) NV(0):
Analog Display Input,  Input Voltage Level: 0.700
							      > (II) NV(0):
Sync:  Separate
							      > (II) NV(0): Max
H-Image Size [cm]: horiz.: 37  vert.: 30
							      > (II) NV(0):
Gamma: 2.20
							      > (II) NV(0):
DPMS capabilities: StandBy Suspend Off; RGB/Color
<snip>

this seems to be a significant difference?  what can i do to help?  does this
help?  is anyone there?

I have 3 FC4 systems that are having similar symptoms.  See :
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178073

Greg Ennis

(In reply to comment #9)
> Two comments:
> 
> Despite the fact that I have the commented
> 
> #       Load  "dri"
> 
> line in /etc/X11/xorg.conf, the xorg logfile reports
> 
> (WW) RADEON(0): Direct Rendering is disabled by default on Radeon VE/7000
>         hardware due to instability, but has been forced on with
>         "Option "dri" in xorg.conf.  You may experience instability.

Yes, that is 100% correct operation.  The "Load" lines in the X config file
load X server modules into memory.  That is all they do.  Loading the DRI
module into the X server's memory space, makes the X server "DRI capable",
however it very much does *NOT* "enable DRI".  Commenting the module out,
does however disable DRI, but only because not loading the module at all,
makes the DRI functionality unavailable to individual drivers.

There is a great misconception in the public for some reason about this.

It is the individual video drivers that determine wether or not DRI will
be enabled or disabled on a per driver basis.  By default, each video driver
examines the current configuration, and determines wether the current
configuration is compatible with the implementation of DRI for the particular
hardware (or wether DRI is even implemented at all for the current hardware).
If DRI is not implemented for that hardware, or if the driver determines that
the current configuration is incompatible with DRI for any reason, the driver
may decide to disable DRI functionality, at which point it will echo a message
to the log that DRI is disabled.  The X server "DRI" extension remains loaded,
however the DRI functionality in the driver is what is disabled.


This bug is getting rather confusing.  It is a bug filed about a Radeon
problem, which other people are jumping on with nvidia and other unrelated
problems, which makes it increasingly difficult to sort out the useful
information in the bug, and separate it from the information about other
totally unrelated problems.

As a polite request to everyone CC'd on this report, I'd like to ask
everyone to please stop adding nvidia and other unrelated comments to
this radeon bug report.  If you have a problem with other video hardware
that for whatever reason sounds similar to this bug, please file a new
bug report directly in X.Org bugzilla at http://bugs.freedesktop.org in
the "xorg" bug report.  Keep your bugs about one specific issue, on one
specific piece of hardware.  This may mean that multiple bugs get filed
by different people, but later if developers can determine that the
multiple bugs are in fact duplicates or caused by the same issue, it is
easier to close them as dupes later, than to have multiple people discussing
unrelated problems in a single bug report and trying to determine what
information is for what problem.


Additionally the following info:

 rm: cannot remove "/var/run/xdcmtl/dcmtl" : Is directory

has nothing to do with the radeon hardware working or not working in this
bug report.  I'm not sure why you're seeing that message, as none of the
rpm pre/post/etc. scripts do anything with that directory at all.  That
sounds more like an rpm problem, or local system issue of some sort, and
I am not able to reproduce it locally.  We have not had any other reports
of people experiencing that problem either, which suggests also that it
is a local issue perhaps.

Having said all of that, I am able to use both KDM and GDM on a fully
updated local test system with the indicated xorg-x11 version, with the
same video hardware.

Unless you can provide additional information that suggests that this is
an X server or driver bug, it is my opinion that this is a local configuration
issue or SElinux interference with your configuration.

Since it is not easy to conclude anything 100% however at this point, I
strongly recommend posting to xorg.org about the problem
and seeking technical assistance to determine the problem and/or narrow it
down.  Then if a real bug can be found which turns out to be a bug in the
X server or driver, please update this bug report with the updated details.

Thanks in advance.


Setting status to NEEDINFO_REPORTER, and awaiting additional information.

mike, i'm truly sorry you had a bad day.  however, you may wish to think some
about how being unhelpful, rude and supercilious doesn't help any of us. 
neither does deliberately warping the problem so that you can ignore it further.

i hope you have a better day tomorrow.

i might even be willing to do some further investigation, had i some faint hope
that it wouldn't be rudely treated or ignored.

I am not sure he had a bad day, since he included a nice long explanation about
the issue.  But what needs to be realized that Radeon 7000 chips are unusable. 
I had three different cards with this chip, and while the computers were working
fine after initial installation of Fc4, as soon as I updated the system via

yum update

gdm could not start on any of them.  Changing the line 

FontPath        "unix/:7100"

did work on one computer for a while, but on the other two, I just changed to an
nvidia card.  Finally about a week ago the third system also gave in, and gdm
would not start.

Now, as far as Mike's 

> There is a great misconception in the public for some reason about this.

I'd like to remind him again about the error message

> Direct Rendering is disabled by default on Radeon VE/7000
>         hardware due to instability, but has been forced on with
>         "Option "dri" in xorg.conf.  You may experience instability.

Do not you think that this error message is certainly responsible for the
misconception?  I comment out the "dri" line, but the message above still claims
that my xorg conf's "dri" line forced Direct Rendering.

In any case, we are talking about a very severe problem, since for users the
computer is completely unusable, and there has been no remedy for at least four
months now.  

For the success of tracking down the problem, I would be glad to send my video
card to wherever RH might want me to.

(In reply to comment #15)
> mike, i'm truly sorry you had a bad day.

I didn't have a bad day. ;o)

> however, you may wish to think some
> about how being unhelpful, rude and supercilious doesn't help any of us. 

My comment was intended to summarize general thoughts on the issue, 
to try to steer future feedback from people experiencing the problem
to be more useful in diagnosing the problem, and to hopefully steer
people having unrelated problems to file their own separate bug reports
instead of cluttering up the original issue that was reported.  If you've
read my comment as rude, you got the wrong impression.

> neither does deliberately warping the problem so that you can ignore it
> further.

Additional information is required in this report before anything can
actively be done to solve it.  That's not ignoring anything, it's simply
stating the facts.

> i hope you have a better day tomorrow.

Every day is better than the last.  ;o)
 
> i might even be willing to do some further investigation, had i some faint
> hope that it wouldn't be rudely treated or ignored.

Even if there's no guarantee we can reproduce or fix a given problem, any
additional information that you can supply would be great.  Please be
careful however not to assume your issue is being ignored if nothing seems
to be getting done about it.  Some issues take longer to examine, reproduce,
diagnose, etc. than others, and unfortunately some issues can never be
reproduced, and thus may not be easily resolveable.  When in doubt, it is
best to report problems to X.Org bugzilla, or discuss them on public X.Org
mailing lists to maximize the number of developers, maintainers, and users
who are aware of the problem you are experiencing, and thus may be able
to collectively work together to diagnose and resolve a given issue.

The resources available in the X.Org community, greatly dwarf the hardware
and manpower resources available via Red Hat bugzilla.  Nonetheless, our
engineering team does our best to try to address as many issues as possible
over time.  Hopefully we'll be able to address this one as well.

Thanks in advance.

(In reply to comment #16)
> I am not sure he had a bad day, since he included a nice long explanation about
> the issue.

Correct.  ;o)

> But what needs to be realized that Radeon 7000 chips are unusable. 
> I had three different cards with this chip, and while the computers were working
> fine after initial installation of Fc4, as soon as I updated the system via

This bug was filed about Radeon 7200 initially.  For the time being at least,
I would like to assume that the 7200 issue is a separate issue from any
other Radeon hardware, or non-Radeon hardware, because we simply don't know
at this point.  There have been quite a number of Radeon 7000 related problems
in the Xorg 6.8.x series thus far, however they have been specific to that
chipset.  It may turn out later on that the Radeon 7200 problem reported
here is more generic than specific to that chip...  hard to say just yet,
but it's easier to close multiple bugs as a dupe later, than to try to
separate 2 or 3 separate issues out of one bug report later on.  ;o)

The reason I mention this here at all to you guys, is because I genuinely
want to help as best as possible.  Sometimes people group issues together
in one bug report, and when we fix the issue initially reported and close
the bug report as fixed, one or more people reopen the report to say that
their problem is still present, even though the original reporter has
claimed their problem is now fixed - thus indicating all of the people
are experiencing different problems all along.  ;o)

It can make life much more difficult as a developer to separate the issues
mentally and spend time fixing a given person's problem, if it is interspersed
with information from unrelated but similar symptomatic issues of other
people.  ;o)  That's all I was trying to say above.  It wasn't intended
to be rude or sound rude in any way.  Sometimes it's hard to word things
in a bug report in a way that will be universally read and carry a single
tone/mood with it I guess.  ;o)

I find adding additional smileys everywhere tends to have people interpret
things in a more friendly way though, so I'm using a lot of extra smileys
now, to make sure nobody thinks I'm being rude. ;o)

Have a good day all!  ;o)

 
> gdm could not start on any of them.  Changing the line 
> 
> FontPath        "unix/:7100"
> 
> did work on one computer for a while, but on the other two, I just changed to an
> nvidia card.  Finally about a week ago the third system also gave in, and gdm
> would not start.
> 
> Now, as far as Mike's 
> 
> > There is a great misconception in the public for some reason about this.
> 
> I'd like to remind him again about the error message
> 
> > Direct Rendering is disabled by default on Radeon VE/7000
> >         hardware due to instability, but has been forced on with
> >         "Option "dri" in xorg.conf.  You may experience instability.
> 
> Do not you think that this error message is certainly responsible for the
> misconception?  I comment out the "dri" line, but the message above still claims
> that my xorg conf's "dri" line forced Direct Rendering.
> 
> In any case, we are talking about a very severe problem, since for users the
> computer is completely unusable, and there has been no remedy for at least four
> months now.  
> 
> For the success of tracking down the problem, I would be glad to send my video
> card to wherever RH might want me to.

Upgrading FC4 to the 2.6.15 kernel on February 2nd caused X to fail on my
system. The Fedora List posted a fix which can be found here:
http://www.redhat.com/archives/fedora-test-list/2006-February/msg00179.html. 
Upgrading module-init-tools with module-init-tools-3.2-0.pre9.0.FC4.1.i386.rpm
fixed that problem. Since that worked I thought I would give the version 49.2
xorg-x11 packages a try. What do you know? The new version of module-init-tools
fixes the problem on my system! Now if you guys could clean up the garbage shown
when X is switching modes (blank screen/double buffer?) that would be really be
nice.

The fix worked for all of two reboots. After that the problem returned. I have
reverted back to v45.

Sorry for the noise. 

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