Created attachment 24925 [details] xorg.conf I try current git nouveau driver. It doesn't work on my machine.
Created attachment 24926 [details] xorg.log
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
Created attachment 24927 [details] Xorg.log on nv driver
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
Created attachment 24929 [details] Open Firmware file NVDA,BMP
(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
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
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.
Created attachment 24993 [details] second rom file
(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.
I'll collect information in /proc/device-tree at night. Could I update rom without MACOS? I don't have installed one.
(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.
Created attachment 25003 [details] /proc/device-tree Archive of /proc/device-tree.
What output connectors does this computer have (VGA, DVI, TV, etc)? Am I correct to assume it's some sort of PowerMac G4?
Created attachment 25009 [details] Back side of videocard Yes, it is mac G4. Threre is a DVI and the some Apple's stuff.
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.
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.
(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/ ?
Created attachment 26293 [details] Result of nvclock -d -i
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.
Created attachment 26313 [details] [review] patch B (2nd of two test patches)
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.
Created attachment 26360 [details] Log of xorg with patch A
Created attachment 26361 [details] xorg log with patch B
Created attachment 26362 [details] drm messages from dmesg with patch A
Created attachment 26363 [details] drm messages from dmesg with patch B
(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.
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.
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.
(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?
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
Really, it is looked like bad fonts only on first initialization. How about error of reservation memory?
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.
Created attachment 26770 [details] Registers with dvi monitor
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.
(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.
Created attachment 27465 [details] Output of radeontool on GeForce4 440 Go Output of radeontool on GeForce4 440 Go
Created attachment 27466 [details] Output of nvclock on GeForce4 440 Go Output of nvclock on GeForce4 440 Go
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 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.
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.
(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"?
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?
I've pushed Francisco's patch to nouveau git.
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.
> 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.
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.
Created attachment 40607 [details] dmesg log of kernel with patch.
Created attachment 40608 [details] Xorg.log According to log weren't files of dri devices.
Created attachment 40609 [details] Result of lspci after try of loading driver.
(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.
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.
Created attachment 40815 [details] Xorg.log with parameter video=offb:off
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)
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.
Created attachment 40857 [details] dmesg wiith first patch parameter video=offb:off
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.
(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.
Created attachment 40932 [details] registers without X booting. Kernel parameters: "video=ofonly nouveau.modeset=0"
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?
Created attachment 40933 [details] Registers for kernel parameters: video=offb:off nouveau.modeset=0 I guess kernel doesn't work with mac console.
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.
Created attachment 40968 [details] dmesg with third patch kernel parameters" video=ofonly"
Created attachment 40969 [details] dmesg with third patch kernel parameters "video=offb:off" Unfortunately, it still doesn't work.
Created attachment 41046 [details] Difference in register on kernel 2.6.36.2 beetween OpenFB and NouveauFB
Created attachment 41047 [details] Difference in registers on kernel 2.6.37-rc5 with patch beetween OpenFB and NouveauFB
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.
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
Created attachment 64352 [details] Log of kernel 3.4.5 Problem is still actual on the kernel 3.4.5
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.
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.
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.
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;
So, does it work with this patch?
No, it doesn't work. Monitor suspends.
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?
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.
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.)
Also, with nouveau loaded (with modesetting), would be great to see the output of ls /sys/class/drm/ grep . /sys/class/drm/card*-*/*
Created attachment 85418 [details] xrandr --verbose
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?
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
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.
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).
Created attachment 85421 [details] boot on 3.10.9 kernel
I don't have debugfs enabled in kernel. I can rebuild it, but it need time.
Created attachment 85424 [details] vbios from debugfs
Also, there is a file /sys/kernel/debug/dri/64/vbios.rom in the file system.
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
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.
Created attachment 85443 [details] kernel log with parameters drm.debug=0xe nouveau.debug=debug Yes, 1600X1200 is my resolution.
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]
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.
(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?
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.
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.
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)
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?
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.
(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).
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.
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.
Created attachment 93009 [details] kernel log for patch: fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, 1, all_heads, 2);
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
(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...]
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/3.
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.