Bug 212432 - XOrg doesn't auto-configure when using XFX nVidia 6600GT card and Samsung Syncmaster 913N
XOrg doesn't auto-configure when using XFX nVidia 6600GT card and Samsung Syn...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nv (Show other bugs)
8
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Adam Jackson
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-26 15:02 EDT by quintesse
Modified: 2009-01-09 01:59 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 01:59:23 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)
Configuration generated by Xorg -configure (2.28 KB, text/plain)
2006-10-31 07:30 EST, quintesse
no flags Details
Xorg log file using default configuration (46.79 KB, text/plain)
2006-10-31 07:31 EST, quintesse
no flags Details
Xorg log file after changing configuration to use vesa driver (47.67 KB, application/octet-stream)
2006-10-31 07:33 EST, quintesse
no flags Details
Output of dmesg for default configuration (18.99 KB, text/plain)
2006-10-31 08:39 EST, quintesse
no flags Details
The X configuration used/generated by the Fedora 8 installer (742 bytes, text/plain)
2007-12-12 18:30 EST, quintesse
no flags Details
The X log generated by the Fedora 8 installer (47.06 KB, text/plain)
2007-12-12 18:31 EST, quintesse
no flags Details
Anaconda lof generated by the Fedora 8 installer (13.89 KB, text/plain)
2007-12-12 18:32 EST, quintesse
no flags Details

  None (edit)
Description quintesse 2006-10-26 15:02:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.4 (like Gecko)

Description of problem:
I was always unable to install FC4 and FC5 in graphical mode using my Samsung 
Syncmaster 913N and now with FC6 I still have the same problem.

It somehow seems to use an unsafe resolution/refresh combination because the
monitor just shows colored lines and a warning that the image being displayed 
is using a suboptimal resolution. But telling the installer to use specific
resolutions (I tried 640x480, 800x600, 1024x768 and 1280x1024) makes no 
difference.

If I finally install using text mode I can get X to work using either
the vesa or the closed-source nvidia driver. The nv driver installed by 
default by the installation just doesn't seem to use the correct settings for 
the monitor.

I must say that I don't remember correctly anymore, but I think I had to turn
off DDC and modelines manually for the nv driver to work. Using the option 
nodcc during the install has no effect though.

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


How reproducible:
Always


Steps to Reproduce:
1. Boot from CD and just hit ENTER
2. Wait for display to turn blank with a warning about suboptimal resolution
3.

Actual Results:
Screen stays blank

Expected Results:
Graphical installer interface should show

Additional info:
Comment 1 quintesse 2006-10-27 12:01:08 EDT
BTW: starting the install with "linux vesa" works. (Tip: maybe this option
should be mentioned in the installer options help screens?)

Looking at it some more it seems it has something to do with the XOrg
-configuration option / auto-detection that doesn't work for my monitor or card
(nVidia 6600GT).

If I start the installer with "linux vesa" the XConfig.conf file generated by
anaconda uses the vesa driver and everything works okay and I can at least install.

On first reboot though X refuses to start. Running XOrg -configure from runlevel
3 results in a XOrg.conf that uses "nv" and the monitor will complain about a
wrong resolution.

If I change the driver in the config to "vesa" or if I use the exact same config
that anaconda used the screen blanks and the monitor light starts blinking
indicatingthere is no signal. The system is notdead but I have not found a way
to get the screen back, killing X does nothing nor can I switch to any VT.

In the end it seems this is an XOrg problem. The strabge thing is that the
version used by anaconda at least works for vesa while the one installed does
nothing at all.

I'll try to test some more. I don't have another monitor but I will try to see
what happens with another Gfx card.
Comment 2 quintesse 2006-10-30 11:13:00 EST
Changing component from "anaconda" to "xorg-x11" because this problem is not
related to the installer but to the version of X used by it, the graphical boot
and the final X session, in fact I'm not able to get X working at all.

I imagine that "vesa" still worked for the installer because the version of X it
uses is different form the final system, but I have no idea if that is a
possibility.

X with this video card worked without problems with the vesa and nvidia's
drivers in FC5 or the nv driver after telling it "NoDDC" and "IgnoreEDID". None
of that works in FC6.

NB: Putting another vido card (an ATI Radeon X300) in the systm works without
any problems.
Comment 3 quintesse 2006-10-30 11:16:04 EST
The following bug seems to describe a very similar problem:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212437
Comment 4 quintesse 2006-10-31 07:30:18 EST
Created attachment 139843 [details]
Configuration generated by Xorg -configure
Comment 5 quintesse 2006-10-31 07:31:59 EST
Created attachment 139844 [details]
Xorg log file using default configuration
Comment 6 quintesse 2006-10-31 07:33:49 EST
Created attachment 139845 [details]
Xorg log file after changing configuration to use vesa driver

Only things changed in default configuration is the driver name fro "nv" to
"vesa" and commenting out of modules "dri" and "glx".
Comment 7 quintesse 2006-10-31 07:43:08 EST
Sorry for the flood of changes and for bumping this to "high" (although I don't
know if I should "high" for something that will affect only a small precentage
of people I guess) but I thought this was like before only an installer problem,
but I'm actually unable to get X working in FC6 right now (with this particular
Gfx card that is).
Comment 8 quintesse 2006-10-31 08:39:19 EST
Created attachment 139852 [details]
Output of dmesg for default configuration
Comment 9 Matěj Cepl 2006-11-01 08:48:15 EST
It may be worthy to note that this computer is using -xen kernel.
Comment 10 quintesse 2006-11-01 10:19:49 EST
Ok, turned down the priority to normal again because I've found out a way to get
things to work.

The problem seems to be that the card has 2 DVI ports. They are not marked with
any number so there is no way to see if there is a "primary" or something like that.

But looking at the Xorg log I saw this:

(II) NV(0): Probing for analog device on output A...
(--) NV(0):   ...can't find one
(II) NV(0): Probing for analog device on output B...
(--) NV(0):   ...found one
(II) NV(0): Probing for EDID on I2C bus A...
(II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) NV(0): I2C device "DDC:ddc2" removed.
(--) NV(0): DDC detected a CRT:
(II) NV(0): Manufacturer: SAM  Model: 11f  Serial#: 1296707897

etc.

So the monitor wasn't conencted to the first output but the second. It seems
that for the grub graphical display and for the text-only part of the boot this
doesn't matter because the right output is automatically selected, but it seems
that the Xorg auto discovery doesn't really like this.

I switched the monitor to the other output and the same part of the log now
shows this:

(II) NV(0): Probing for analog device on output A...
(--) NV(0):   ...found one
(II) NV(0): Probing for analog device on output B...
(--) NV(0):   ...found one
(II) NV(0): Probing for EDID on I2C bus A...
(II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) NV(0): I2C device "DDC:ddc2" removed.
(II) NV(0):   ... none found
(II) NV(0): Probing for EDID on I2C bus B...
(II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) NV(0): I2C device "DDC:ddc2" removed.
(--) NV(0): DDC detected a CRT:
(II) NV(0): Manufacturer: SAM  Model: 11f  Serial#: 1296707897

It somehow thinks there are 2 monitors attached?

I have no idea but at least now I get a normal picture (instead of my monitor
complaining that it can't handle the signal).

So, there still is something wrong with the XOrg auto discovery because I think
this should work but there is no rush anymore.
Comment 11 quintesse 2007-06-02 14:54:12 EDT
The original problem (as per the description of this bug report) still exists in
Fedora 7. Haven't yet finished the installation so don't know if any of the
other problems still persist. Will let you know as soon as I have more information.
Comment 12 Matěj Cepl 2007-07-12 12:13:27 EDT
Reporter, still talking about kernel-xen? fullvirt or paravirt?
Comment 13 quintesse 2007-07-13 23:41:47 EDT
No, we're talking about the installation here so the kernel is whatever the
installation uses.

A big improvement is that if I install with "linux vesa" it now also selects
vesa for the installed XOrg. So the problem I mentioned in comment #1 is solved
at least.
Comment 14 Adam Jackson 2007-07-31 13:27:43 EDT
(In reply to comment #11)
> The original problem (as per the description of this bug report) still exists in
> Fedora 7. Haven't yet finished the installation so don't know if any of the
> other problems still persist. Will let you know as soon as I have more
information.

Do you have an X log from the failed startup from F7 yet?
Comment 15 quintesse 2007-07-31 18:27:29 EDT
See #13, it's not the startup but the installation procedure that fails. If
there is a way to get that log while performing the installation let me know and
I'll get it for you.
Comment 16 Matěj Cepl 2007-12-10 04:22:19 EST
Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, or
Rawhide)? If this issue turns out to still be reproducible, please let us know
in this bug report. If after a month's time we have not heard back from you, we
will have to close this bug as CANTFIX.

Setting status to NEEDINFO, and awaiting information from the reporter.

[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]
Comment 17 quintesse 2007-12-10 16:07:16 EST
The same problem still exists for Fedora 8. The original bug description is
still valid: insert DVD, select graphical install and the moment the installer
switches to graphical mode the monitor shows colored lines and complains that
the signal is out of range. Installing with "linux vesa" does work.
Comment 18 Matěj Cepl 2007-12-11 06:27:19 EST
Could we get updated information for this bug, please?

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 19 quintesse 2007-12-12 18:30:08 EST
Created attachment 286321 [details]
The X configuration used/generated by the Fedora 8 installer
Comment 20 quintesse 2007-12-12 18:31:09 EST
Created attachment 286331 [details]
The X log generated by the Fedora 8 installer
Comment 21 quintesse 2007-12-12 18:32:07 EST
Created attachment 286341 [details]
Anaconda lof generated by the Fedora 8 installer
Comment 22 Bug Zapper 2008-11-26 02:03:02 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  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 '8'.

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 8'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 8 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 23 Bug Zapper 2009-01-09 01:59:23 EST
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 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.

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