Created attachment 347286 [details] X.org configuration, log, dmesg and lspci output Description of problem: Nouveau driver is unable to detect displays connected to iMac G4 machine (controller is integrated GeForce4 440 Go NV17 with 32 MB VRAM) and fails to start X.org. My machine has the built-in flat panel and an external LCD monitor connected to via a mini D-sub output. There are two "screen" devices in the OFW device tree, both outputs are detected and written to by the kernel offb framebuffer driver (nvidiafb is disabled) and both outputs work correctly in Mac OS X 10.4.11 (PPC). The nv driver works corrently on the LVDS (and if forced via FlatPanel and CrtcNumber options also on the D-sub output), but I was unable to achieve dual-head configuration. The nouveau driver works at least with the LVDS output if the RandR12 option is set to off. The most probable cause are problems with reading the contents of the ROM, as the following lines from the X.org log suggest: (II) NOUVEAU(0): Attempting to load BIOS image from PROM (!!) NOUVEAU(0): ... BIOS signature not found (II) NOUVEAU(0): Attempting to load BIOS image from PRAMIN (!!) NOUVEAU(0): ... BIOS checksum invalid (II) NOUVEAU(0): Attempting to load BIOS image from PCI ROM (!!) NOUVEAU(0): ... BIOS signature not found (II) NOUVEAU(0): Using BIOS image from PRAMIN (II) NOUVEAU(0): BMP BIOS found (II) NOUVEAU(0): BMP version 5.21 (II) NOUVEAU(0): Bios version 04.17.00.56 (WW) NOUVEAU(0): No output data (DCB) found in BIOS, assuming a CRT output exists (--) NOUVEAU(0): Parsing VBIOS init table 0 at offset 0x0149 (--) NOUVEAU(0): Parsing VBIOS init table 1 at offset 0x045F (--) NOUVEAU(0): Parsing VBIOS init table 2 at offset 0x0264 (--) NOUVEAU(0): Parsing VBIOS init table 3 at offset 0x09EE (--) NOUVEAU(0): Parsing VBIOS init table 4 at offset 0x041F (II) NOUVEAU(0): Output VGA-0 has no monitor section (II) NOUVEAU(0): I2C bus "VGA-0" initialized. (II) NOUVEAU(0): I2C device "VGA-0:E-EDID segment register" registered at address 0x60. (II) NOUVEAU(0): I2C device "VGA-0:ddc2" registered at address 0xA0. (II) NOUVEAU(0): EDID for output VGA-0 (II) NOUVEAU(0): Output VGA-0 disconnected (WW) NOUVEAU(0): No outputs definitely connected, trying again... (II) NOUVEAU(0): Output VGA-0 disconnected (WW) NOUVEAU(0): Unable to find initial modes (EE) NOUVEAU(0): 1526: No valid modes. Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-0.0.12-36.20090514git9656762.fc11.ppc How reproducible: Always Steps to Reproduce: 1. Start with a working xorg.conf which uses nv. 2. Replace the nv driver with nouveau driver. 3. (Possibly disable AIGLX, but this has no effect on the bug.) Actual results: X.org does not work. Expected results: The driver should properly detect both outputs and start X.org. Additional info: 1. xorg.conf, Xorg.0.log, output of dmesg and output of lspci -v is attached 2. nvidiafb was disabled
The problem can be partially fixed by tweaking the current version of Nouveau in Rawhide (xorg-x11-drv-nouveau-0.0.14-1.20090701git6d14327.fc12) thanks to a workaround in the driver (the card's BIOS lacks the DCB output table and the outputs configuration needs to be hardwired in the driver). However, it is still not perfect, as I was only able to get the external mini-VGA output working, the integrated flat panel only shows colored bars. For details see https://bugs.freedesktop.org/show_bug.cgi?id=21273
The problem is present in the current rawhide (as of 2009-09-09) even with KMS enabled and both nvidiafb and offb disabled. The output gets scrambled during KMS initialization, but no proper mode is set. The X.org nouveau driver then causes X.org to crash.
Created attachment 360255 [details] dmesg output on rawhide (2009-09-09) showing KMS to fail
Created attachment 360256 [details] X.org log on rawhide (2009-09-09) showing the nouveau driver to crash X.org
Do you have the ability to ssh into the machine at all? Are you able to boot with "3" added to your boot options, and then either by typing blindly or ssh'ing into the machine remotely grab a VBIOS image? You'll need: http://cgit.freedesktop.org/~stuart/vbtracetool/ And "./vbtracetool -w 2>vbios.rom" will grab you a ROM image.
I can ssh into the machine or use offb (while disabling nouveau KMS) to get a reasonable console access. I was able tu dump the VBIOS either from the OpenFirmware device tree or by programming the PCI bus directly and mmaping /dev/mem at the specific expansion ROM area. I'll try vbtracetool and post the VBIOS images ASAP (unfortunately I have turned the machine off and I am away from my office now). What I have understood by examining the VBIOS is that it really lacks the DCB table. But there simply has to be some way how to fake the correct data and initialize both outputs (or at least the primary one) of the card (Mac OS X can do it, so it has to be technically possible even with the missing structures in VBIOS). The guys on the freedesktop.org bugzilla have suggested some patches for a similar brain dead nVidia in a PowerMac (see https://bugs.freedesktop.org/show_bug.cgi?id=21273), but even after tweaking the "magic values" don't work for me and my knowledge of the internals of nVidia (or Nouveau, for that matter) is very limited.
Created attachment 360492 [details] VBIOS image from OpenFirmware tree
Created attachment 360493 [details] VBIOS image from PCI
Created attachment 360494 [details] Complete OpenFirmware device tree
Created attachment 360495 [details] X.org log with KMS off
Comment to the previous four attachments: Even after some tweaking of vbtracetool (it is too x86-centric, there are no IOPLs and a separate I/O address space on PowerPC) I was unable to make it dump some data. The output on stdout was: Using card 10de:0174 on 0080 Nvidia card -- using PROM/PRAMIN BIOS Using card memory region at 0x91000000 Attempting to locate BIOS image in PROM... BIOS signature not found Attempting to locate BIOS image in PRAMIN... BIOS checksum invalid Failed to load alternate image, proceeding to use PCI ROM However, you can have a look at VBIOS image copied from the OpenFirmware device tree (NVDA,BMP) and a dump after reprogramming the PCI bus (vbios.rom), which is slightly larger, but I don't know if this is just some garbage. I have also attached a complete OFW device tree, because it might contain some information about the configuration of the video outputs. Finally, I have managed to start X.org with xorg-x11-drv-nouveau-0.0.15-9.20090910git806eaf6.fc12 by turing KMS off and manually rmmoding nouveau, drm and ttm kernel modules. See the new X.org log attached. This time there is no segfault, but the external VGA in not detected and the integrated flat panel remains black. Thanks for any insights!
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 (at least F12Beta, but even better if the very latest versions). 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.]
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The bug is still present in Fedora 12 release. Nothing noteworthy has been done in the sources to tackle this problem since 2009-07-07.
I have F13 on a Compaq R3000z with the nVidia Corporation NV17 [GeForce4 440 Go 64M] (rev a3) The driver in the 2.6.33.5-124.fc13.x86_64 works fine, however later kernels don't work, for example 2.6.34.6-47.fc13.x86_64. I tried creating an xorg.conf file with system-display-config when running with the -124 kernel, that made things much worse, only a little square displayed. I had to remove the xorg.conf file to get back to the point where the -124 kernel would work. This is a killer problem for these graphics chip because there is no alternative on F13 to the Nouveau driver. The Nvidia binary driver for the 440 GO is the 96xx driver which lacks support for Xorg 1.8.
martin: how's your experience with this with f13?
(In reply to comment #16) > how's your experience with this with f13? None. Since Fedora 13 PowerPC is no longer a primary architecture and there is no release of F13 for PowerPC as a secondary architecture (AFAIK). Since F12 is still supported, I still use it on my iMac G4. After F14 I would be forced to move to Debian (or whatever) and spam their Bugzilla with this issue :)
I've put F14 on my antique laptop with the 440GO and Nouveau works fine, the but that was introduced in F13 is fixed in F14.
(In reply to comment #18) Well, this bug is evidently unique to the "brain-dead" 440 Go in the iMac G4 machine (and possibly other PowerPC-based Apple machines). I have never claimed that the same issue can be observed on any x86-based computer. In fact, the real issue is that the Nouveau driver is too much dependent on the specific BIOS data (which are not present in the OFW-compliant firmware of the 440 Go in the iMac) and does not provide any way how to easily supply the configuration manually. However, it is futile to discuss this further on this Bugzilla since Fedora does not support PowerPC anymore ..
"However, it is futile to discuss this further on this Bugzilla since Fedora does not support PowerPC anymore .." It does. It's just a secondary arch now, not a primary one. But it's still a part of Fedora. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #20) > "However, it is futile to discuss this further on this Bugzilla since Fedora > does not support PowerPC anymore .." > > It does. It's just a secondary arch now, not a primary one. But it's still a > part of Fedora. > > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers It;s not a Power PC bug, I've experienced it on a Compaq R3000z which is an AMD64 processor with a 440 GO graphics chip. However it's cleared up in F14 so this bug can probably be closed.
(In reply to comment #19) > (In reply to comment #18) > > Well, this bug is evidently unique to the "brain-dead" 440 Go in the iMac G4 > machine (and possibly other PowerPC-based Apple machines). I have never claimed > that the same issue can be observed on any x86-based computer. This should actually be fixed in the latest F14 kernels, if not in releases, whatever's in koji has a fix that looks relevant. > > In fact, the real issue is that the Nouveau driver is too much dependent on the > specific BIOS data (which are not present in the OFW-compliant firmware of the > 440 Go in the iMac) and does not provide any way how to easily supply the > configuration manually. I wouldn't say "too dependant", it's actually necessary, really. The only way to fix boards with broken (yes, broken) VBIOS tables is to add vendor and board-specific workarounds for them. Which, is exactly what's been done in this case. Anyway, hopefully you'll have some luck with F14! :) > > However, it is futile to discuss this further on this Bugzilla since Fedora > does not support PowerPC anymore ..
(In reply to comment #20) > It does. It's just a secondary arch now, not a primary one. But it's still a > part of Fedora. Yes, true. However, without stable releases it makes it definitively non-trivial to use Fedora on PowerPC. (In reply to comment #22) > This should actually be fixed in the latest F14 kernels, if not in releases, > whatever's in koji has a fix that looks relevant. OK, just give me some time to install/compile the relevant packages on my iMac and test it.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
I am sorry to say but the bug is still not fixed even in F14. The driver currently contains some default values which are probably very similar to those I was able to invent in comment #1. The result is that the external VGA output is not detected, the integrated LCD is detected as VGA and I can only see funny colored bars. I have compiled the following packages from F14 (including tons of dependencies) by hand in the F12 for PPC: kernel-2.6.35.6-50.fc12.ppc.rpm libdrm-2.4.22-1.fc12.ppc.rpm xorg-x11-drv-nouveau-0.0.16-13.20101010git8c8f15c.fc12.ppc.rpm
Created attachment 459469 [details] Kernel log from the latest nouveau (F14)
Created attachment 459471 [details] Fully colored bars which I can see with the latest nouveau
Can you give this scratch build a try: http://koji.fedoraproject.org/koji/taskinfo?taskID=2594332
(In reply to comment #28) Brilliant, the patch nv17_imac_dcb.patch really does the trick, thank you! Are you going to push the patch upstream or should I take cake of that? Anyhow, with respect to F14 this bug can be closed.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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