Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 2402 - annoying timeout when in xinit (server too fast?)
Summary: annoying timeout when in xinit (server too fast?)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 6.0
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL: http://noa.tm/xinit-strace.txt
Whiteboard:
: 2621 3448 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-04-28 20:50 UTC by redhat-bugzilla
Modified: 2008-05-01 15:37 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-06-17 14:53:40 UTC


Attachments (Terms of Use)

Description redhat-bugzilla 1999-04-28 20:50:35 UTC
When trying to start the X server in Hedwig with startx
i get a boring timeout before the windowmanager starts.
A strace of xinit (see url) shows that xinit sets an
alarm(15) and then pause()s. The relevant code in
xc/programs/xinit/xinit.c has the following comment:
----
/*
* kludge to avoid race with TCP, giving server time to
* set his socket options before we try to open it,
* either use the 15 second timeout, or await SIGUSR1.
*
* If your machine is substantially slower than 15 seconds,
* you can easily adjust this value.
*/
alarm (15);
pause ();
alarm (0);
----
It seems like the process gets the USR1 signal before it
starts to pause(). Is our Xserver too fast?

Comment 1 David Lawrence 1999-05-13 21:30:59 UTC
I have verified this to occur on occasion but not consistently. This
has been assigned to a developer for further review.

Comment 2 Chris Evans 1999-05-14 13:05:59 UTC
I logged an identical bug. You probably want to find it and mark it as
a duplicate.

Note that I _do_ see this consistently, if my X server and xinit and
WM etc. are all cached. I have a P2-350.

This is an annoying bug and probably warrants an update to fix.

Comment 3 Jeff Johnson 1999-06-03 15:32:59 UTC
*** Bug 2621 has been marked as a duplicate of this bug. ***

Hi

If I drop to runlevel 3 (no X running by default) then
startx is observed to be broken. Actually technically it is
"xinit" or the X server that is broken.

The broken behaviour is 15 seconds of waiting at a blank X
screen before my window manager is launched.

Closer inspection reveals that "xinit" is waiting for a
signal from the X server, which NEVER ARRIVES, hence a 15
second timeout

Can you reproduce?? If not tell me ASAP and I will be more
specific

------- Additional Comments From chris@ferret.lmh.ox.ac.uk  05/08/99 08:19 -------
Have some additional comments :-)

It appears to be a race condition. If I boot to runlevel 3 and type
"startx", my X session launches fine.

If I exit the X session, and type "startx" again, all the binaries are
cached and load very quickly. Because of this speed increase, the
race condition is observed - startx hangs for 15 seconds showing a
blank X screen.

Comment 4 Preston Brown 1999-06-08 16:47:59 UTC
I hopefully have coded up a fix for this, but we need to test it more
thoroughly before we roll it into the errata X release we are
planning.

Comment 5 Jeff Johnson 1999-06-14 14:19:59 UTC
*** Bug 3448 has been marked as a duplicate of this bug. ***

With RH 6.0 sometimes (maybe 1 time on 3) X takes 10 seconds
more to start (during these 10 seconds there's no disk
activity).
It happens with any window manager and I've seen it on 4
computers (they all use the SVGA server).
It's not a very severe bug, but's really annoying (usually X
takes only 3 or 4 seconds to start, why sometimes it has to
take 13 or 14?).
If you press ctrl+alt+backspace during the "slow" start and
then restart X, usually it start "fast".
It happens with any user on my system.

Comment 6 Bill Nottingham 1999-06-17 14:53:59 UTC
Fixed in errata XFree86-*-52 release.


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