Bug 21273 - [NV17] PowerMac3,6 Driver can't detect video output and xserver doesn't start
Summary: [NV17] PowerMac3,6 Driver can't detect video output and xserver doesn't start
Status: NEW
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: git
Hardware: PowerPC Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-18 15:01 UTC by Andrey Gusev
Modified: 2015-05-26 16:47 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg.conf (1.15 KB, text/plain)
2009-04-18 15:01 UTC, Andrey Gusev
no flags Details
xorg.log (9.87 KB, text/plain)
2009-04-18 15:03 UTC, Andrey Gusev
no flags Details
Xorg.log on nv driver (37.06 KB, text/plain)
2009-04-18 15:08 UTC, Andrey Gusev
no flags Details
Open Firmware file NVDA,BMP (2.64 KB, application/octet-stream)
2009-04-18 15:52 UTC, Andrey Gusev
no flags Details
rom file (48.00 KB, application/octet-stream)
2009-04-21 04:52 UTC, Danny
no flags Details
second rom file (47.50 KB, application/octet-stream)
2009-04-21 04:53 UTC, Danny
no flags Details
/proc/device-tree (25.77 KB, application/octet-stream)
2009-04-21 10:58 UTC, Andrey Gusev
no flags Details
Back side of videocard (95.27 KB, image/jpeg)
2009-04-21 11:53 UTC, Andrey Gusev
no flags Details
Dump of registers with monitor on dvi output through dvi2vga adapter (8.70 KB, text/plain)
2009-05-11 04:52 UTC, Andrey Gusev
no flags Details
Result of nvclock -d -i (404 bytes, text/plain)
2009-05-29 12:19 UTC, Andrey Gusev
no flags Details
test patch A (4.10 KB, patch)
2009-05-30 16:31 UTC, Stuart Bennett
no flags Details | Splinter Review
patch B (2nd of two test patches) (4.10 KB, patch)
2009-05-30 16:32 UTC, Stuart Bennett
no flags Details | Splinter Review
Log of xorg with patch A (29.16 KB, text/plain)
2009-06-02 15:09 UTC, Andrey Gusev
no flags Details
xorg log with patch B (83.43 KB, text/x-log)
2009-06-02 15:10 UTC, Andrey Gusev
no flags Details
drm messages from dmesg with patch A (91.49 KB, text/plain)
2009-06-02 15:16 UTC, Andrey Gusev
no flags Details
drm messages from dmesg with patch B (30.07 KB, text/plain)
2009-06-02 15:16 UTC, Andrey Gusev
no flags Details
Diff of registers beetween patch A and B. (6.98 KB, text/plain)
2009-06-05 14:42 UTC, Andrey Gusev
no flags Details
Log of register with patchA and corrupted fonts (8.70 KB, text/plain)
2009-06-05 14:58 UTC, Andrey Gusev
no flags Details
Dump of registers with patch B when fonts are bad (8.70 KB, text/plain)
2009-06-05 23:57 UTC, Andrey Gusev
no flags Details
Registers with dvi monitor (8.70 KB, text/plain)
2009-06-14 09:13 UTC, Andrey Gusev
no flags Details
Try of using dvi output (28.72 KB, text/x-log)
2009-06-14 09:16 UTC, Andrey Gusev
no flags Details
Output of radeontool on GeForce4 440 Go (8.70 KB, text/plain)
2009-07-07 09:23 UTC, Martin Decky
no flags Details
Output of nvclock on GeForce4 440 Go (405 bytes, text/plain)
2009-07-07 09:24 UTC, Martin Decky
no flags Details
X log for tweaked Nouveau driver on GeForce4 440 Go (45.81 KB, text/plain)
2009-07-07 09:25 UTC, Martin Decky
no flags Details
A patch for GeForce4 440 Go on iMac G4 (4.64 KB, patch)
2010-11-18 09:54 UTC, Martin Decky
no flags Details | Splinter Review
nv17_mac_dcb.patch (5.73 KB, patch)
2010-11-18 17:35 UTC, Francisco Jerez
no flags Details | Splinter Review
output of lspci -vvnn on my iMac G4 (5.40 KB, text/plain)
2010-11-23 08:57 UTC, Martin Decky
no flags Details
dmesg log of kernel with patch. (28.95 KB, text/plain)
2010-11-27 15:45 UTC, Andrey Gusev
no flags Details
Xorg.log (14.51 KB, text/plain)
2010-11-27 15:47 UTC, Andrey Gusev
no flags Details
Result of lspci after try of loading driver. (6.03 KB, text/plain)
2010-11-27 15:49 UTC, Andrey Gusev
no flags Details
dmesg wiith parameter video=offb:off (28.17 KB, text/plain)
2010-12-05 13:09 UTC, Andrey Gusev
no flags Details
Xorg.log with parameter video=offb:off (28.04 KB, text/plain)
2010-12-05 13:11 UTC, Andrey Gusev
no flags Details
nv17_mac_dcb_1.patch (5.75 KB, patch)
2010-12-06 06:33 UTC, Francisco Jerez
no flags Details | Splinter Review
nv17_mac_dcb_2.patch (5.75 KB, patch)
2010-12-06 06:35 UTC, Francisco Jerez
no flags Details | Splinter Review
dmesg wiith first patch parameter video=offb:off (28.09 KB, text/plain)
2010-12-06 23:14 UTC, Andrey Gusev
no flags Details
dmesg wiith second patch parameter video=offb:off (28.09 KB, application/octet-stream)
2010-12-06 23:22 UTC, Andrey Gusev
no flags Details
registers without X booting. Kernel parameters: "video=ofonly nouveau.modeset=0" (8.70 KB, text/plain)
2010-12-08 12:52 UTC, Andrey Gusev
no flags Details
Registers for kernel parameters: video=offb:off nouveau.modeset=0 (8.70 KB, text/plain)
2010-12-08 14:29 UTC, Andrey Gusev
no flags Details
nv17_mac_dcb_3.patch (7.88 KB, patch)
2010-12-09 08:04 UTC, Francisco Jerez
no flags Details | Splinter Review
dmesg with third patch kernel parameters" video=ofonly" (28.87 KB, text/plain)
2010-12-09 14:41 UTC, Andrey Gusev
no flags Details
dmesg with third patch kernel parameters "video=offb:off" (28.17 KB, text/plain)
2010-12-09 14:45 UTC, Andrey Gusev
no flags Details
Difference in register on kernel 2.6.36.2 beetween OpenFB and NouveauFB (4.92 KB, text/plain)
2010-12-12 14:12 UTC, Andrey Gusev
no flags Details
Difference in registers on kernel 2.6.37-rc5 with patch beetween OpenFB and NouveauFB (8.43 KB, application/octet-stream)
2010-12-12 14:14 UTC, Andrey Gusev
no flags Details
Difference in register on kernel 2.6.36.2 beetween OpenFB and NvidiaFB (4.92 KB, text/plain)
2010-12-12 14:17 UTC, Andrey Gusev
no flags Details
Log of kernel 3.4.5 (5.75 KB, text/plain)
2012-07-18 15:49 UTC, Andrey Gusev
no flags Details
Patch to kernel to test fabricate of dcd output (1.25 KB, patch)
2012-07-18 19:51 UTC, Andrey Gusev
no flags Details | Splinter Review
Log after previous patch (6.91 KB, text/plain)
2012-07-18 19:55 UTC, Andrey Gusev
no flags Details
Log of initialization (5.90 KB, text/plain)
2012-07-18 20:52 UTC, Andrey Gusev
no flags Details
Log initialization (5.21 KB, text/plain)
2012-07-20 08:18 UTC, Andrey Gusev
no flags Details
xrandr --verbose (6.31 KB, text/plain)
2013-09-08 05:44 UTC, Andrey Gusev
no flags Details
bad bios (32.00 KB, text/plain)
2013-09-08 06:11 UTC, Andrey Gusev
no flags Details
boot on 3.10.9 kernel (40.77 KB, text/plain)
2013-09-08 07:23 UTC, Andrey Gusev
no flags Details
vbios from debugfs (2.64 KB, application/octet-stream)
2013-09-08 12:10 UTC, Andrey Gusev
no flags Details
log of loading with workaround (4.39 KB, text/plain)
2013-09-08 16:22 UTC, Andrey Gusev
no flags Details
kernel log with parameters drm.debug=0xe nouveau.debug=debug (71.17 KB, text/plain)
2013-09-08 17:34 UTC, Andrey Gusev
no flags Details
log loading kernel from git (43.97 KB, text/plain)
2014-01-10 19:47 UTC, Andrey Gusev
no flags Details
log of 3.10.0 kernel (39.11 KB, text/plain)
2014-01-11 11:41 UTC, Andrey Gusev
no flags Details
Strings are realted to nouveau and drm in the kernel log. (7.40 KB, text/plain)
2014-01-28 20:45 UTC, Andrey Gusev
no flags Details
Kernel log for fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, 2, 2); (5.60 KB, text/plain)
2014-01-28 21:30 UTC, Andrey Gusev
no flags Details
kernel log for patch: fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, all_heads, 2); (11.35 KB, text/plain)
2014-01-29 18:26 UTC, Andrey Gusev
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Gusev 2009-04-18 15:01:42 UTC
Created attachment 24925 [details]
xorg.conf

I try current git nouveau driver. It doesn't work on my machine.
Comment 1 Andrey Gusev 2009-04-18 15:03:06 UTC
Created attachment 24926 [details]
xorg.log
Comment 2 Andrey Gusev 2009-04-18 15:05:00 UTC
lspci
0000:00:10.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 420] (rev a3) (prog-if 00 [VGA controller])
	Subsystem: nVidia Corporation Device 0008
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 248 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 48
	Region 0: Memory at 91000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at 98000000 (32-bit, prefetchable) [size=128M]
	Region 2: Memory at f1000000 (32-bit, prefetchable) [size=512K]
	Expansion ROM at f1080000 [size=128K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [44] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>
	Kernel driver in use: nvidiafb
Comment 3 Andrey Gusev 2009-04-18 15:08:05 UTC
Created attachment 24927 [details]
Xorg.log on nv driver
Comment 4 Stuart Bennett 2009-04-18 15:31:14 UTC
1) nvidiafb won't work with nouveau, use "video=ofonly" on your kernel boot command
2) there's some failure to find the video outputs, please attach file the Open Firmware file NVDA,BMP which is somewhere in /proc/device-tree
Comment 5 Andrey Gusev 2009-04-18 15:52:12 UTC
Created attachment 24929 [details]
Open Firmware file NVDA,BMP
Comment 6 Stuart Bennett 2009-04-18 16:16:46 UTC
(In reply to comment #5)
> Created an attachment (id=24929) [details]
> Open Firmware file NVDA,BMP

Thanks.  Sadly the information we need is missing from that.  Can you try dumping the whole PCI rom as well, something like:
cd /sys/bus/pci/devices/0000:00:10.0
echo 1 > rom
cat rom > romfile
echo 0 > rom
Comment 7 Andrey Gusev 2009-04-19 01:21:52 UTC
I tried do so, but it doesn't work. I got something like:
[  639.794261] pci 0000:00:10.0: Invalid ROM contents
cat: rom: Input/output error
Comment 8 Danny 2009-04-21 04:52:21 UTC
Created attachment 24992 [details]
rom file

I have no clue why the rom is corrupted. I'm going out on a limp here, and hope that this machine is included in a firmware update for geforce cards that apple released a couple of years ago. I extracted the files from that update and they are attached.

I hope Stuart can see whether or not these roms are actually suited for this card. Of course, all of this does not really help if nouveau actually needs to access the rom to do something meaningful with it.
Comment 9 Danny 2009-04-21 04:53:09 UTC
Created attachment 24993 [details]
second rom file
Comment 10 Stuart Bennett 2009-04-21 06:56:19 UTC
(In reply to comment #8)
> Created an attachment (id=24992) [details]
> rom file
> 
> I have no clue why the rom is corrupted. I'm going out on a limp here, and hope
> that this machine is included in a firmware update for geforce cards that apple
> released a couple of years ago. I extracted the files from that update and they
> are attached.

Thanks for looking at this.  Rather than corruption, I suspect the problem is that for early models such as this they simply didn't bother putting the necessary table in the OF NVDA,BMP.

The NVIDIA1100-A74.rom is for an nv17, but is an older version than the existing one, and also misses the appropriate table :(  However, from looking at the rest of the rom it doesn't look like they've hidden the DCB in some other part of OF

Andrey: could you attach a compressed tar file of /proc/device-tree (or if that's too big, just the nvidia pci-card subdirectory containing NVDA,BMP) so we can see if OF gives any hints, or whether we just have to make this up.

Comment 11 Andrey Gusev 2009-04-21 07:46:05 UTC
I'll collect information in /proc/device-tree at night. Could I update rom without MACOS? I don't have installed one.
Comment 12 Stuart Bennett 2009-04-21 07:50:42 UTC
(In reply to comment #11)
> I'll collect information in /proc/device-tree at night. Could I update rom
> without MACOS? I don't have installed one.

Thanks.  Don't worry about a rom update at the moment; it would be good to fix this without needing an update, and the rom update here wouldn't fix anything anyway.
Comment 13 Andrey Gusev 2009-04-21 10:58:36 UTC
Created attachment 25003 [details]
/proc/device-tree

Archive of /proc/device-tree.
Comment 14 Stuart Bennett 2009-04-21 11:27:42 UTC
What output connectors does this computer have (VGA, DVI, TV, etc)?  Am I correct to assume it's some sort of PowerMac G4?
Comment 15 Andrey Gusev 2009-04-21 11:53:49 UTC
Created attachment 25009 [details]
Back side of videocard

Yes, it is mac G4. Threre is a DVI and the some Apple's stuff.
Comment 16 Stuart Bennett 2009-04-30 13:28:39 UTC
Hi, could you dump some registers for me?  You need to:

git clone git://anongit.freedesktop.org/~stuart/radeontool; cd radeontool; make

then, for all possible options of outputs you can test (DVI (DVI-D) and VGA over DVI (DVI-A) would be good), do a fresh boot of linux (using video=ofonly as mentioned in comment 4), and run "./radeontool unlock; ./radeontool owner 0; ./radeontool regs > regs-OUTPUT_TYPE.log"

once you've got the dump files, attach them to this bug report.
Comment 17 Andrey Gusev 2009-05-11 04:52:53 UTC
Created attachment 25727 [details]
Dump of registers with monitor on dvi output through dvi2vga adapter

I made a dump for monitor on dvi output. Monitor is connected through dvi2vga adapter (monitor has only vga input). Currently, I don't have another one, I am going to buy one, so I will add more results later.
Comment 18 Stuart Bennett 2009-05-27 09:11:50 UTC
(In reply to comment #17)
> Created an attachment (id=25727) [details]
> Dump of registers with monitor on dvi output through dvi2vga adapter

Using the same monitor/connector, can you also attach the results of running "nvclock -i -d", using the nvclock program available from http://www.linuxhardware.org/nvclock/ ?

Comment 19 Andrey Gusev 2009-05-29 12:19:40 UTC
Created attachment 26293 [details]
Result of nvclock -d -i
Comment 20 Stuart Bennett 2009-05-30 16:31:26 UTC
Created attachment 26312 [details] [review]
test patch A

Please try this patch, *and* the following one, and report if either (or both) work.  You will have to remove this patch ("git reset --hard origin") to apply the second one.
Comment 21 Stuart Bennett 2009-05-30 16:32:27 UTC
Created attachment 26313 [details] [review]
patch B (2nd of two test patches)
Comment 22 Andrey Gusev 2009-06-02 15:08:16 UTC
I checked both patches. Both are working, but with first patch, there is a problem with font. See: http://img20.imageshack.us/img20/7747/bugfong.png
As I understand,I need a Gallium3D branch for getting dri.
I attach logs. 
Comment 23 Andrey Gusev 2009-06-02 15:09:56 UTC
Created attachment 26360 [details]
Log of xorg with patch A
Comment 24 Andrey Gusev 2009-06-02 15:10:51 UTC
Created attachment 26361 [details]
xorg log with patch B
Comment 25 Andrey Gusev 2009-06-02 15:16:06 UTC
Created attachment 26362 [details]
drm messages from dmesg with patch A
Comment 26 Andrey Gusev 2009-06-02 15:16:46 UTC
Created attachment 26363 [details]
drm messages from dmesg with patch B
Comment 27 Stuart Bennett 2009-06-04 17:35:34 UTC
(In reply to comment #22)
> I checked both patches. Both are working, but with first patch, there is a
> problem with font. See: http://img20.imageshack.us/img20/7747/bugfong.png

Ok, working is good, but I'm surprised that there's a font problem with only one of the patches.  Is it repeatable -- does the first patch *always* have broken fonts, and does the second patch *always* have working fonts?

If it is repeatable, can you make a register dump while you are using X with patch A and another dump from X using patch B (same procedure as in comment #16)?

> As I understand,I need a Gallium3D branch for getting dri.

You need mesa master branch for 3d, but it's not necessary for 2d, and it's not supported.
Comment 28 Andrey Gusev 2009-06-05 14:42:51 UTC
Created attachment 26477 [details]
Diff of registers beetween patch A and B.

You are right, bug with font is unstable. I try to reproduce it, but while there is the difference of registers with patch A and B. I tested patch B first and my Xserver hung. I found in syslog:
Jun  6 00:55:08 power-debian gdm[3244]: WARNING: gdm_slave_xioerror_handler: Fatal error X - Restart :0
It tried to restart, but all system hung. I couldn't switch to console, but magic keys worked. 
2D is enough for me, but It would be good have AGP acceleration.
Comment 29 Andrey Gusev 2009-06-05 14:58:04 UTC
Created attachment 26478 [details]
Log of register with patchA and corrupted fonts

I reproduced it, after some restarting session, fonts became bad. Logout repaired fonts.
Comment 30 Stuart Bennett 2009-06-05 15:25:17 UTC
(In reply to comment #29)
> Created an attachment (id=26478) [details]
> Log of register with patchA and corrupted fonts
> 
> I reproduced it, after some restarting session, fonts became bad. Logout
> repaired fonts.

So are you saying that sometimes the fonts are ok when using patch A?

Also, have you ever got corrupted fonts with patch B?
Comment 31 Andrey Gusev 2009-06-05 23:57:00 UTC
Created attachment 26485 [details]
Dump of registers with patch B when fonts are bad

>So are you saying that sometimes the fonts are ok when using patch A?
Yes, sometimes they are ok. I can say in most cases.

>Also, have you ever got corrupted fonts with patch B?

Yes, I got corrupted fonts with patch B. It was first initialization. I can see in dmesg:
 
[  124.681630] pci 0000:00:10.0: Invalid ROM contents
[  128.584775] pci 0000:00:10.0: Invalid ROM contents
[  132.443573] pci 0000:00:10.0: Invalid ROM contents
[  216.017077] [drm] Initialized drm 1.1.0 20060810
[  226.226079] pci 0000:00:10.0: BAR 1: can't reserve mem region [0x98000000-0x9fffffff]
[  226.234741] [drm] Detected an NV17 generation card (0x017200a5)
[  226.238082] [drm] Initialized nouveau 0.0.12 libdrm-2.4.9-2-ga1e3ab9e55047c08a on minor 0
[  226.246490] [drm] Used old pci detect: framebuffer loaded
[  267.394922] [drm] OF bios successfully copied (2701 bytes)
[  267.395735] [drm] OF bios successfully copied (2701 bytes)
[  267.396385] [drm] OF bios successfully copied (2701 bytes)
[  267.448771] [drm] Allocating FIFO number 0
[  267.449937] [drm] nouveau_fifo_alloc: initialised FIFO 0
[  267.867452] Process Xorg (pid:3561) mapped non-existing PCI legacy memory for 00000:00
[  267.868387] [drm] Allocating FIFO number 1
[  267.869244] [drm] nouveau_fifo_alloc: initialised FIFO 1
[ 1779.522615] [drm] nouveau_fifo_free: freeing fifo 1
[ 1779.522645] [drm] cleanning a channel with graph in current context
[ 1779.553369] [drm] nouveau_fifo_free: freeing fifo 0
[ 1781.252878] [drm] OF bios successfully copied (2701 bytes)
[ 1781.253641] [drm] OF bios successfully copied (2701 bytes)
[ 1781.254242] [drm] OF bios successfully copied (2701 bytes)
[ 1781.301913] [drm] Allocating FIFO number 0
[ 1781.302997] [drm] nouveau_fifo_alloc: initialised FIFO 0
[ 1781.668603] Process Xorg (pid:5286) mapped non-existing PCI legacy memory for 00000:00
[ 1781.669483] [drm] Allocating FIFO number 1
[ 1781.670341] [drm] nouveau_fifo_alloc: initialised FIFO 1
Comment 32 Andrey Gusev 2009-06-06 10:54:25 UTC
Really, it is looked like bad fonts only on first initialization. How about error of reservation memory?
Comment 33 Stuart Bennett 2009-06-11 13:16:31 UTC
Ok, I've pushed the dvi-analogue patch in http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=b7e3306ddc3693699f6f9de7b22913ee22ed31ed
I can't fix the dvi-digital or apple connectors without some register dumps with those in use.

I'd suggest making a new separate bug for your font problem, and leave this one for the remaining connectors.
Comment 34 Andrey Gusev 2009-06-14 09:13:41 UTC
Created attachment 26770 [details]
Registers with dvi monitor
Comment 35 Andrey Gusev 2009-06-14 09:16:01 UTC
Created attachment 26771 [details]
Try of using dvi output

I tried to use dvi monitor. Driver is initialized, but monitor went to suspend mode. May be this log will be useful.
Comment 36 Andrey Gusev 2009-06-14 09:18:52 UTC
(In reply to comment #33)
> Ok, I've pushed the dvi-analogue patch in
> http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=b7e3306ddc3693699f6f9de7b22913ee22ed31ed
> I can't fix the dvi-digital or apple connectors without some register dumps
> with those in use.
I added attachment of registers with dvi-digital connector. Hope apple don't need.
> 
> I'd suggest making a new separate bug for your font problem, and leave this one
> for the remaining connectors.
> 
I think this good idea.
Comment 37 Martin Decky 2009-07-07 09:23:34 UTC
Created attachment 27465 [details]
Output of radeontool on GeForce4 440 Go

Output of radeontool on GeForce4 440 Go
Comment 38 Martin Decky 2009-07-07 09:24:05 UTC
Created attachment 27466 [details]
Output of nvclock on GeForce4 440 Go

Output of nvclock on GeForce4 440 Go
Comment 39 Martin Decky 2009-07-07 09:25:04 UTC
Created attachment 27467 [details]
X log for tweaked Nouveau driver on GeForce4 440 Go

X log for tweaked Nouveau driver on GeForce4 440 Go
Comment 40 Martin Decky 2009-07-07 09:26:11 UTC
Comment to the previous three attachments:

I have a very similar problem with my iMac G4 (Flat Panel model, GeForce4 440 Go). The machine has an integrated flat panel and a mini-VGA external connector. The BIOS also lacks the DCB table.

With the patch provided here (tweaking it trivially to take the "Working around missing output tables" code path in my case) I get correct output on the external monitor connected via mini-VGA, but the integrated flat panel is not detected (but it glows with funny green bars).

I'm not an expert on nVidia, thus I was just randomly tweaking the patch somehow and the "best" I was able to achieve was a correct detection of both the flat panel and the external monitor over mini-VGA (see attached X.log), but the flat panel still just glows with funny color bars. The combination of the fabricated outputs in this case is as follows:

fabricate_vga_output(dcb, LEGACY_I2C_CRT, 0x1, 0);
fabricate_vga_output(dcb, LEGACY_I2C_PANEL, 0x3, 2);

(Again, please excuse my total ignorance, this is just a random guess.)

I have also attached the output of radeontool and nvclock (with ofonly console, both outputs are on and show kernel output properly). Thanks for any help with configuring both outputs.
Comment 41 Martin Decky 2010-11-18 09:54:24 UTC
Created attachment 40392 [details] [review]
A patch for GeForce4 440 Go on iMac G4

This patch is part of a Fedora kernel package created by Ben Skeggs (http://koji.fedoraproject.org/koji/taskinfo?taskID=2594332) which solves the issue for my GeForce4 440 Go on iMac G4 (both the integrated flat panel and external VGA are detected and work flawlessly).

You might try to adopt it for your case.
Comment 42 Francisco Jerez 2010-11-18 17:24:34 UTC
(In reply to comment #41)
> Created an attachment (id=40392) [details]
> A patch for GeForce4 440 Go on iMac G4
> 
> This patch is part of a Fedora kernel package created by Ben Skeggs
> (http://koji.fedoraproject.org/koji/taskinfo?taskID=2594332) which solves the
> issue for my GeForce4 440 Go on iMac G4 (both the integrated flat panel and
> external VGA are detected and work flawlessly).
> 
> You might try to adopt it for your case.

Martin, can you attach the output you get from "lspci -vvnn"?
Comment 43 Francisco Jerez 2010-11-18 17:35:38 UTC
Created attachment 40401 [details] [review]
nv17_mac_dcb.patch

(In reply to comment #36)
> (In reply to comment #33)
> > Ok, I've pushed the dvi-analogue patch in
> > http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=b7e3306ddc3693699f6f9de7b22913ee22ed31ed
> > I can't fix the dvi-digital or apple connectors without some register dumps
> > with those in use.
> I added attachment of registers with dvi-digital connector. Hope apple don't
> need.
> > 
> > I'd suggest making a new separate bug for your font problem, and leave this one
> > for the remaining connectors.
> > 
> I think this good idea.

Andrey, the patch I'm attaching should fix KMS on your card with DVI-D and DVI-A, can you try it on a recent kernel tree and tell me if it works? If it does, can you provide the output from "lspci -vvnn" as well?
Comment 44 Ben Skeggs 2010-11-19 00:14:33 UTC
I've pushed Francisco's patch to nouveau git.
Comment 45 Martin Decky 2010-11-23 08:57:34 UTC
Created attachment 40509 [details]
output of lspci -vvnn on my iMac G4

(In reply to comment #42)

Hello guys, sorry for my late reply (the machine is not always readily available) and for forgetting to add myself to the CC list. Anyway, even though the patch has been already pushed upstream (thanks!) here is my output of lspci.
Comment 46 Andrey Gusev 2010-11-23 12:42:19 UTC
> Andrey, the patch I'm attaching should fix KMS on your card with DVI-D and
> DVI-A, can you try it on a recent kernel tree and tell me if it works? If it
> does, can you provide the output from "lspci -vvnn" as well?

I will test this patch when find free night. I need upgrade xserver for this, so it takes a lot of time.
Comment 47 Andrey Gusev 2010-11-27 15:42:14 UTC
I tried this patch. It looks like working, but driver still doesn't work for me.
I got 2.6.37-rc3 kernel, applied patch and built it. nvidia frame buffer driver was disabled. I installed xorg-server from experimental of Debian and built libdrm and nouveau driver. After rebooting, monitor suspended. It seems system worked, but monitor didn't display anything.
I attach logs of kernel, X and lspci.
Comment 48 Andrey Gusev 2010-11-27 15:45:36 UTC
Created attachment 40607 [details]
dmesg log of kernel with patch.
Comment 49 Andrey Gusev 2010-11-27 15:47:43 UTC
Created attachment 40608 [details]
Xorg.log

According to log weren't files of dri devices.
Comment 50 Andrey Gusev 2010-11-27 15:49:52 UTC
Created attachment 40609 [details]
Result of lspci after try of loading driver.
Comment 51 Francisco Jerez 2010-11-29 04:34:36 UTC
(In reply to comment #47)
> I tried this patch. It looks like working, but driver still doesn't work for
> me.
> I got 2.6.37-rc3 kernel, applied patch and built it. nvidia frame buffer driver
> was disabled. I installed xorg-server from experimental of Debian and built
> libdrm and nouveau driver. After rebooting, monitor suspended. It seems system
> worked, but monitor didn't display anything.
> I attach logs of kernel, X and lspci.

Apparently you have a handoff issue, try with "video=offb:off" in your kernel command line.
Comment 52 Andrey Gusev 2010-12-05 13:09:33 UTC
Created attachment 40814 [details]
dmesg wiith parameter video=offb:off

I tried this parameter, but nothing is changed except I didn't see process of booting system.
Comment 53 Andrey Gusev 2010-12-05 13:11:01 UTC
Created attachment 40815 [details]
Xorg.log with parameter video=offb:off
Comment 54 Francisco Jerez 2010-12-06 06:33:14 UTC
Created attachment 40826 [details] [review]
nv17_mac_dcb_1.patch

(In reply to comment #52)
> Created an attachment (id=40814) [details]
> dmesg wiith parameter video=offb:off
> 
> I tried this parameter, but nothing is changed except I didn't see process of
> booting system.

Okay, can you revert the previous patch (e.g. "git reset --hard") and try this one? (with the "video" option still in place)
Comment 55 Francisco Jerez 2010-12-06 06:35:34 UTC
Created attachment 40827 [details] [review]
nv17_mac_dcb_2.patch

(In reply to comment #54)
> Created an attachment (id=40826) [details]
> nv17_mac_dcb_1.patch
> 
> (In reply to comment #52)
> > Created an attachment (id=40814) [details] [details]
> > dmesg wiith parameter video=offb:off
> > 
> > I tried this parameter, but nothing is changed except I didn't see process of
> > booting system.
> 
> Okay, can you revert the previous patch (e.g. "git reset --hard") and try this
> one? (with the "video" option still in place)

...or this one if you've no luck with nv17_mac_dcb_1.patch.
Comment 56 Andrey Gusev 2010-12-06 23:14:42 UTC
Created attachment 40857 [details]
dmesg wiith first patch parameter video=offb:off
Comment 57 Andrey Gusev 2010-12-06 23:22:28 UTC
Created attachment 40858 [details]
dmesg wiith second patch parameter video=offb:off

Both patches doesn't change anything. After booting kernel tried to set video mode, but it is failed and monitor suspended. I could make a blind input in console. (At least with second patch).
Additional, I tried to remove nouveau driver and boot without parameter video. (xserver uses frame buffer driver). But all is same. As I understand, driver doesn't take control from kernel.
Comment 58 Francisco Jerez 2010-12-07 04:28:36 UTC
(In reply to comment #57)
> Created an attachment (id=40858) [details]
> dmesg wiith second patch parameter video=offb:off
> 
> Both patches doesn't change anything. After booting kernel tried to set video
> mode, but it is failed and monitor suspended. I could make a blind input in
> console. (At least with second patch).
> Additional, I tried to remove nouveau driver and boot without parameter video.
> (xserver uses frame buffer driver). But all is same. As I understand, driver
> doesn't take control from kernel.

This monitor works with offb, right? Can you get a register dump from it? (while you're in text mode, don't start X) You can use "video=ofonly nouveau.modeset=0" to make sure no other framebuffer driver takes over.
Comment 59 Andrey Gusev 2010-12-08 12:52:27 UTC
Created attachment 40932 [details]
registers without X booting. Kernel parameters: "video=ofonly nouveau.modeset=0"
Comment 60 Andrey Gusev 2010-12-08 12:55:41 UTC
I see in dmesg:
[    0.370917] Console: switching to colour frame buffer device 200x75
[    0.399597] fb0: Open Firmware frame buffer device on /pci@f0000000/NVDA,Parent@10/NVDA,Display-B@1
[    0.400377] fb1: Open Firmware frame buffer device on /pci@f0000000/NVDA,Parent@10/NVDA,Display-A@0

Should I disable Open Firmware frame buffer too?
Comment 61 Andrey Gusev 2010-12-08 14:29:13 UTC
Created attachment 40933 [details]
Registers for kernel parameters: video=offb:off nouveau.modeset=0

I guess kernel doesn't work with mac console.
Comment 62 Francisco Jerez 2010-12-09 08:04:24 UTC
Created attachment 40955 [details] [review]
nv17_mac_dcb_3.patch

(In reply to comment #59)
> Created an attachment (id=40932) [details]
> registers without X booting. Kernel parameters: "video=ofonly
> nouveau.modeset=0"

*Sigh*, your card's actually supposed to use the on-chip TMDS transmitter, but it's missing the BIOS scripts required to set it up. The attached patch hardcodes  some TMDS PLL parameters into the driver. That will hopefully be enough to get you an image through DVI-D.
Comment 63 Andrey Gusev 2010-12-09 14:41:35 UTC
Created attachment 40968 [details]
dmesg with third patch kernel parameters" video=ofonly"
Comment 64 Andrey Gusev 2010-12-09 14:45:07 UTC
Created attachment 40969 [details]
dmesg with third patch kernel parameters "video=offb:off"

Unfortunately, it still doesn't work.
Comment 65 Andrey Gusev 2010-12-12 14:12:49 UTC
Created attachment 41046 [details]
Difference in register on kernel 2.6.36.2 beetween  OpenFB and NouveauFB
Comment 66 Andrey Gusev 2010-12-12 14:14:30 UTC
Created attachment 41047 [details]
Difference in registers on kernel 2.6.37-rc5 with patch beetween  OpenFB and NouveauFB
Comment 67 Andrey Gusev 2010-12-12 14:17:02 UTC
Created attachment 41048 [details]
Difference in register on kernel 2.6.36.2 beetween  OpenFB and NvidiaFB

I made mistake in previous comment to this diff.
Comment 68 Andrey Gusev 2011-06-04 02:57:44 UTC
I checked kernel from git. Problem is still actual:
Jun  4 13:44:10 power-debian kernel: [   41.258117] [drm] Initialized drm 1.1.0 20060810
Jun  4 13:44:10 power-debian kernel: [   41.905751] au8830 0001:10:15.0: enabling device (0004 -> 0007)
Jun  4 13:44:10 power-debian kernel: [   41.905862] Vortex: init....
Jun  4 13:44:10 power-debian kernel: [   42.114836] [drm] nouveau 0000:00:10.0: Detected an NV10 generation card (0x017200a5)
Jun  4 13:44:10 power-debian kernel: [   42.115084] [drm] nouveau 0000:00:10.0: OF bios successfully copied (2701 bytes)
Jun  4 13:44:10 power-debian kernel: [   42.115210] [drm] nouveau 0000:00:10.0: Attempting to load BIOS image from PRAMIN
Jun  4 13:44:10 power-debian kernel: [   42.170951] [drm] nouveau 0000:00:10.0: ... BIOS checksum invalid
Jun  4 13:44:10 power-debian kernel: [   42.171027] [drm] nouveau 0000:00:10.0: Attempting to load BIOS image from PROM
Jun  4 13:44:10 power-debian kernel: [   42.257320] done.
Jun  4 13:44:10 power-debian kernel: [   42.340091] [drm] nouveau 0000:00:10.0: ... BIOS checksum invalid
Jun  4 13:44:10 power-debian kernel: [   42.340148] [drm] nouveau 0000:00:10.0: Attempting to load BIOS image from PCIROM
Jun  4 13:44:10 power-debian kernel: [   42.340286] [drm] nouveau 0000:00:10.0: ... BIOS signature not found
Jun  4 13:44:10 power-debian kernel: [   42.340309] [drm] nouveau 0000:00:10.0: Attempting to load BIOS image from ACPI
Jun  4 13:44:10 power-debian kernel: [   42.340337] [drm] nouveau 0000:00:10.0: ... BIOS signature not found
Jun  4 13:44:10 power-debian kernel: [   42.340360] [drm] nouveau 0000:00:10.0: Using BIOS image from PRAMIN
Jun  4 13:44:10 power-debian kernel: [   42.387733] [drm] nouveau 0000:00:10.0: BMP BIOS found
Jun  4 13:44:10 power-debian kernel: [   42.387784] [drm] nouveau 0000:00:10.0: BMP version 5.21
Jun  4 13:44:10 power-debian kernel: [   42.387808] [drm] nouveau 0000:00:10.0: Bios version 04.17.00.56
Jun  4 13:44:10 power-debian kernel: [   42.387833] [drm] nouveau 0000:00:10.0: No output data (DCB) found in BIOS
Jun  4 13:44:10 power-debian kernel: [   42.388438] i2c i2c-5: therm_windtunnel: attach_adapter method is deprecated
Jun  4 13:44:10 power-debian kernel: [   42.388470] i2c i2c-5: Please use another way to instantiate your i2c_client
Jun  4 13:44:10 power-debian kernel: [   42.392908] [drm] nouveau 0000:00:10.0: Parsing VBIOS init table 0 at offset 0x0149
Jun  4 13:44:10 power-debian kernel: [   42.393046] [drm] nouveau 0000:00:10.0: Parsing VBIOS init table 1 at offset 0x045F
Jun  4 13:44:10 power-debian kernel: [   42.408019] [drm] nouveau 0000:00:10.0: Parsing VBIOS init table 2 at offset 0x0264
Jun  4 13:44:10 power-debian kernel: [   42.428120] [drm] nouveau 0000:00:10.0: Parsing VBIOS init table 3 at offset 0x09EE
Jun  4 13:44:10 power-debian kernel: [   42.428180] [drm] nouveau 0000:00:10.0: Parsing VBIOS init table 4 at offset 0x041F
Jun  4 13:44:10 power-debian kernel: [   42.492733] i2c i2c-6: therm_windtunnel: attach_adapter method is deprecated
Jun  4 13:44:10 power-debian kernel: [   42.492771] i2c i2c-6: Please use another way to instantiate your i2c_client
Jun  4 13:44:10 power-debian kernel: [   42.732051] [drm] nouveau 0000:00:10.0: 1 available performance level(s)
Jun  4 13:44:10 power-debian kernel: [   42.732107] [drm] nouveau 0000:00:10.0: 0: memory 400MHz
Jun  4 13:44:10 power-debian kernel: [   42.732148] [drm] nouveau 0000:00:10.0: c: memory 351MHz core 270MHz
Jun  4 13:44:10 power-debian kernel: [   42.732434] [TTM] Zone  kernel: Available graphics memory: 381492 kiB.
Jun  4 13:44:10 power-debian kernel: [   42.732460] [TTM] Zone highmem: Available graphics memory: 774708 kiB.
Jun  4 13:44:10 power-debian kernel: [   42.732482] [TTM] Initializing pool allocator.
Jun  4 13:44:10 power-debian kernel: [   42.732545] [drm] nouveau 0000:00:10.0: Detected 32MiB VRAM
Jun  4 13:44:10 power-debian kernel: [   42.734905] [drm] nouveau 0000:00:10.0: 64 MiB GART (aperture)
Jun  4 13:44:10 power-debian kernel: [   42.736697] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Jun  4 13:44:10 power-debian kernel: [   42.736729] [drm] No driver support for vblank timestamp query.
Jun  4 13:44:10 power-debian kernel: [   42.737146] [drm] nouveau 0000:00:10.0: Setting dpms mode 3 on vga encoder (output 0)
Jun  4 13:44:10 power-debian kernel: [   42.758052] i2c i2c-7: therm_windtunnel: attach_adapter method is deprecated
Jun  4 13:44:10 power-debian kernel: [   42.758088] i2c i2c-7: Please use another way to instantiate your i2c_client
Jun  4 13:44:10 power-debian kernel: [   42.774005] No connectors reported connected with modes
Jun  4 13:44:10 power-debian kernel: [   42.774037] [drm] Cannot find any crtc or sizes - going 1024x768
Jun  4 13:44:10 power-debian kernel: [   42.774261] [drm] nouveau 0000:00:10.0: allocated 1024x768 fb: 0x49000, bo eedf4800
Jun  4 13:44:10 power-debian kernel: [   42.775966] Console: switching to colour frame buffer device 128x48
Jun  4 13:44:10 power-debian kernel: [   42.777549] fb0: nouveaufb frame buffer device
Jun  4 13:44:10 power-debian kernel: [   42.777578] drm: registered panic notifier
Jun  4 13:44:10 power-debian kernel: [   42.777617] [drm] Initialized nouveau 0.0.16 20090420 for 0000:00:10.0 on minor 0
Comment 69 Andrey Gusev 2012-07-18 15:49:02 UTC
Created attachment 64352 [details]
Log of kernel 3.4.5

Problem is still actual on  the kernel 3.4.5
Comment 70 Andrey Gusev 2012-07-18 19:51:53 UTC
Created attachment 64361 [details] [review]
Patch to kernel to test fabricate of dcd output

I tried to shrink a bug. NV driver uses i2c bus for detection
[    71.463] (II) NV(0): I2C bus "DDC" initialized.
[    71.463] (II) NV(0): Probing for analog device on output A...
[    71.465] (--) NV(0):   ...can't find one
[    71.465] (II) NV(0): Probing for analog device on output B...
[    71.467] (--) NV(0):   ...can't find one
[    71.467] (II) NV(0): Probing for EDID on I2C bus A...
[    71.467] (II) NV(0): I2C device "DDC:ddc2" registered at address 0xA0.
[    71.470] (II) NV(0):   ... none found
[    71.470] (II) NV(0): Probing for EDID on I2C bus B...
[    71.519] (--) NV(0): DDC detected a DFP:
[    71.519] (II) NV(0): Manufacturer: GSM  Model: 4e3a  Serial#: 78597
[    71.519] (II) NV(0): Year: 2008  Week: 10
[    71.519] (II) NV(0): EDID Version: 1.3
Current code doesn't init i2c because it can't read dcb table. So I change order of initialization and make initialization of i2c after parsing dcb table. Code of initialization of i2c tries to read dcb table itself, but for my card it is failed to do it.
Comment 71 Andrey Gusev 2012-07-18 19:55:43 UTC
Created attachment 64362 [details]
Log after previous patch

Unfortunately, this change doesn't make good effect. I guess code of fabrication outputs for PowerMac is incorrect.
Comment 72 Andrey Gusev 2012-07-18 20:52:32 UTC
Created attachment 64364 [details]
Log of initialization

I noted, that outputs fabricate only for PowerMac4,5, but I have PowerMac3,6. After changing I got this log. There is a correct resolution of monitor 1600X1200, but monitor suspended and I didn't see console.
Comment 73 Andrey Gusev 2012-07-20 08:18:52 UTC
Created attachment 64417 [details]
Log initialization

After this patch
diff -u linux_stock/drivers/gpu/drm/nouveau/nouveau_bios.c linux-3.4/drivers/gpu/drm/nouveau/nouveau_bios.c
--- linux_stock/drivers/gpu/drm/nouveau/nouveau_bios.c	2012-07-18 23:28:42.467787857 +0400
+++ linux-3.4/drivers/gpu/drm/nouveau/nouveau_bios.c	2012-07-20 00:05:20.048039574 +0400
@@ -6092,10 +6092,18 @@
 #ifdef __powerpc__
 	/* Apple iMac G4 NV17 */
 	if (of_machine_is_compatible("PowerMac4,5")) {
+		NV_INFO(dev, "Fabricate outputs for Apple iMac G4 NV17\n");
 		fabricate_dcb_output(dcb, OUTPUT_TMDS, 0, all_heads, 1);
 		fabricate_dcb_output(dcb, OUTPUT_ANALOG, 1, all_heads, 2);
 		return;
 	}
+	/* Apple PowerMac G4 NV17 */
+	if (of_machine_is_compatible("PowerMac3,6")) {
+		NV_INFO(dev, "Fabricate outputs for Apple PowerMac G4 NV17\n");
+		fabricate_dcb_output(dcb, OUTPUT_TMDS, 0, all_heads, 1);
+		fabricate_dcb_output(dcb, OUTPUT_TMDS, 1, all_heads, 2);
+		return;
+	}
 #endif
 
 	/* Make up some sane defaults */
@@ -6485,19 +6493,23 @@
 	if (!NVInitVBIOS(dev))
 		return -ENODEV;
 
+	NV_INFO(dev, "Init BIOS");
 	ret = nouveau_parse_vbios_struct(dev);
 	if (ret)
 		return ret;
 
-	ret = nouveau_i2c_init(dev);
+	NV_INFO(dev, "Init MXM");
+	ret = nouveau_mxm_init(dev);
 	if (ret)
 		return ret;
 
-	ret = nouveau_mxm_init(dev);
+	NV_INFO(dev, "Parse dcd table");
+	ret = parse_dcb_table(dev, bios);
 	if (ret)
 		return ret;
 
-	ret = parse_dcb_table(dev, bios);
+	NV_INFO(dev, "Init I2C");
+	ret = nouveau_i2c_init(dev);
 	if (ret)
 		return ret;
Comment 74 Marcin Slusarz 2012-07-20 19:02:25 UTC
So, does it work with this patch?
Comment 75 Andrey Gusev 2012-07-20 19:38:51 UTC
No, it doesn't work. Monitor suspends.
Comment 76 Ilia Mirkin 2013-09-06 23:03:34 UTC
I noticed that in your patch you have OUTPUT_TMDS twice instead of OUTPUT_ANALOG the second time. Was that on purpose? Esp since it sounds like you're using the analog "part" of the DVI cable, that seems like it could be relevant. Does this hardware still exist in a working state to test potential patches?

Also, am I correct in understanding that the old "nv" driver worked fine?
Comment 77 Andrey Gusev 2013-09-08 04:35:29 UTC
This card doesn't have analog output, see attachment 25009 [details] in this bug. I have this hardware and use dvi output with nv driver. I tried to find rams from other cards and emulate tables from bios, but it doesn't help.
I saw workarounds was removed from kernel part. It would be good if kernel driver have options for such cases. I haven't tried kms in last kernel, but I think nothing changed. Patches are welcome. I don't know enough about hardware to fix it.
Comment 78 Ilia Mirkin 2013-09-08 04:50:58 UTC
The vast majority of DVI ports on graphics cards can do both digital and analog. That's what makes DVI -> VGA adapters possible. Is the screen that you have connected digital or analog?

Can you supply the output of

xrandr --verbose

when running with the "nv" driver? I just looked over the nv driver's codebase, and unfortunately I don't see any relevant PowerMac hacks, so there must be something it knows that nouveau doesn't.

Can you also upload a copy of your vbios? I think nouveau ignores it for NV17, but would still be interesting to see what it says. (With nouveau loaded, you can get it out of /sys/kernel/debug/dri/0/vbios.rom, or you can use the envytools nvagetbios utility.)
Comment 79 Ilia Mirkin 2013-09-08 04:59:29 UTC
Also, with nouveau loaded (with modesetting), would be great to see the output of

ls /sys/class/drm/
grep . /sys/class/drm/card*-*/*
Comment 80 Andrey Gusev 2013-09-08 05:44:40 UTC
Created attachment 85418 [details]
xrandr --verbose
Comment 81 Andrey Gusev 2013-09-08 06:11:16 UTC
Created attachment 85419 [details]
bad bios

There is err on extracting
./nvagetbios -s PROM  >mybios
Attempt to extract the vbios from card 0 (nv17) using PROM
Invalid checksum. Broken vbios or broken retrieval method?
Comment 82 Andrey Gusev 2013-09-08 06:45:09 UTC
1)ls /sys/class/drm/
card0
card0-VGA-1
controlD64
ttm
version

2)grep . /sys/class/drm/card*-*/*
grep: /sys/class/drm/card0-VGA-1/device: Is a directory
/sys/class/drm/card0-VGA-1/dpms:On
/sys/class/drm/card0-VGA-1/enabled:disabled
/sys/class/drm/card0-VGA-1/status:disconnected
grep: /sys/class/drm/card0-VGA-1/subsystem: Is a directory
Comment 83 Andrey Gusev 2013-09-08 06:50:22 UTC
My screen is digital. nv driver is stupid, it tries every possible output. Nouveau is more smart, it searches this information in bios. So nv works, nouveau doesn't.
Comment 84 Ilia Mirkin 2013-09-08 06:54:41 UTC
Did you try the other ways of obtaining the vbios? (e.g. using pramin with nvagetbios, or looking in the path I mentioned, with debugfs mounted, and nouveau loaded).

Also, would love to see a kernel log for a semi-recent kernel (say, 3.8+) that shows what nouveau thinks it's doing.

The fact that you only see the VGA-1 connector is clearly a bad sign -- you should have 2 DVI-I connectors, and no VGA connectors (based on the photo).
Comment 85 Andrey Gusev 2013-09-08 07:23:31 UTC
Created attachment 85421 [details]
boot on 3.10.9 kernel
Comment 86 Andrey Gusev 2013-09-08 07:26:41 UTC
I don't have debugfs enabled in kernel. I can rebuild it, but it need time.
Comment 87 Andrey Gusev 2013-09-08 12:10:23 UTC
Created attachment 85424 [details]
vbios from debugfs
Comment 88 Andrey Gusev 2013-09-08 12:13:23 UTC
Also, there is a file /sys/kernel/debug/dri/64/vbios.rom in the file system.
Comment 89 Andrey Gusev 2013-09-08 16:22:12 UTC
Created attachment 85441 [details]
log of loading with workaround

I return workaround to code for PowerMac 3,6:
+	if (of_machine_is_compatible("PowerMac3,6")) {
+		fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 0, all_heads, 1);
+		fabricate_dcb_output(dcb, DCB_OUTPUT_ANALOG, 1, all_heads, 2);
+		return;
+	}
Unfortunately, it doesn't help. Also, there is output card0-DVI-I-1.
cat classdrm 
card0
card0-DVI-I-1
controlD64
ttm
version
Comment 90 Ilia Mirkin 2013-09-08 17:10:19 UTC
Very interesting. Note the

[   22.983172] nouveau  [     DRM] allocated 1600x1200 fb: 0x9000, bo ef220600

That means _something_ is working. I assume 1600x1200 is your monitor's preferred resolution. What happens if you boot with the kernel command line options "drm.debug=0xe nouveau.debug=debug"? That should provide a bunch more info.
Comment 91 Andrey Gusev 2013-09-08 17:34:58 UTC
Created attachment 85443 [details]
kernel log with parameters drm.debug=0xe nouveau.debug=debug

Yes, 1600X1200 is my resolution.
Comment 92 Ilia Mirkin 2014-01-07 07:16:49 UTC
What happens if you only add:

fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, all_heads, 2);

Or only add:

fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, all_heads, 1);

(These should hopefully echo the much earier patches that seemed to help you.)

[i.e. same as in comment #89, but with just one fabricated dcb at a time, and note that I kept the i2c index at 1 for both]
Comment 93 Andrey Gusev 2014-01-10 19:47:01 UTC
Created attachment 91839 [details]
log loading kernel from git

I tried to add only one line:
fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, all_heads, 2);

I see white horizontal lines on the screen and all hung up.
Comment 94 Ilia Mirkin 2014-01-11 05:44:10 UTC
(In reply to comment #93)
> Created attachment 91839 [details]
> log loading kernel from git
> 
> I tried to add only one line:
> fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, all_heads, 2);
> 
> I see white horizontal lines on the screen and all hung up.

Ugh, looks like nouveau might have grown a bug on ppc or something -- the traceback isn't related to the line that you added (hopefully!). What if you apply it to a 3.10 kernel or whatever you were trying with earlier?
Comment 95 Andrey Gusev 2014-01-11 11:41:13 UTC
Created attachment 91856 [details]
log of 3.10.0 kernel

I tried fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, all_heads, 1); on the kernel 3.0.10. Monitor suspended after showing white lines.
Comment 96 Ilia Mirkin 2014-01-18 10:46:50 UTC
So... that's better -- before it was completely shut off, right? I'll keep looking at this to see if I can figure something more out. I think we're on the right track, just not right enough.
Comment 97 Andrey Gusev 2014-01-21 17:40:16 UTC
I made reboot or shutdown. There isn't difference. I want to pay attention, than nvidiafb works perfect. May be it output can give a hint.
[    0.442165] nvidiafb: Device ID: 10de0172 
[    0.446576] nvidiafb: CRTC0 analog not found
[    0.450534] nvidiafb: CRTC1 analog not found
[    0.527317] i2c i2c-0: unable to read EDID block.
[    0.646311] i2c i2c-0: unable to read EDID block.
[    0.765310] i2c i2c-0: unable to read EDID block.
[    1.021533] nvidiafb: EDID found from BUS2
[    1.021579] nvidiafb: CRTC 1 is currently programmed for DFP
[    1.021598] nvidiafb: Using DFP on CRTC 1
[    1.021615] nvidiafb: Panel size is 1600 x 1200
[    1.021633] nvidiafb: Panel is TMDS
[    1.023208] nvidiafb: Flat panel dithering disabled
[    1.030025] Console: switching to colour frame buffer device 200x75
[    1.037505] nvidiafb: PCI nVidia NV17 framebuffer (32MB @ 0x98000000)
Comment 98 Ilia Mirkin 2014-01-23 05:39:17 UTC
Sorry to keep making you try stuff, but can you put up a log of a kernel with

if (of_machine_is_compatible("PowerMac3,6")) {
  fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, all_heads, 2);
  return;
}

[Also, looking at Stuart's patch that worked for you all that while ago... perhaps instead of all_heads (3 in your case) it should be "2"? Worth trying too, but unless it produces substantially diff/better results, I don't need a log from it.]

(You can use 3.13 now -- the bug with instmem you ran into should be fixed now.)

And boot with

nouveau.debug=trace drm.debug=0xe

This should produce a bunch of debug info, which may be helpful. Thanks for that nvidiafb log too.

Also, to be clear -- that fabricate_dcb_output line changes behaviour from "screen suspends due to no output" to "screen on with garbage on it", right?
Comment 99 Andrey Gusev 2014-01-28 20:45:56 UTC
Created attachment 92954 [details]
Strings are realted to nouveau and drm in the kernel log.

I got kernel 3.13.0. Bug is fixed. I haven't tried kernel without patches rather long time. Previously, my monitor suspended and all. But fresh kernel have another behavior. I can see ugly console  in the top part of the screen and white trash in the bottom part. If it helps, I can attach a screen photo.
Comment 100 Ilia Mirkin 2014-01-28 20:54:10 UTC
(In reply to comment #99)
> Created attachment 92954 [details]
> Strings are realted to nouveau and drm in the kernel log.
> 
> I got kernel 3.13.0. Bug is fixed. I haven't tried kernel without patches
> rather long time. Previously, my monitor suspended and all. But fresh kernel
> have another behavior. I can see ugly console  in the top part of the screen
> and white trash in the bottom part. If it helps, I can attach a screen photo.

Doesn't sound like the bug is fixed... it's just not as bad as before.

[   21.317011] nouveau  [     DRM] allocated 1024x768 fb: 0x9000, bo efa73c00

That means it's not really detecting your monitor, since the resolution should be higher. Can you try the modification I suggested in comment #98 ? And attach the logs with the additional debug info from the parameters I mentioned there?

As for the trash that you see -- does it go away if you clear the screen or otherwise make it so that the console updates that area (e.g. run a command with a lot of output, etc).
Comment 101 Andrey Gusev 2014-01-28 21:30:33 UTC
Created attachment 92956 [details]
Kernel log for fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, 2, 2);

Monitor suspends with patch.
+       if (of_machine_is_compatible("PowerMac3,6")) {
+               fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, 2, 2);
+               return;
+       }

I could see log in without patch and I saw symbols on the screen. I'll recheck reaction on big output and switching virtual consoles.
I will try patch from comment 98.
Comment 102 Andrey Gusev 2014-01-28 22:17:11 UTC
I rechecked behavior without patch. I see a console in the left top angle. There is another righter it. Second is the clone of the first. I see same output. I see a log of loading in this console, can log in, switch virtual terminal. There is  a trash on the bottom side of the screen.
I guess the size of console is 1024x768. The size of the second is (1600-1024)x768.
Comment 103 Andrey Gusev 2014-01-29 18:26:21 UTC
Created attachment 93009 [details]
kernel log for patch: fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, all_heads, 2);
Comment 104 Tim Riker 2015-05-26 16:39:33 UTC
What became of this? I installed Ubuntu 14.04 on a Powermac G4 Quicksilver 2002 edition and got a blank screen. I look at the output and it thinks it's using VGA when I suspect it should be using TMDS
Comment 105 Ilia Mirkin 2015-05-26 16:47:26 UTC
(In reply to Tim Riker from comment #104)
> What became of this? I installed Ubuntu 14.04 on a Powermac G4 Quicksilver
> 2002 edition and got a blank screen. I look at the output and it thinks it's
> using VGA when I suspect it should be using TMDS

Nothing AFAIK. I ran out of ideas to try. You can look through some of my suggested patches and try some of them out, perhaps you'll get better results. As I recall, Andrey had some success using xf86-video-nv and/or nvidiafb.

If you have the necessary skills, it shouldn't be *too* difficult to add a *ton* of prints in dispnv04/* and nvidiafb and compare where they start making different decisions about stuff.

Note that dispnv04/* should map pretty closely to xf86-video-nv -- that driver was originally imported as nouveau into the kernel and then modified... dispnv04 is the bits of it that were modified the least. [The details of the history are a bit off there, but close enough... xf86-video-nv was first forked as xf86-video-nouveau and *then* imported into the kernel...]


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.