Bug 113570 - XServer locks up machine for over 4 mins while starting
XServer locks up machine for over 4 mins while starting
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: XFree86 (Show other bugs)
1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-15 09:33 EST by Jerry DaSilva
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-12 13:05:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
My XFree86 startup log (30.06 KB, text/plain)
2004-01-15 09:46 EST, Jerry DaSilva
no flags Details
messages log file (19.20 KB, text/plain)
2004-01-16 18:07 EST, Jerry DaSilva
no flags Details
lsmod output (810 bytes, text/plain)
2004-01-16 18:07 EST, Jerry DaSilva
no flags Details

  None (edit)
Description Jerry DaSilva 2004-01-15 09:33:09 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; 
Q312461)

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):
XFree86-4.3.0-42

How reproducible:
Always

Steps to Reproduce:
1.login to the machine
2.run startx
3.
    

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.

Additional info:
Comment 1 Jerry DaSilva 2004-01-15 09:46:48 EST
Created attachment 97025 [details]
My XFree86 startup log
Comment 2 Mike A. Harris 2004-01-16 10:02:13 EST
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:

    Option "noaccel"

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
or not.

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.

TIA


please
Comment 3 Jerry DaSilva 2004-01-16 17:37:14 EST
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
(bhcompile@daffy.perf.redhat.com) (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
hdr 00
(II) PCI: 00:03:0: chip 1095,0646 card 0000,0000 rev 01 class 01,01,8a
hdr 00
(II) PCI: 00:06:0: chip 8086,0962 card 0000,0000 rev 01 class 06,04,00
hdr 81
(II) PCI: 00:06:1: chip 8086,1960 card 101e,0490 rev 01 class 01,04,00
hdr 80
(II) PCI: 00:07:0: chip 105d,2339 card 105d,0004 rev 02 class 03,00,00
hdr 00
(II) PCI: 00:14:0: chip 8086,84c5 card 0000,0000 rev 04 class 05,00,00
hdr 00
(II) PCI: 00:19:0: chip 8086,84c4 card 0000,0000 rev 04 class 06,00,00
hdr 00
(II) PCI: 00:1a:0: chip 8086,84c4 card 0000,0000 rev 04 class 06,00,00
hdr 00
(II) PCI: 02:08:0: chip 1011,0024 card 0000,0000 rev 03 class 06,04,00
hdr 01
(II) PCI: 03:04:0: chip 8086,1229 card 8086,10f0 rev 05 class 02,00,00
hdr 00
(II) PCI: 03:05:0: chip 8086,1229 card 8086,10f0 rev 05 class 02,00,00
hdr 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
cleared)
(II) Bus 1 I/O range:
	[0] -1	0	0x0000b000 - 0x0000bfff (0x1000) IX[B]
(II) Bus 1 non-prefetchable memory range:
	[0] -1	0	0xfc000000 - 0xfc0fffff (0x100000) MX[B]
(II) Bus 1 prefetchable memory range:
	[0] -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:
	[0] -1	0	0x00000000 - 0x0000ffff (0x10000) IX[B]
(II) Bus 0 non-prefetchable memory range:
	[0] -1	0	0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0 prefetchable memory range:
	[0] -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.

-Jerry
Comment 4 Jerry DaSilva 2004-01-16 18:07:06 EST
Created attachment 97066 [details]
messages log file
Comment 5 Jerry DaSilva 2004-01-16 18:07:44 EST
Created attachment 97067 [details]
lsmod output
Comment 6 Mike A. Harris 2004-02-17 03:37:35 EST
It seems that way.  Hard to conclude anything though without more
information.  Can you attach your X server log file as a bugzilla
attachment?

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?
Comment 7 Barry K. Nathan 2004-07-31 00:57:59 EDT
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...
Comment 8 Jerry DaSilva 2004-07-31 09:56:38 EDT
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 
the issue.

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.

Comment 9 Mike A. Harris 2004-10-12 13:05:36 EDT
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:

        http://fedora.redhat.com/download

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"
component.

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.

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