Red Hat Bugzilla – Bug 113570
XServer locks up machine for over 4 mins while starting
Last modified: 2007-11-30 17:10:35 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;
Description of problem:
Everytime I try to start the XServer either by using the startx
script directly or starting in runlevel 5, my computer completely
locks up and becomes unresponsive for over 4 minutes. The keyboard
doesn't respond and the screen is blank. There is no disk activity.
It seems like the whole machine is dead. I also cannot switch to
another console while its locked up.
After the 4 plus minutes have elapsed, all the sudden the disk drive
starts going really heavy and the desktop appears within 15 seconds.
This is what it used to do under RedHat 6.2. The XServer under 6.2
would just come up immediately.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.login to the machine
Actual Results: As I explained in the description
Expected Results: I expect the hard drive to crank and put up a
display and desktop within a reasonable amount of time, without my
computer locking up rock solid.
Created attachment 97025 [details]
My XFree86 startup log
I128 video hardware is very old, and the I128 driver is more or
less unmaintained upstream for quite some time. Since we do not
have this ancient hardware, nor it's specifications, there isn't
much we can personally do about i128 driver malfunctions other
than to try to narrow down the problem with you, and try to isolate
the problem area of the driver.
In order to troubleshoot, please add the following to the driver
section of your config file:
After rebooting the machine, in order to reset the video hardware
to it's default power-on state and ensure it is not misprogrammed,
please start the X server with "startx" and see if the crash you
were observing has disappeared, or is still present. Please indicate
wether it works or not.
If it does seem to make the problem go away, remove the noaccel
option, and now we can try to determine which of the acceleration
primatives are related to the problem you're experiencing. To do
that, please read the XF86Config manpage, where you'll find a number
of options listed that start with XaaNoxxxxxxx. Please try each of
these options one at a time, restarting the X server (or your system)
between each invocation, to see if the given option works around
the problem. If the X server does start and seem to work, please
exercise it a bit to see if it is stable. Indicate here if any
single XaaNo option, or group of options results in a stable display
Once you've done this experimentation, please attach the log file
and config file from any noteable configurations which worked and
any others that you think might aide in finding a solution. Also,
attach at least one copy of /var/log/messages, and the output of
"lsmod" from your running system under X, as both contain valuable
information useful for troubleshooting. All files attached should
be individual uncompressed files, one per attachment, browser
viewable, like the above log attachment you've provided.
Once you've provided the results of your troubleshooting, I can
investigate a possible resolution.
Using "noaccel" option in the drivers section made no difference.
I think you misunderstood my problem. There is nothing unstable about
the XServer at all once it starts. It is rock solid and much faster
than the RedHat 6.2 version by a bunch. My problem is a spli second
after I type startx, I get a blank screen for over 4 minutes in which
the keyboard is completely locked out. After the 4 minutes have
elapsed, the XServer starts normally and everything works great.
I do have some more information now though. I got a slick idea to
telnet into my machine remotely while it is hung up to see if I could
dump the XFree log file and now know exactly at which line in the log
file in which it is hung up at. When I did this I found the lines that
were written in the log were these:
XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42)
Release Date: 15 August 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.21-2.ELsmp i686 [ELF]
Build Date: 24 October 2003
Build Host: porky.devel.redhat.com
Before reporting any problems, please make sure you are using the most
recent XFree86 packages available from Red Hat by checking for updates
at http://rhn.redhat.com/errata or by using the Red Hat Network up2date
tool. If you still encounter problems, please file bug reports in the
XFree86.org bugzilla at http://bugs.xfree86.org and/or Red Hat
bugzilla at http://bugzilla.redhat.com
Module Loader present
OS Kernel: Linux version 2.4.22-1.2149.nptl
(firstname.lastname@example.org) (gcc version 3.2.3 20030422 (Red Hat
Linux 3.2.3-6)) #1 Wed Jan 7 13:08:26 EST 2004
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/XFree86.0.log", Time: Fri Jan 16 17:21:47 2004
(==) Using config file: "/etc/X11/XF86Config"
(==) ServerLayout "Default Layout"
(**) |-->Screen "Screen0" (0)
(**) | |-->Monitor "Monitor0"
(**) | |-->Device "Videocard0"
(**) |-->Input Device "Mouse0"
(**) |-->Input Device "Keyboard0"
(**) Option "XkbRules" "xfree86"
(**) XKB: rules: "xfree86"
(**) Option "XkbModel" "pc105"
(**) XKB: model: "pc105"
(**) Option "XkbLayout" "us"
(**) XKB: layout: "us"
(==) Keyboard: CustomKeycode disabled
(**) |-->Input Device "DevInputMice"
(**) FontPath set to "unix/:7100"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7
(WW) Open APM failed (/dev/apm_bios) (No such device)
(II) Module ABI versions:
XFree86 ANSI C Emulation: 0.2
XFree86 Video Driver: 0.6
XFree86 XInput driver : 0.4
XFree86 Server Extension : 0.2
XFree86 Font Renderer : 0.4
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
compiled for 4.3.0, module version = 1.0.0
Module class: XFree86 Font Renderer
ABI class: XFree86 Font Renderer, version 0.4
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
compiled for 4.3.0, module version = 1.0.0
ABI class: XFree86 Video Driver, version 0.6
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:02:0: chip 8086,0482 card 0000,0000 rev 05 class 00,00,00
(II) PCI: 00:03:0: chip 1095,0646 card 0000,0000 rev 01 class 01,01,8a
(II) PCI: 00:06:0: chip 8086,0962 card 0000,0000 rev 01 class 06,04,00
(II) PCI: 00:06:1: chip 8086,1960 card 101e,0490 rev 01 class 01,04,00
(II) PCI: 00:07:0: chip 105d,2339 card 105d,0004 rev 02 class 03,00,00
(II) PCI: 00:14:0: chip 8086,84c5 card 0000,0000 rev 04 class 05,00,00
(II) PCI: 00:19:0: chip 8086,84c4 card 0000,0000 rev 04 class 06,00,00
(II) PCI: 00:1a:0: chip 8086,84c4 card 0000,0000 rev 04 class 06,00,00
(II) PCI: 02:08:0: chip 1011,0024 card 0000,0000 rev 03 class 06,04,00
(II) PCI: 03:04:0: chip 8086,1229 card 8086,10f0 rev 05 class 02,00,00
(II) PCI: 03:05:0: chip 8086,1229 card 8086,10f0 rev 05 class 02,00,00
After 4 mins I then got these lines: (I only pasting a few, rest of
file is same as before)
(II) PCI: End of PCI scan
(II) PCI-to-PCI bridge:
(II) Bus 1: bridge is at (0:6:0), (0,1,1), BCTRL: 0x0003 (VGA_EN is
(II) Bus 1 I/O range:
 -1 0 0x0000b000 - 0x0000bfff (0x1000) IX[B]
(II) Bus 1 non-prefetchable memory range:
 -1 0 0xfc000000 - 0xfc0fffff (0x100000) MX[B]
(II) Bus 1 prefetchable memory range:
 -1 0 0xff700000 - 0xff7fffff (0x100000) MX[B]
(II) Host-to-PCI bridge:
(II) Bus 0: bridge is at (0:25:0), (0,0,3), BCTRL: 0x0008 (VGA_EN is set)
(II) Bus 0 I/O range:
 -1 0 0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 0 non-prefetchable memory range:
 -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
 -1 0 0x00000000 - 0xffffffff (0x0) MX[B]
It seems to me, the XServer is getting hung up scanning my PCI bus.
What do you think? I'll upload my messages and lsmod files too.
Created attachment 97066 [details]
messages log file
Created attachment 97067 [details]
It seems that way. Hard to conclude anything though without more
information. Can you attach your X server log file as a bugzilla
It is very likely that fixing this problem will require manual
debugging of the X server directly on the problem hardware. Are you
skilled at all in debugging with gdb? If so, do you have 2 computers
connected on a LAN?
FWIW, I've experienced this problem with more modern hardware, on
various Linux distributions. Typically it happens when there is some
sort of DNS misconfiguration and the machine is not able to look up
the name that corresponds to its own IP address...
I forgot I still had this bug open in the database. I can use gdb,
not very skilled at it though. I can no longer experiment with the
machine however since in the last few months, Fedora 2 came out, I
tried it, and it fixed both the SMP crash problem and my slow video
start. X now starts up very fast, as it did before. So I'd say you
don't need to spend any more time to fix this, as anyone with this
problem could probably use the X-server in Fedora 2 and get rid of
Note to Barry, it was not a DNS problem, I know that for sure. The
X-Server was hanging during PCI bus scan in my case. This hang went
away with the new Fedora 2 kernel.
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:
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"
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.