Bug 186343

Created attachment 126600 [details]
Xorg.0.log

/var/log/Xorg.0.log from ubuntu-5.10-live-powerpc (2005-11-01) booted on this
hardware.

Created attachment 126601 [details]
xorg.conf

/etc/X11/xorg.conf from ubuntu-5.10-live-powerpc (2005-11-01) booted on this
hardware.

Run "system-config-display --reconfig" and start the X server with the newly
generated config file.  Then attach the config file and the X server log from
this test to the report as individual uncompressed file attachments.

Next, hand edit xorg.conf and assuming it is not already - change it to use the
"nv" driver, and restart the X server again.  Indicate if the server starts
ok or not, and attach the config and log from that session as well.

Thanks in advance.

system-config-display does not exist at this very early point during
installation from DVD.  Neither does the mouse, nor the network.  There is a
shell on C-A-F2; I looked in /bin, /sbin, /usr/bin, and /usr/sbin, but could not
find system-config-display .

The last few lines on the initial screen are:
-----
...1...2...3...4...X server started successfully.
_X11TransSocketINETConnect() can't get address for localhost:6001: Name or
service  not known

(mini-wm:511): Gtk-WARNING **: cannot open display: :1
-----

File /tmp/X.log ends with:
-----
(EE) VESA(0): V_BIOS address 0x26000 out of range
(EE) Screen(s) found, but none have a usable configuration

Fatal server error:
no screens found
-----

File /tmp/XConfig.test contains these lines (among others):
-----
Section "Device"
        Driver "vesa"
-----


Booting Ubuntu Live, copying system-config-display and libraries from a
successful Fedora Core 5 installation on a 32-bit PowerPC Mac Mini, then trying
to run system-config-display on the PowerMac G4 under Ubuntu, gives a
Segmentation fault.

Our bugzilla database had a catastrophic failure on June 13, 2006
which lost all bug changes from Thurs June 9th onward.  I have
bugzilla email records of the timeperiod however, and will be
restoring as many changes as I can manually.

(In reply to comment #0)
> > Description of problem:
> > PCI 10de:0184 is not recognized as a video card that supports graphical install.

Yep, the video driver source code does not list 10de:0184 as a valid
device currently.

  { 0x10DE0181, "GeForce4 MX 440 with AGP8X" },
  { 0x10DE0182, "GeForce4 MX 440SE with AGP8X" },
  { 0x10DE0183, "GeForce4 MX 420 with AGP8X" },
  { 0x10DE0185, "GeForce4 MX 4000" },
  { 0x10DE0186, "GeForce4 448 Go" },
  { 0x10DE0187, "GeForce4 488 Go" },
  { 0x10DE0188, "Quadro4 580 XGL" },

...

Most likely, this is just an oversight in the nv driver however that can
be easily fixed I'm guessing.  Before we do that I need you to test a
few things and let me know the results, and then we can release a driver
update soon that should fix it if all goes well.

If you haven't already gotten the OS to install by other means, please
do a text mode installation, or force anaconda to use the "vesa" driver
for install if possible.  Then, once the OS is installed, manually
configure X by doing:   system-config-display --reconfig

This should configure your X server to use vesa by default, but we want
to try "nv" out, so manually edit the xorg.conf and change the driver
from "vesa" to "nv".  After doing that, start up the X server and see if
it works.  Then attach the resulting X server log and config file to the
report along with your success/failure status.

The "nv" driver has some logic in it where in some cases it can attempt
to support some unknown chips based on similarities within a chip family.
If it detects your chip is in the same family as another supported chip,
then even though your chip isn't supported, it may report in the log
file:

                   NVChipsets[numUsed].token = pciid;
                   NVChipsets[numUsed].name = "Unknown NVIDIA chip";

So, if you try this and see in the log "Unknown NVIDIA chip", and it
appears to work, then we can probably add a new mapping for the 0184
to the driver, update our videoaliases file, and it should just
autodetect after that.

Thanks in advance.

Here's the official PCI ID registry:  http://pci-ids.ucw.cz/iii/?i=10de

This chip is not known there at all, so the reason it's probably not in
the driver is that it was probably a custom made board that was made for
Apple or whoever in low volume, and not widely known, so it's missed out
getting on the hardware lists, etc.  Fortunately it's probably easy to
fix that once your test results are back.  ;) 


...



Ok, I'm a real whiz kid today.  I didn't read all the comments in the
report before doing my investigation of the driver and responding above...
so I missed your ubuntu log the first time around.

It appears that ubuntu is already assigning all nvidia chips, known or not
to the nv driver in hopes that they might work.  Since you seem to indicate
that it works in ubuntu, I think we can safely assume that it will work
equally well (or unwell) in Fedora.

So, I have added 0184 to the nv.xinf, and it will be in future builds.

If you could comment on how well it works using nv though, that would
still be appreciated.  We'll probably need someone from Nvidia to supply
the correct technical chipset name for submission to sourceforge and
commit to the upstream Xorg driver.

TIA


...


I've filed a request to Nvidia:

https://bugs.freedesktop.org/show_bug.cgi?id=7171

------- Additional Comments From jreiser  2006-06-11 18:14 EST -------
All automatic attempts to reconfigure the display for use by X11 fail.  The only
way I could get X11 to run was by manually editing /etc/xorg.conf to use Driver
"nv".

Booting the original FC5-ppc-DVD.iso with "linux vesa" fails to start the X
server.  The session on virtual terminal #1 hangs.  Hunting around for messages,
I find "(EE) VESA(0): V_BIOS address 0x26000 is out of range" and "(EE)
Screen(s) found, but none have a usable configuration."

Booting with "linux text" allows install to succeed.  First reboot goes only to
runlevel 3.  Appling "telinit 5" fails to start the X server (using driver
vesa), with similar messages as in the boot with "linux vesa".  Accepting the
invitation to try reconfiguring the X server also fails again with similar
messages.  Running "system-config-display --reconfig" also fails, again with
similar mesasges.

I will attach copies of xorg.conf, Xorg.0.log, Xorg.0.log.old, Xorg.setup.log,
and output from "lspci; lspci -n; lspci -vv".

Manual edit of /etc/xorg.conf to specify Driver "nv" (instead of Driver "vesa")
succeeds.

[log file attachments, etc. were previously attached at this place in
 the bug, but were lost in the bugzilla database failure]

To be clear, this bug is about the PCI ID being unknown, as indicated in
the summary line.  The PCI ID has now been added to the nv.xinf file
in rawhide, and committed to CVS for future FC5 builds, so that part of
the problem is solved.  The video driver in FC5 and in rawhide however,
does not know this specific chip yet.  Officially it is unsupported,
however the "nv" driver contains fallback logic in which it attempts
to guess the chip family from the PCI ID, as Nvidia chooses PCI IDs
for their devices which follow a specific pattern that is detectable.

If the driver detects the chip family as a known family, but the specific
chip is unknown, as is the case with this chip (0x0184), it will attempt
to treat the chip as a known chip of the same family in hopes that it
will work.  In many cases this does work, and the user ends up with working
video even though their chip is not officially supported yet.  In other
cases, the chip may not work, or may have problems if the chip has
differences from other chips in the same family which require special
cases in the driver code.

In all cases, installing FC5 off CD/DVD on this hardware will not ever
get autodetected.  That is expected, because the nv.xinf file does not
map this device to the nv driver.  While I have added the device ID to
nv.xinf in CVS for FC5, and in rawhide for this chip, that wont be present
on the FC5 DVD image, so the fix will not be seen until FC6.

In short:  Any form of installation from stock FC5 media, this chip will
not ever be autodetected, because any possible fix that could be created
for this, will not be present on the already shipped DVD image.

The only way that this chip will ever be autodetected, is by upgrading
to the newer release which contains the nv.xinf mapping.  I have not
built any rpms for FC5 yet, however they are in rawhide.  The rawhide
driver however will require the rawhide X server, and a bunch of other
dependencies will get dragged in.

The simple way to test this fix yourself, is to find the "nv.xinf" file
on your installed system, make a backup copy of it, and then edit it
in a text editor.  Scroll down to the entry for the 0183 device, copy
the line, and edit the copy to say 184 then save and exit.

Now if you run "system-config-display --reconfig", the tools should
detect the 0184 chip and assign the "nv" driver for it.  Again however,
the "nv" driver may or may not work properly with this chip, and only
Nvidia can rectify that situation should it arise.

So at this point, there are one of 2 possible scenarios with the updated
nv.xinf installed on the system:

1) Running "system-config-display --reconfig" should now autodetect the
   card, and assign the "nv" driver to it in xorg.conf.  If it does not,
   then locate the nv.xinf file on the system, and confirm that it has the
   entry for device ID 0184 present in it.  If the entry is present for
   the chip, then there is a bug in kudzu or something else preventing
   the proper driver assignment, and we should reassign this bug to kudzu.

or

2) Running "system-config-display --reconfig" does now properly autodetect
   the card, and assign the "nv" driver to it in xorg.conf.  When the X
   server is started, the nv driver may or may not work at all on this
   hardware, as the chip is officially unsupported.  Only Nvidia can
   update the driver to provide the proper required support logic, and
   I've filed a bug upstream as indicated above to track this.  This is
   however a separate problem from our tool detecting the chip and
   assigning the driver.


Once the system is configured to use "nv" either via system-config-display
working, or manually, if the "nv" driver does not work for this chip
properly, you should file a bug report in X.Org bugzilla for Nvidia to
address in a future driver update.

Hope this helps.

------- Additional Comments From jreiser  2006-06-12 11:33 EST -------
Modifying nv.xinf (found somewhere below /usr/share) to have an additional line
for chip 0184 (otherwise the same as chip 0183) allowed "system-config-display
--reconfig" to work, and bringing up X11 via "telinit 5" then worked, too.

------- Additional Comments from John Reiser <jreiser>
All automatic attempts to reconfigure the display for use by X11 fail.	The
only
way I could get X11 to run was by manually editing /etc/xorg.conf to use Driver

"nv".

Booting the original FC5-ppc-DVD.iso with "linux vesa" fails to start the X
server.  The session on virtual terminal #1 hangs.  Hunting around for
messages,
I find "(EE) VESA(0): V_BIOS address 0x26000 is out of range" and "(EE)
Screen(s) found, but none have a usable configuration."

Booting with "linux text" allows install to succeed.  First reboot goes only to

runlevel 3.  Appling "telinit 5" fails to start the X server (using driver
vesa), with similar messages as in the boot with "linux vesa".	Accepting the
invitation to try reconfiguring the X server also fails again with similar
messages.  Running "system-config-display --reconfig" also fails, again with
similar mesasges.

I will attach copies of xorg.conf, Xorg.0.log, Xorg.0.log.old, Xorg.setup.log,
and output from "lspci; lspci -n; lspci -vv".

Manual edit of /etc/xorg.conf to specify Driver "nv" (instead of Driver "vesa")

succeeds.

(In reply to comment #11)
> ------- Additional Comments From jreiser  2006-06-12 11:33 EST
-------
> Modifying nv.xinf (found somewhere below /usr/share) to have an additional line
> for chip 0184 (otherwise the same as chip 0183) allowed "system-config-display
> --reconfig" to work, and bringing up X11 via "telinit 5" then worked, too.

I've confirmed that the current rawhide build of the nv driver contains
the 0x0184 device ID in nv.xinf.