Created attachment 262771 [details]
xorg.conf file used

Created attachment 262781 [details]
xorg.log from machine with no X display

This is the xorg.log from the machine when typing "init 5", waiting a minute or
two and then typing "init 3".

The screen goes blank, and the monitor flashes "no signal".

Smolt profile:
http://smolt.fedoraproject.org/show?UUID=d45b75f0-8eff-4cd4-a761-74917ce75420

I have also tried the xorg-x11-drv-openchrome-0.2.900-7.fc8 driver,
unfortunately also to no avail.

xorg.log file will be attached.

I have not tried the option below yet...

Option "EnableAGPDMA" "false"

Created attachment 268611 [details]
xorg.log when using openchrome xorg log file

Created attachment 268631 [details]
xorg log file when adding Option "EnableAGPDMA" "false" to the xorg.conf file

Looks like your monitor isn't giving out usefull DDC information and doesn't
like the generic fallback Modes we choose.  Can you please post your xorg.conf
and CRT type?  This should be a simple case of setting up a monitor entry in
your xorg.conf that generates better hsync and vrefesh ranges.

Monitor type is a 17" TFT... It's been in continuous linux use since about
Fedora 5 time and each release inbetween, with a variety of DVI and VGA
connections... Currently using DVI.

Will drag out the exact make/model when I can get someone to put eyeballs on it.

Xorg.conf shown below:

# Xorg configuration created by pyxf86config

Section "ServerLayout"
        Identifier     "Default Layout"
        Screen      0  "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "kbd"
        Option      "XkbModel" "pc105"
        Option      "XkbLayout" "gb"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "openchrome"
        Option "EnableAGPDMA" "false"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
        EndSubSection
EndSection

Ah okay now this is starting to make sense.  Does your motherboard have a DVI
daughterboard, or are you using a VGA to DVI cable or converter?

Neither, DVI connection on the rear of the motherboard, DVI cable to DVI input
on monitor.

Can't speak for any weirdness that might be onboard the motherboard, but it
doesn't appear to be VGA converter onboard... motherboard only has a DVI connection.

Add

option "VBEModes" "true" 

to your device section in xorg.conf.  Our DVI support is a little weak, but I
think that should get you up and running.

Created attachment 269111 [details]
vbemodes set to true

Still no luck so far, but at least a more defined error this time.

xorg.log attached

I have the same problem with Fedora8 on a Ebox 3854
(http://www.compactpc.com.tw/ebox-3854.htm)

The strange thing is that at firstboot, the X server works fine. (Also after
rebooting.)

Adding the VBEModes option didn't help. 

Monitor is a 19" IIyama VisionMaster Pro 454 (HM903DT).

okay well let's try some manual configuration.

1) comment out the VBEModes line.

2) Add your monitor's manual setup to xorg.conf

Section "Monitor"
        Identifier   "Monitor0"
        ModelName    "Iiyama HM903DT, VisionMaster Pro 454"
        HorizSync    30.0 - 132.0
        VertRefresh  45.0 - 200.0
        Option      "dpms"
EndSection

3)  Add this to your Section "Screen" 

Monitor    "Monitor0"

This should give you the full range of resolutions for your display.

If you are still getting a blank screen try manually adding resolutions to the
Screen section of your xorg.conf

Basically add something like this under 

Depth   24
Modes    "1280x1024"


Report back.

Created attachment 269901 [details]
Log files and xorg.confs.

OK, that got me started. What happened was that the screen would build up (not
too fast) over and over again, until i ended up with a blue screen. Apparently,
the computer had fallen back into runlevel 3, as i could type reboot and enter
to reboot. I could not restart a terminal with ctrl-alt-f2. The log shows some
interesting lines (to pick a few):
(II) VIA(0): Not using default mode "1024x768" (no clock available for mode)
(II) VIA(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan)
(II) VIA(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan)
(II) VIA(0): Not using default mode "576x432" (bad mode clock/interlace/doublescan)
(II) VIA(0): Not using default mode "1280x960" (insufficient memory for mode)
(II) VIA(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan)
(II) VIA(0): Not using default mode "1280x960" (insufficient memory for mode)

See files xorg.conf.20071127-01 and Xorg.0.log.20071127-01.

Second step was with the Modes lines included, with the same result.
See files xorg.conf.20071127-02 and Xorg.0.log.20071127-02.

Step 3, i tried the openchrome drivers mentioned by Dave.
The log file still has the same kind of errors, but at least the session could
be started now. (Yippee!)
See files *20071127-03.

In step 4, from within my Gnome session i changed back to the via driver by
using system-config-display, and I changed to a 1024x768 resolution. Now it
works more or less, albeit that the refresh rate seems a bit low (not sure, but
my eyes are not enjoying the view).
See files *20071127-04.

can you please repost your log files.  I am unable to extract the archive your
posted previously.

Created attachment 270471 [details]
xorg.conf.20071127-01 from the archive in comment 15

Created attachment 270481 [details]
xorg.conf.20071127-02 from the archive in comment 15

Created attachment 270491 [details]
xorg.conf.20071127-03 from the archive in comment 15

Created attachment 270501 [details]
xorg.conf.20071127-04 from the archive in comment 15

Created attachment 270511 [details]
Xorg.0.log.20071127-01 from the archive in comment 15

Created attachment 270521 [details]
Xorg.0.log.20071127-02 from the archive in comment 15

Created attachment 270531 [details]
Xorg.0.log.20071127-03 from the archive in comment 15

Created attachment 270541 [details]
Xorg.0.log.20071127-04 from the archive in comment 15

I managed to unpack the archive. You don't have to repost anything.

okay.  First off I really can't help you too much with the via driver that
ships.  That driver is a mess.  Please stick with the openchrome driver for
debugging purposes.

If you just switch back to the openchrome driver in xorg.conf the screen should
start fine at 1024x768 resolution.  After you have logged into your gnome
session use the screen resolution preferences to adjust the resolution and
refresh rate.

Mass migration: via -> openchrome.

please retry with xorg-x11-drv-openchrome. This is the successor to
xorg-x11-drv-via. As stated in comment #11, you will need to have :
 option "VBEModes"
in your conf.

If you check comment #12 you'll see that I've already tried the VBEModes setting.

Created attachment 271851 [details]
X log ( no more problems)

I switched back to the openchrome driver at 1024x768, and everything seems fine
now. Thanks a lot, and good luck to you Dave.

(I included the log file just in case.)

(In reply to comment #30)
> If you check comment #12 you'll see that I've already tried the VBEModes setting.

Sorry, I read thru the bug report too fast, I though it was still with the via
driver. I'm afraid you'll have to wait for upstream to have DVI support outside
of just the VBE trick.

(In reply to comment #31)
> Created an attachment (id=271851) [edit]
> X log ( no more problems)
> 
> I switched back to the openchrome driver at 1024x768, and everything seems fine
> now. Thanks a lot, and good luck to you Dave.
> 
> (I included the log file just in case.)

Thanks for testing.

No problem, thanks for the action.

There was a suggestion that using both the VBEModes trick and forcing a
resolution etc, that might work... I will be back and hands on with this at the
weekend so will be able to try that approach then.

Created attachment 274651 [details]
xorg.conf with mode fixed (no autodetect)

Still no display, once X is started the display goes black and never returns
until reboot, even changing to runlevel 3 does not bring the console back.

Rebooting is the only way to see the console again.

ssh etc continues to work.

Created attachment 274661 [details]
xorg log file with mode fixed

xorg log file with fixed mode

Minor update, following a reboot I can now return to runlevel 3 to recover the
console... still no X display but at least now my console access is still visible!

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

xorg-x11-drv-openchrome-0.2.902-7.fc9.i386

X still broken on this hardware....

OK, so I'm now coming back round and trying this again with F10, initial tests suggest it's all still b0rked.

Logs, config files, and workarounds to follow. Updated version in bug to F10.

Could you update to the latest version, retest and report back to see if this still remains an issue for you.

You can get the latest update from here.

http://koji.fedoraproject.org/koji/packageinfo?packageID=5229

Thank you.

I had problem with openchrome. It can not start X (always fails with error " not using default mode "1024x768" (unknown reason)"). I found problem in via_mode.c in function ViaPanelGetIndex. There is code like this:

for (i = 0; i < VIA_BIOS_NUM_PANEL; i++)
	        DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO, "ViaPanelGetIndex:"
	                         "Match Debug: %d == %d)\n", pBIOSInfo->Panel->NativeModeIndex,
	                         lcdTable[i].fpSize));
	        if (lcdTable[i].fpSize == pBIOSInfo->Panel->NativeModeIndex) {
	            int modeNum, tmp;

As you can see "for" is executed only for DEBUG statement (and not next "if" - there are missing { after for and befor DEBUG - and } at end. indent is ok, but code not). After removing row with DEBUG, driver started working.

for (.....)
     DEBUG();
     if (..) {
           ....
     }


Should be changed to

for (.....) {
     DEBUG();
     if (..) {
           ....
     }
}

(In reply to comment #41)
Thanks for the report, this is now fixed upstream, and a new package for F-10 is on its way to updates-testing.
However, I think this is different from the initial bug report. Even with this fixed, there still no DVI daughterboard support in the driver.

Updating bug for the new F11 release (preview plus all rawhide to date).

Still no display.

xorg-x11-drv-openchrome-0.2.903-10.fc11.i586

Will push updated logs and xorg.conf next.

Current xorg options:
VBEModes false
EnableAGPDMA false

Unsetting need info flag.

Created attachment 346821 [details]
xorg.conf used with F11

Created attachment 346823 [details]
xorg.conf used with F11 with openchrome settings

Created attachment 346824 [details]
xorg logfile generated when xorg.conf used in F11 with openchrome settings

Created attachment 346825 [details]
xorg logfile generated when no xorg.conf exists

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  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 '11'.

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 11'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 11 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

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days