From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Description of problem:
After updating xinitrc (yum update xinitrc) yesterday, I noticed that
all openGL applications from screensavers to games (UT2003, neverball,
etc) were now about 10% of their original speed.
After using a combination of glxgears & ps -ef | ** & $top cmds to try
to figure out what was up, I came up with this theory which seems to
respond positively to testing:
The latest xinitrc (4.0.13-1) appears in the script named
/etc/X11/xinit/xinitrc, to launch Xclients as "clients" of dbus:
*** excerpted from latest xinitrc script ***
exec $SSH_AGENT $DBUS_LAUNCH $HOME/.Xclients || \
exec $DBUS_LAUNCH $HOME/.Xclients
*** end of excerpt ***
Prior to this version (>2 days ago) , Xclients was launched with
ssh-agents but not with dbus.
I tested by using the prior version of xinitrc script from the package
before the current one and all performance is fine without dbus in the
Dbus is still in use in the system for other purposes that aren't
quite as timeslice-needy as X , but something in the scheme of
prioritizing & message passing looks as if it needs some work if
people are to be able to use OGL apps without trouble using the latest
dbus & xinitrc packages.
I'm not sure what information to provide, but I'm able to switch
easily from version to version so anything that's needed will be easy
to show output from if asked for.
Occasionally , using the new scheme with dbus being bandwidth master,
I was able to get a more or less quescent state where X worked fairly
well. It would only happen if I ran the X app as the very first
application when there was >300K free memory so possibly other things
and priorities of (just a guess, kswapd?) are playing into this. But
99% of the time, dbus is a bottleneck, or so it appears.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install latest dbus & xinitrc packages (as of 07Oct04)
2. Startx (which is kde in my case)
3. Run an OGL X11 intensive program and check the performance.
Actual Results: OGL apps like UT2003 & Pipes screensaver & glxgears
ran at ~10-20% of their original performance.
Expected Results: I expected OGL apps to run with good performance as
My system is all 100% latest development / rawhide.
Its on an nf7 abit nforce2 based mobo with a 2400+ athlon xp + 512mb
My desktop of the moment is KDE
DBus has been in xinitrc since August:
* Wed Aug 25 2004 Colin Walters <firstname.lastname@example.org> 4.0.3-1
- Add DBus session to Xsession, xinitrc
All it does is start dbus, set an enviornment variable so apps can
find the session bus and then spawns the session.
CC'ing Mike Harris on this. Mike, you made the latest changes in
xinitrc. Can you think of a reason Mickey might be seeing this?
*** Bug 135075 has been marked as a duplicate of this bug. ***
Mickey and Scott can you take the DBUS stuff out of the xinitrc and
see if things speed up? If not then it could be other issues.
I removed the DBUS references from xinitrc (new vers), and it speeds
things up to "normal". I'm sure you know best when dbus went into
xinitrc, but perhaps its something to do with how dbus itself is
working. I recall also updating dbus so its a somewhat uncontrolled
environment here. The only thing I'm sure of is that all yum installed
packages on my box are up to date insofar as rawhide (dev tree) goes.
When I diff xinitrc (new) with xinitrc from the prior package, I only
see the DBUS parameter on the start line in the newer package,
although there's other references to DBUS in both. I'd attach them
(and will if requested) but I suppose this is something you've already
checked out and have access too as well.
By the way: Does it make sense to have two simultaneous processes (the
DBUS + Xclients & the ssh-* + Xclients ) running? This is what happens
with the latest version and is easily seen in the latest copy of
xinitrc. I can only recall ever seeing one before this (the ssh one).
They are needed just to set the eviornment variables for the entire
session. Can you post the diff from your two versions. I just want
to check them against mine. Last changes I made to dbus were to NULL
out some variables when freed and to change the dbus activation code
to look in /usr/shared instead of /usr/lib.
Created attachment 104946 [details]
diff between old version (first) and current version of xinintrc
One other note is that I needed to change the following line to include the
# Xsession and xinitrc scripts which has been factored out to avoid duplication
because it failed to find the *common file. Without changing it I couldn't run
startx and have X run without an error.
I have tried to duplicate what you are seeing and glxgears seems to
run at the same speed with or without dbus in the session.
By closing this are you saying that it is ok for GL screensavers to be
running at 1.7 frames per second, or that you do not see them running
Honestly, I did not try to duplicate Mick's results, 'cause I was a
bit lost in what he was saying he changed, so do I need to file
another bug? perhaps this is an xorg problem with the GL mesa libs?
Scott: I can't speak for John, but most likely he attempted to
reproduce it and wasn't able to, and meant to close the bug
as WORKSFORME but chose NOTABUG by accident. That's just a
personal assumption though.
I think what you are encountering here is not an xinitrc nor
dbus bug but rather an rhgb bug. rhgb starts up an X server
for graphical boot, and then it starts up a second X server
which is the real X server. The problem is, in the past this
was done sequentially and things "just worked", but now in order
to eliminate the 1-5 second flicker to text mode and back between
the 2 X servers, rhgb starts the second server and waits for
it to start up before switching. This causes 2 X servers to
both be running simultaneously.
Because of this, the first X server gets DRI support, but the
second one gets no DRI support because only one X server can
have DRI if multiple servers are running.
The result of this, is that users essentially lose 3D acceleration
in rawhide right now. We are currently exploring how to fix this,
but for now, users can simply disable rhgb by doing:
rpm -e rhgb
or modifying their grub.conf
Hope this helps.
That was it!
You know I don't have any idea why I ever use rhgb, I always select to
show details... Maybe just to see what it's breaking.
For the record, I can't remeber closing the bug, just posting a quick
comment. Sorry for that but it looks like it got resolved. Thanks.
Sorry, I was away for work, not paying attention here, but while I
could duplicate the bug, I used dbus-monitor (--session and --system)
to no real avail. A few errors that I know weren't related, but
nothing of interest.
I think my initial take on the problem was incorrect, and will report
back after installing today's rawhide. It's probably right that this
version of the bug be closed.
The closest I've come to finding an actual cause is realizing that
this only happens when another X11 app is running (like firefox), and
is intermittent, but I'm trying to cross-reference pmap -x's of both
and figure out what perhaps changed there.
Thanks, sorry for the mis-reported bug.
*** This bug has been marked as a duplicate of 135209 ***
rhgb-0.14.1-1 appears to have fixed the problem on my box.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.