Red Hat Bugzilla – Bug 167821
Installler GUI fails with certain configurations and many disks
Last modified: 2008-12-10 13:49:14 EST
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):
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.
Created attachment 118601 [details]
/proc/partitions from failing config
Created attachment 118602 [details]
output of lspci for failing config
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... ;-)
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.
Created attachment 124456 [details]
/tmp/X.log from failing config
Created attachment 124457 [details]
/tmp/ramfs/X.log from failing config
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)
requested by Jams Antill
(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".
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?
If anybody can supply the requested information, please feel free to reopen this bug.