Bug 443228

Summary: Graphical install fails due to bad refresh rates
Product: [Fedora] Fedora Reporter: Albert-Jan Yzelman <ajy777>
Component: xorg-x11-drv-atiAssignee: Dave Airlie <airlied>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: mcepl, vossman77, xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-18 06:06:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 235705    
Attachments:
Description Flags
x configuration file after text-mode install
none
The /tmp/X.log file created by the Anaconda installer
none
The XConfig file generated by X during graphical install
none
The Anaconda log none

Description Albert-Jan Yzelman 2008-04-19 13:39:22 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; nl; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

Description of problem:
With the latest Fedora 9 Preview, x86_64 DVD version;

choosing graphical install results in a blank screen when entering X mode.



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

How reproducible:
Always


Steps to Reproduce:
1. Boot from CD
2. Select and start graphical installation
3. Press next until anaconda starts booting X

Actual Results:
A blank screen, while presumably anaconda is not aware of any ill and patiently waits for user input.

Expected Results:
The anaconda GUI should have shown.

Additional info:

text-mode install works, but then a blank screen is encountered when booting in fedora 9. Changing to tty (ctrl_alt_f1-8) works, but does not show a login screen, probably due to the first-boot config fedora wants to perform. Hence no chance of manually getting to the x conf file.

Booting from DVD in rescue mode simply hangs.

Had no problems in Fedora 8 with the exact same setup.

Probable cause:
somehow X is defaulting to a refresh rate higher than 60Hz, which my monitor apperently (and surprisingly) cannot handle.

Possible implications:
there may be a whole lot more people with monitors out there which fail on too high refresh rates.


Relevant system info:
Ati Radeon X1900XTX and X1900CF video cards (primary videocard recognised by anaconda as X1900XT)
Samsung SyncMaster 2232BW monitor hooked up with an crossfire cable, with a DVI to DSUB converter (analog mode)
Crossfire XPress 3200 (RD580) northbridge chipset

Comment 1 Matěj Cepl 2008-04-21 16:39:55 UTC
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 2 Albert-Jan Yzelman 2008-04-21 16:59:53 UTC
Thanks for the reply. I'll be back home in a couple of hours, and will try to
boot from some live CD and get the config files; I would have attached them
sooner, but I cannot get into a live shell due to this bug (SSH also fails,
ethernet connection probably is not started).

Also, when I press 'I' for interactive startup after the 'loading nash' thing,
it still starts X without asking me. I consider this a flaw as well; should I
report this separately or is there a good reason for doing this?

Comment 3 Albert-Jan Yzelman 2008-04-21 19:47:25 UTC
Created attachment 303193 [details]
x configuration file after text-mode install

Comment 4 Albert-Jan Yzelman 2008-04-21 19:53:12 UTC
xorg.conf has been submitted. There is no Xorg.*.log in /var/log to be found;
not after booting immediately after text-mode install, nor after deleting
xorg.conf and rebooting.
If X always creates a log file (even if it does not crash), this would mean X is
never started and the system sort of hangs before that (although ctrl+alt+f1-8
switching is still possible, albeit does not show a login prompt, and
ctrl+alt+del reboots nicely). If this is the case, please advice on how to
proceed tracking down the real bug.

Comment 5 Matěj Cepl 2008-04-22 15:05:07 UTC
Sorry, this is an installation issue, so then some logs would be available in
/tmp/X* -- when running installation program and it crashes, switch to console
(Alt+Ctrl+F2) and then copy content of /tmp somewhere (USB drive, Internet,
other computer). X* is the file we are after.

Comment 6 Albert-Jan Yzelman 2008-04-22 19:59:16 UTC
Created attachment 303366 [details]
The /tmp/X.log file created by the Anaconda installer

Note that Anaconda does *not* crash; the screen is just blank (presumably due
to a default too high refresh rate)

Comment 7 Albert-Jan Yzelman 2008-04-22 20:00:05 UTC
Created attachment 303367 [details]
The XConfig file generated by X during graphical install

Comment 8 Albert-Jan Yzelman 2008-04-22 20:01:23 UTC
Created attachment 303368 [details]
The Anaconda log

Note here that the log displays anaconda is at the welcome screen, presumably
just waiting, and not crashed in any way.

Comment 9 Albert-Jan Yzelman 2008-04-22 20:04:24 UTC
New info posted. Let me know if more is required.

Comment 10 Jeremy Katz 2008-05-02 16:56:52 UTC
Does booting with 'xdriver=vesa' work around the problem?

Comment 11 Albert-Jan Yzelman 2008-05-02 18:41:10 UTC
Yes, it does!

Comment 12 Jeremy Katz 2008-05-02 20:31:28 UTC
Given the presence of a workaround (... and that we have drivers that require
this every release :/), dropping to F9Target

Comment 13 Bug Zapper 2008-05-14 09:43:49 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 14 Albert-Jan Yzelman 2008-12-02 21:53:42 UTC
A minor update: I have found that this issue persists in Fedora 10.

Comment 15 Albert-Jan Yzelman 2009-02-08 13:54:43 UTC
Persists in Fedora 11 Alpha (also on i686).

Comment 16 Bug Zapper 2009-11-18 10:11:37 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 17 Bug Zapper 2009-12-18 06:06:58 UTC
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.