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): 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.
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. Thanks
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.
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 (mozilla)
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 hdb6)
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
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 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.
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
I'm closing this bug. I am way past the waiting for X to start up quickly phase.