Red Hat Bugzilla – Bug 128090
X very slow during startup w/ 2.6.7-1.492 kernel
Last modified: 2007-11-30 17:10:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040625
Description of problem:
Initializing the system in runlevel 3 and doing a few things before
starting X from tty3, system was very slow. It seemed locked up, but
w/ after allowing time, system finally loaded up X.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Booting up in runlevel 3 and then logging into a shell on tty1 to
check root mail, no problem yet.
2.Logging into tty2 and starting a bittorrent application in the
shell. (FC3T1). Bittorent proceeded.
3.Logged into tty3 to run startx.
Actual Results: Once I started X from tty3, screen seemed to change
monitor to graphics mode. (clicked relay and was not illuminated.)
When trying to go to any of the terminals, they did not seem to react.
(tty1 or tty2)
Expected Results: I expected a normal initialize time for X to start.
This might be related to a priority level for X being low. I believe
initializing X quickly would save a lot of time for reports for not
really locked up systems. I did not try to reproduce this yet. I'll
try again afterbug submittal.
Created attachment 101998 [details]
This is the old x log. Xorg log did not seem present a moment ago (mc viewing)
I'll include current log after this report.
Created attachment 101999 [details]
latest xorg log
This is the latest log entry.
Created attachment 102001 [details]
Second try without rebooting
Though X seemed to have a lot of delay time when it was initializing, the
startx initializing of X did not seem like a lockup. The overall performance of
applications seems to be slower than normal and a lot of disk activity seems to
be going on.
If this report has any usful information to spiff up X on starting, use it.
Otherwise, I guess closing this and moving on is fine with me. There appears to
be no error log for X within my home directory.
If you've updated the kernel and had a change in behaviour of the
X server starting up, the primary suspect would be the new kernel.
Please downgrade your kernel to a previous kernel to see if that
Also, it is important to note that "startx" starts a lot more than
just the X server, it starts the entire GNOME desktop (or KDE, or
whatever other environment you use). If there is anything wrong
with any of those components that start after the desktop starts,
you wont get a useable desktop until everything that loads _after_
the X server has loaded too.
The X server itself, should take about 3 seconds, and no more than 6
seconds to load and initialize everything, before the startup
scripts start loading up desktop components, etc. In order to test
this out, please do the following:
1) Quit all instances of X that are running.
2) As a user, from the commandline type "X" all alone and hit enter.
That will start up the X server all by itself. You will get a blank
desktop with no applications or window managers running, and an "X"
shaped mouse cursor. The time it takes from hitting enter, until
the screen is a single color/pattern with the X cursor, is the X
server startup time. If this is 6 seconds or less, then your
slowdown is not occuring in the X server, but probably in the
desktop startup scripts (ie: GNOME) or something else.
If the X server does take more than 6 seconds to start, then it is
more likely to be a kernel problem. My first suggestion in this case
is to kill the X server with CTRL-ALT-BS, and start it up again with
"X" from the commandline, and immediately start moving the mouse
around and randomly tapping the SHIFT, CTRL, and ALT keys. While
this may sound like an odd request, it does ensure the kernel's
entropy pool is not empty, as that can sometimes cause X server
startup delays. (Although it is usually only noticed on Alpha
architecture for some reason, it occasionally occurs on x86, in
particular if the kernel has bugs in /dev/random) ;o)
At this stage, if you are able to pinpoint the problem to X server
startup, then I recommend killing the X server, and logging in from
another machine over the network, and starting up the X server from
the network shell. While doing this, watch the X server's startup
messages, and when the messages appear to delay or stop, possibly
indicating a hang that is waiting for something, hit the ENTER key
a few times, which should scroll the screen a bit. That will allow
you to isolate the point in X server startup that the hang occurs
at. Please cut and paste that into a text file and attach it
to the report if you're able to get this to happen.
Thanks for the report.
Created attachment 102009 [details]
X with 492- still slow, unresponsive
the text file attached was obtained by highlighting the messages on the
terminal, then starting cat >xcraft.txt and then right clicking the mouse to
paste the copied text to screen. This is with doing the same routine as when
the problem was noted.
Trying to change to a terminal seemed unresponsive and it took awhile for the
mouse cusrer to display. Switching the screem to graphics mode (clicking
relay,etc) seemed to happen within a few seconds.
I tried the original FC3T1 kernel out and X seemed slow and
unresponsive with that kernel also. I then got the latest kernel
released for FC2 and installed then rebooted the computer. Starting
X seemed like it was locked up with kernel-2.6.6-1.435.2.3 also. Since
the overall time is not extreme. (less than a minute). It is not
really easy to judge without a stopwatch.
I will attach the recent log for X with trying two different kernels
and just starting the X, then running startx to add to the bug report
Created attachment 102010 [details]
log with all the changes to kernel versions, X w/ no manager
The FC2 kernel-2.6.6-1.435.2.3 seems to do what the latest test kernel does for
responsiveness with X.
Created attachment 102164 [details]
This is with a new kernel version and all updates, minus gtkhtml3 applied
The mirror being used is hiwaay for update retrieval. This mirror seems
up2date. I logged in root tty1. Started bittorrent from a shell tty2 user jim.
Launched X again from tty3.
Reassigning bug to kernel component. Nothing has changed in X which
would result in a slowdown at startup time.
breaking mtrr's can do this quite easily....
Created attachment 102302 [details]
/proc/mtrr before X started
Created attachment 102303 [details]
of course after X gets usable values into /proc/mtrr
Created attachment 102304 [details]
down and dirty uptime load line before launching bittorrent
The bittorrent files are already on the computer. The process underway is
verifying the images. The images are on auxilary mounts (/dev/hda2) that are on
the same disk that this OS boots from. (contained in /dev/hdb3 as hdb5 and
Created attachment 102305 [details]
uptime during bittorrent launching and just before launching X
If there is any info that would be more valuable. I would provide such data.
Created attachment 102309 [details]
xorg log with GNOME service failures
Are these related problems?
Trying the same procedure used before. I tested out kernel-2.6.7-1.499
to see if there was any differences with the startup time. Bittorrent
took on a quick average (guestemate) around 60 percent of the CPU
processing. (Reading already downloaded ISOs, verifying with
X only averaged around 3 % CPU usage and was very very slow
initializing. X was slow and GNOME took a lot of time starting all
I know that starting a bittorrent download takes a lot of time with
reading the isos. I'll try next time without starting bittorrent.
I tried starting X w/o trying to launch bittorrent first. X was slow
on launching, but not extre...emly slow as when trying to launch
bittorrent before X.
Someone else who has a similar card and slowly starting firstboot
problem commented on the test list his problems w/ i815 driver. Dave
Jones asked for lspci -n output because of a possibility that this
problem could be. I had trouble pinpointing if his problem was similar
to mine or not.
Here is my output, just in case.
00:00.0 Class 0600: 8086:1130 (rev 02)
00:02.0 Class 0300: 8086:1132 (rev 02)
00:1e.0 Class 0604: 8086:2418 (rev 02)
00:1f.0 Class 0601: 8086:2410 (rev 02)
00:1f.1 Class 0101: 8086:2411 (rev 02)
00:1f.2 Class 0c03: 8086:2412 (rev 02)
00:1f.3 Class 0c05: 8086:2413 (rev 02)
00:1f.5 Class 0401: 8086:2415 (rev 02)
01:00.0 Class 0200: 10b7:9200 (rev 74)
01:01.0 Class 0200: 10ec:8029
the message referenced is linked below:
I'm closing this bug. I am way past the waiting for X to start up