Bug 167821 - Installler GUI fails with certain configurations and many disks
Installler GUI fails with certain configurations and many disks
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: anaconda (Show other bugs)
4.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-08 11:26 EDT by Dale Busacker
Modified: 2008-12-10 13:49 EST (History)
0 users

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


Attachments (Terms of Use)
/proc/partitions from failing config (1.35 KB, text/plain)
2005-09-08 11:46 EDT, Dale Busacker
no flags Details
output of lspci for failing config (7.61 KB, text/plain)
2005-09-08 11:47 EDT, Dale Busacker
no flags Details
lspci output from new failing config (7.61 KB, text/plain)
2006-02-09 16:27 EST, Noah Romer
no flags Details
/tmp/X.log from failing config (1.27 KB, text/plain)
2006-02-09 16:28 EST, Noah Romer
no flags Details
/tmp/ramfs/X.log from failing config (68.53 KB, text/plain)
2006-02-09 16:29 EST, Noah Romer
no flags Details

  None (edit)
Description Dale Busacker 2005-09-08 11:26:28 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)

Description of problem:
Large and complex configurations with many disks results in failure of mini-wm to connect to the X server.  Disconnecting some of the disks during install corrects the condition.

> Attempting to start native X server
> Waiting for X server to start...log located in /tmp/X.log
> 1...2...3...4...5.... X server started successfully.
> Xlib: connection to ":1.0" refused by server
> Xlib: Maximum number of clients reached
> 
> (mini-wm:673): Gtk-WARNING **: cannot open display: :1


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
See attached lspci.out and proc_partitions for configuration information.  This issue occurs on an Intel Harwich platform.  Once configured, simply start the installation to reproduce the failure

  

Actual Results:  mini-wm does not connect/start, X does

Expected Results:  GUI starts.

Additional info:
Comment 1 Dale Busacker 2005-09-08 11:46:14 EDT
Created attachment 118601 [details]
/proc/partitions from failing config
Comment 2 Dale Busacker 2005-09-08 11:47:04 EDT
Created attachment 118602 [details]
output of lspci for failing config
Comment 3 Jeremy Katz 2005-09-19 14:01:42 EDT
Can you hit ctrl-s when it fails and try to grab /tmp/X.log and /tmp/ramfs/X.log?

Number of disks really shouldn't influence X startup time... ;-)
Comment 4 Noah Romer 2006-02-09 16:27:02 EST
Created attachment 124455 [details]
lspci output from new failing config 

The original hw is no longer available to test with, but we recently came
across another config that causes this.
Comment 5 Noah Romer 2006-02-09 16:28:51 EST
Created attachment 124456 [details]
/tmp/X.log from failing config
Comment 6 Noah Romer 2006-02-09 16:29:56 EST
Created attachment 124457 [details]
/tmp/ramfs/X.log from failing config
Comment 7 Noah Romer 2006-02-09 16:37:34 EST
True. The number of disks really shouldn't effect X starting up. Weirdness abounds.

Don't know that the X.log files will tell you anything useful. The only diff
between them for a failing config and non-failing config is the timestamp line, i.e.

--- run1/tmp/ramfs/X.log        2006-02-09 10:46:18.000000000 -0800
+++ run4/tmp/ramfs/X.log        2006-02-09 11:57:20.000000000 -0800
@@ -14,7 +14,7 @@
 Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(++) Log file: "/tmp/ramfs/X.log", Time: Thu Feb  9 10:30:14 2006
+(++) Log file: "/tmp/ramfs/X.log", Time: Thu Feb  9 11:54:13 2006
 (++) Using config file: "/tmp/XConfig.test"
 (==) ServerLayout "Default Layout"
 (**) |-->Screen "Screen0" (0)
Comment 9 Red Hat Bugzilla 2007-06-11 22:55:05 EDT
requested by Jams Antill
Comment 11 Adam Jackson 2007-10-04 15:10:17 EDT
(In reply to comment #10)
> Is X doing some strange hardware probing here that causes it to take longer to
> start up than we wait for?

It... shouldn't be?  That's a fair number of PCI devices but far from the most
I've ever seen, and it's just one rv100 chip so I can't imagine hardware probe
is taking that long.

I say "not my bug".
Comment 12 Chris Lumens 2008-07-28 11:42:52 EDT
Just taking random stabs in the dark at this point - how much memory is in the
machine in question, and when X is working on starting up, can you switch to
tty2 and see how much memory is free?
Comment 13 Andy Lindeberg 2008-12-10 13:49:14 EST
If anybody can supply the requested information, please feel free to reopen this bug.

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