Bug 128090 - X very slow during startup w/ 2.6.7-1.492 kernel
Summary: X very slow during startup w/ 2.6.7-1.492 kernel
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-07-17 15:39 UTC by Jim Cornette
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-09-09 22:53:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
This is the old x log. Xorg log did not seem present a moment ago (mc viewing) (101.74 KB, text/plain)
2004-07-17 15:42 UTC, Jim Cornette
no flags Details
latest xorg log (31.21 KB, text/plain)
2004-07-17 15:43 UTC, Jim Cornette
no flags Details
Second try without rebooting (29.80 KB, text/plain)
2004-07-17 17:00 UTC, Jim Cornette
no flags Details
X with 492- still slow, unresponsive (903 bytes, text/plain)
2004-07-17 22:30 UTC, Jim Cornette
no flags Details
log with all the changes to kernel versions, X w/ no manager (29.81 KB, text/plain)
2004-07-17 23:18 UTC, Jim Cornette
no flags Details
This is with a new kernel version and all updates, minus gtkhtml3 applied (30.83 KB, text/plain)
2004-07-23 03:38 UTC, Jim Cornette
no flags Details
/proc/mtrr before X started (132 bytes, text/plain)
2004-07-29 21:40 UTC, Jim Cornette
no flags Details
of course after X gets usable values into /proc/mtrr (203 bytes, text/plain)
2004-07-29 21:41 UTC, Jim Cornette
no flags Details
down and dirty uptime load line before launching bittorrent (63 bytes, text/plain)
2004-07-29 21:45 UTC, Jim Cornette
no flags Details
uptime during bittorrent launching and just before launching X (63 bytes, text/plain)
2004-07-29 21:47 UTC, Jim Cornette
no flags Details
xorg log with GNOME service failures (29.80 KB, text/plain)
2004-07-29 23:14 UTC, Jim Cornette
no flags Details

Description Jim Cornette 2004-07-17 15:39:08 UTC
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):
xorg-x11-6.7.0-6, kernel-2.6.7-1.492

How reproducible:
Didn't try

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.

Additional info:

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.

Comment 1 Jim Cornette 2004-07-17 15:42:03 UTC
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.

Comment 2 Jim Cornette 2004-07-17 15:43:28 UTC
Created attachment 101999 [details]
latest xorg log

This is the latest log entry.

Comment 3 Jim Cornette 2004-07-17 17:00:39 UTC
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.

Thanks

Comment 4 Mike A. Harris 2004-07-17 19:59:04 UTC
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
changes things.

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.

Comment 5 Jim Cornette 2004-07-17 22:30:20 UTC
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.

Comment 6 Jim Cornette 2004-07-17 23:12:40 UTC
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
(mozilla)

Comment 7 Jim Cornette 2004-07-17 23:18:13 UTC
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.

Comment 8 Jim Cornette 2004-07-23 03:38:10 UTC
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.

Comment 9 Mike A. Harris 2004-07-28 17:29:58 UTC
Reassigning bug to kernel component.  Nothing has changed in X which
would result in a slowdown at startup time.

Comment 10 Arjan van de Ven 2004-07-28 17:33:04 UTC
breaking mtrr's can do this quite easily....

Comment 11 Jim Cornette 2004-07-29 21:40:27 UTC
Created attachment 102302 [details]
/proc/mtrr before X started

Comment 12 Jim Cornette 2004-07-29 21:41:36 UTC
Created attachment 102303 [details]
of course after X gets usable values into /proc/mtrr

Comment 13 Jim Cornette 2004-07-29 21:45:59 UTC
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
hdb6)

Comment 14 Jim Cornette 2004-07-29 21:47:50 UTC
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.
END

Comment 15 Jim Cornette 2004-07-29 23:14:28 UTC
Created attachment 102309 [details]
xorg log with GNOME service failures

Are these related problems?

Comment 16 Jim Cornette 2004-07-31 00:28:50 UTC
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
bittorrent tracker.)
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
services.
I know that starting a bittorrent download takes a lot of time with
reading the isos. I'll try next time without starting bittorrent.

Comment 17 Jim Cornette 2004-08-05 02:54:31 UTC
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.

lspci -n
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:
http://www.redhat.com/archives/fedora-test-list/2004-July/msg00689.html


Comment 18 Jim Cornette 2004-09-09 22:53:36 UTC
I'm closing this bug. I am way past the waiting for X to start up
quickly phase.



Note You need to log in before you can comment on or make changes to this bug.