Bug 140441 - Mysterious side-effects cause dual-head to work properly
Mysterious side-effects cause dual-head to work properly
Product: Fedora
Classification: Fedora
Component: system-config-display (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Adam Jackson
Depends On:
Blocks: FC6Target
  Show dependency treegraph
Reported: 2004-11-22 16:48 EST by Andrew D. Stadler
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-31 10:52:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew D. Stadler 2004-11-22 16:48:57 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
System hangs when restarting into dual-head configuration.  Only a
specific sequence of actions seems to be capable of bringing up dual-head.

There are two specific issues I'd like to address here.  The first is
that the system is crashing on startup, and was reported as bug # 140435.

The 2nd is that a mysterious change (hidden side effects?) causes the
system to work again, and is the subject of this bug.

My system is a ThinkPad T30 running FC3, pretty much up-to-date.  It
has a radeon 7500 and the displays are the internal 1400x1050 and an
external VGA dell 2000fp (1600x1200).  This system worked properly in
single and dual-head configurations when I was running FC2.

Version-Release number of selected component (if applicable):
system-config-display-1.0.24-1 xorg-x11-6.8.1-12.FC3.1

How reproducible:

Steps to Reproduce:
1.  config system for dual-head, xinerama.
2.  reboot.  System hangs during RHGB.  Note - the on the first
reboot, it hangs quite late in the sequence ("starting redhat network").
3.  reboot.  System hangs during RHGB, but much earlier ("setting the
hostname").  Subsequent reboots always hang earlier, like this.
4.  Unplug the external display and reboot.  System comes up properly
(single page)
5.  Plug the external display back in.  Restart takes you back to (3).
 Logout-Login works, but NOTE external display is now mirroring
incorrectly (it shows a subset of the total 1400x1050 screen)
6.  Run system-config-display and make an inconsequential change (e.g.
 per bug 136283, s-c-d shows 1400x1050 as the 2nd monitor's
resolution.  I change it back to 1600x1200).  Click OK.
7.  Take a look at /etc/X11/ and note - (a) xorg.conf has a new mod
time (it's been touched) but "diff xorg.conf xorg.conf.backup"
indicates that no actual change was made.
8.  Logout - Login.  DUAL HEAD NOW WORKS.
9.  Restart.  We're back to (2) failing on restart.

10.  Repeat test but in step 6, simply "sudo touch
/etc/X11/xorg.conf".  This does not fix things, we still crash.

Actual Results:  Running s-c-d and making inconsequential changes to
xorg.conf seems to resolve the dual view issues.  This implies that
s-c-d is doing something other than simply touching xorg.conf.

Expected Results:  s-c-d would appear to be about rewriting xorg.conf,
but this test indicates that something else is going on.  Is there any
way to make this process more visible & transparent?

Additional info:
Comment 1 Paul Nasrat 2004-11-23 08:39:33 EST
Can you test with system-config-display from updates testing:

Comment 2 Andrew D. Stadler 2004-11-23 12:18:58 EST
Assuming that this is the same as system-config-display-1.0.24-1-noarch.rpm, then yes, 
all of these tests were already run with this newer system-config-display.

(I had already upgraded to it, per your recommendation in bug 140201.)
Comment 3 Paul Nasrat 2004-11-23 16:03:38 EST
Apologies - I misread.  What happens if you disable rhgb- set GRAPHICAL=no in
Comment 4 Andrew D. Stadler 2004-11-23 22:47:12 EST
I tried the following test:
1.  Removed the /etc/rhgb/xorg.conf (to go back to original, troubled
2.  Edited /etc/sysconfig/init and changed GRAPHICAL to =no

Result:  System booted using text mode only, and eventually switched
to graphic login screen, with both monitors operating properly.

So it seems that *either* workaround resolves the problem: 
single-head /etc/rhgb/xorg.conf file, or, GRAPHICAL=no in

Note, this test helps narrow down the issues in my other bug, #
140435, which was more about the crashing in rhgb.  Any ideas about
steps 6-7-8 in the original writeup, the core of this bug, about the
mysterious ability of s-c-d to fix the system without making any
obvious change to /etc/X11/xorg.conf ?
Comment 5 Paul Nasrat 2004-11-29 08:33:01 EST
I imagine that this is as we are respawning the X server, running
system-config-display probably involved you restarting it.

A simple test to eliminate system-config-display from the picture -
boot into original, troubled config.

Ctrl-Alt-Backspace to zap X

Does X restart correctly laid out?
Comment 6 Andrew D. Stadler 2005-02-27 20:00:15 EST
I wasn't sure at which point you wanted me to zap X, so I tried a few points.

At #2 (hung) nothing happened.
At #3 (hung) nothing happened
Ugh, #4 no longer works.  Now, even with the 2nd monitor unplugged, it is dying at 
"setting the hostname".   Apparently the original steps to reproduce are no longer 

I will need to work out a different set of steps before I can perform your test....

Comment 7 Adam Jackson 2006-03-03 10:37:04 EST
Mass update: move dual head bugs from FC5 to FC6, no way they can get fixed
before FC5 release at this point.
Comment 8 John Thacker 2006-10-31 10:52:57 EST
Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.
Comment 9 Andrew D. Stadler 2006-10-31 11:53:53 EST
Just a followup, I didn't abandon this bug.  I have not been able to follow up because after upgrading to 
FC5, dual-head became completely unuseable on my system.  (Somewhere between FC4 and FC5 the 
driver for the radeon 7500 became quite flaky in dual-head mode).

fedora #185944
fedora #190751
freedesktop #5781
freedesktop #7019

I will be more than happy to regress this bug... if I ever regain dual-head useability....

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