Description of problem: PCI 10de:0184 is not recognized as a video card that supports graphical install. Version-Release number of selected component (if applicable): anaconda-11.0.5-1 How reproducible: always Steps to Reproduce: 1. boot FC5-ppc-DVD.iso on Apple PowerMac G4 "mirrored drive doors" model M8570. 2. skip mediatest 3. watch start of X11 server fail. Actual results: X11 server "starts" but aborts immediately because connection to display fails. Expected results: Graphical install begins. Additional info: Device is nVidia Corporation GeForce4 MX VGA-compatible graphics card, 64MB video RAM; original equipment on Apple PowerMac G4 model M8570 ("mirrored drive doors"), circa 2001.
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.