Red Hat Bugzilla – Bug 182217
Fedora install does not detect Nvidia 7600GT card to use nv driver
Last modified: 2014-06-18 05:08:08 EDT
Description of problem:
When trying to install Fedora Core 5 Test 3 the installer uses the VESA driver
instead of the nvidia driver for the E-VGA 7600GT PCI-Express card with device
id 0092. During install Fedora showed that an nvidia unknown device 0092. What
complicates this is that the VESA driver in FC5t3 does not work(corrupt screen)
so installation does not work even with the VESA driver. The VESA and the nv
driver worked with this video card on FC4.
Version-Release number of selected component (if applicable):
Whatever the installer uses for Fedora Core 5 Test 3
Install using an E-VGA 7600GT PCI-Express card
Steps to Reproduce:
1. Install E-VGA 7600GT PCI-Express Video card
2. Try to install fedora
Use the and configure the nv driver for the 7600GT during installation. I am
sure that the nv driver works on the card because I manually setup X on the
previous FC4 to use the nv driver and it worked just fine.
Information from /etc/sysconfig/hwconf...
desc: "nVidia Corporation: Unknown device 0092"
Forgot processor specs:
and installing using FC5t3 x86_64 DVD
This card is already listed in nv.xinf in FC5test3, so on a fresh OS install,
or when running "system-config-display --reconfig", the "nv" driver will
automatically get used for this hardware:
alias pcivideo:v000010DEd00000092sv*sd*bc*sc*i* nv
If this does not happen, it is a bug in kudzu or something else.
I think the nv driver is what is actually causing the corrupted display. After
an upgrade from FC4 to FC5t3 using the vnc method, The vesa driver is what was
configured. The vesa driver worked. I manually changed it to use the nv driver
and it showed the screen corruption like during the anaconda install.
Interstingly I tried running system-config-display --reconfig and it gave a
traceback. I then did a verify on the system-config-display rpm and it was
missing some files mysteriously. I removed the RPM and installed it from
scratch but I still get the traceback. I want to see if the nv driver is
configured automatically by running that but I can't seem to find what RPM is
supposed to provide the rhpxl.monitor python module.
I image that when I do figure out how to get past the traceback and it
configures the nv driver, the screen might be garbled like when I manually
configure X to use the nv driver.
Would the traceback on system-config-display explain why the vesa driver was
configured after the upgrade(maybe a fallback driver)?
[root@localhost static]# system-config-display --reconfig
Traceback (most recent call last):
File "/usr/share/system-config-display/xconf.py", line 32, in ?
ImportError: No module named rhpxl.monitor
[root@localhost static]# rpm --verify system-config-display-1.0.36-1
*** I fixed the missing problem by reinstalling system-config-display.
I found the rhpxl rpm package(duh). After installing that the display was
configured for the nv driver and it worked! So it looks like FC5 should force
the rhpxl package when upgrading.
The monitor frequencies were way off though because my SyncMaster 770TFT was not
listed(even though it was for FC4 or FC3 I think. I set them to what my monitor
manual specified and now I can even use higher resolutions. I have a feeling
this whole thing is because of monitor refresh rates being way off or something
with the anaconda installer. FYI, the nvidia installer auto-detected the
correct refresh rates using DCC when I installed it on FC4. It would be nice if
the system-config-display had an option to autodetect the monitor refresh using DCC.
(In reply to comment #4)
> I found the rhpxl rpm package(duh). After installing that the display was
> configured for the nv driver and it worked! So it looks like FC5 should force
> the rhpxl package when upgrading.
The package used to be rhpl, and changed to rhpxl at some point. Perhaps
the packages that depended on rhpl for that didn't get updated to depend on
rhpxl. Either way, 'tis a kudzu and/or system-config-display and/or
pyxf86config and/or something else bug it would seem.
I've CC'd some other developers who maintain or have contributed to the
various X config tool bits. This is something that should probably be
fixed for FC5 as a Blocker likely.
> The monitor frequencies were way off though because my SyncMaster 770TFT was not
> listed(even though it was for FC4 or FC3 I think. I set them to what my monitor
> manual specified and now I can even use higher resolutions. I have a feeling
> this whole thing is because of monitor refresh rates being way off or something
> with the anaconda installer.
That's not related to the bug initially reported here however. If you are
experiencing any other issues, please file individual bug reports for each
issue against the correct component. If you're not sure, make a best
guess to which component might be at fault and we can reassign if necessary.
> FYI, the nvidia installer auto-detected the correct refresh rates using DCC
> when I installed it on FC4.
Unfortunately that's not too useful info however, as Nvidia's proprietary
source code is not available.
> It would be nice if the system-config-display had an option to autodetect
> the monitor refresh using DCC.
ddcprobe is used for monitor autodetection during install or X configuration.
If a display is not probeable with ddcprobe for any reason, then the config
tool/installer will be unable to detect the display at all and it will have
to be manually specified.
At runtime however, the X server and drivers use native DDC probing if
the monitor details are not specified in the config file already. DDC
support varies from driver to driver, and chip to chip, as well as other
As long as DDC is being used in any form, the display will return it's
Horizontal and Vertical frequency ranges to the tool doing the probing
(be it ddcprobe or the X server/driver, etc.) and assuming nothing blocks
or interferes with the signal (such as a KVM, a buggy driver, a buggy
monitor, etc.), the mode list is then pruned to remove modes that are
outside of display's advertised ranges. Then, generally speaking, for
the configured resolution, the best mode with the highest refresh rate
is used which is compatible with the display's H/V frequency range.
If that isn't happening, then either DDC is not being used, or there is
a bug in the tool (ddcprobe for example) or the driver (ie: nv). If it
can be narrowed down to being the video driver, then a bug should be filed
in X.Org bugzilla so that Nvidia fixes it in a future "nv" driver update.
Hope this helps.
>> I found the rhpxl rpm package(duh). After installing that the display was
>> configured for the nv driver and it worked! So it looks like FC5 should force
>> the rhpxl package when upgrading.
>The package used to be rhpl, and changed to rhpxl at some point. Perhaps
>the packages that depended on rhpl for that didn't get updated to depend on
>rhpxl. Either way, 'tis a kudzu and/or system-config-display and/or
>pyxf86config and/or something else bug it would seem.
It didn't so much change as broke apart into two smaller packages, since rhpl
has become a bit of a dumping ground for random python blobs. Regardless, this
part is definately a system-config-display bug in that its requires have not
Chris went ahead and made the change here
For the record this was a 7800GT not a 7600GT.
device ID 0092 is the important part