Bug 15206

Created attachment 15470 [details]
xrandr output (dual DVI)

This is a known issue, the G5's have a 2nd dvi transmitter on their card. We currently don't know how to activate that.

Any hints/ideas/thumb-sucking on where to probe and muck around?

Created attachment 15471 [details]
xrandr output, mixed VGA/DVI

You might like to try again with an up-to-date checkout. Off-ship dvi is now fixed for nv2x and nv3x x86, but I've no idea about nv4x and PPC :) It will probably help to boot with both monitors plugged so the open firmware stuff can set up as much as possible.

I also have this problem, but on x86.

If I open 1 xserver with 2 nouveau screens, one of the screens will open normally and the other will get black. X won't put anything wrong on the log (as if everything started normally).

Then, if I open an X client and then kill it (like: DISPLAY=:0.0 xterm, and then ctrl+c) the Xserver will crash, and will print something like this:

(EE) NOUVEAU(0): [DRI] Locking deadlock.
        Already locked with context 136431004,
        trying to lock with context 2.
(EE) NOUVEAU(0): Error creating device

Fatal server error:
AddScreen/ScreenInit failed for driver 0


Should "2" be a pointer? Unitialized variable problem?


My xorg.conf is configured to open a screen for each output.



I also discovered that if I use one nouveau in one screen and nv in the other, the same problem will happen.

There is also a related problem that might have the same cause:
If I open 1 xserver with a nouveau screen and a radeonhd screen, both screens will open normally, but when I kill an X client (like opening an xterm and then killing it) the machine will freeze, and won't even respond to ping!

Since both events are triggered when a client dies, they might have the same cause. Maybe they are not related.

Cards I used to test:
GeForce 7300
GeForce fx 5500

And the ATI mentioned as a RS690 (X1200).

Nouveau version is the most recent today.(e034616ab2bbbc486f90c5f64e2bd2de194cf92e)


Pieces of xorg.conf:
#### nvidia1 DVI-to-VGA + VGA ####
Section "Device"
    Identifier     "nvidia1"
    Driver         "nouveau"
    BusID          "PCI:2:0:0"

    Option "monitor-DVI-A-0" "nvidia1-DVI"
    Option "monitor-VGA-0"   "nvidia1-VGA"
EndSection

Section "Monitor"
    Identifier "nvidia1-DVI"
    Option "PreferredMode" "1024x768"
    Option "Enable" "true"
EndSection

Section "Monitor"
    Identifier "nvidia1-VGA"
    Option "PreferredMode" "1024x768"
    Option "Enable" "true"
    Option "RightOf" "nvidia1-DVI"
EndSection

#### nvidia2 DVI cable + VGA####
Section "Device"
    Identifier     "nvidia2"
    Driver         "nouveau"
    BusID          "PCI:3:1:0"

    Option "monitor-DVI-A-0" "nvidia2-DVI"
    Option "monitor-VGA-0"   "nvidia2-VGA"
EndSection

Section "Monitor"
    Identifier "nvidia2-DVI"
    Option "PreferredMode" "1024x768"
    Option "Enable" "true"
EndSection

Section "Monitor"
    Identifier "nvidia2-VGA"
    Option "PreferredMode" "1024x768"
    Option "Enable" "true"
    Option "RightOf" "nvidia2-DVI"
EndSection

Paulo, please open a separate bug for your issue; your problem is using two cards simultaneously, the original bug is someone using one card with two monitors.

Created attachment 17245 [details]
Xorg.0.log

(In reply to comment #5)
> You might like to try again with an up-to-date checkout. Off-ship dvi is now
> fixed for nv2x and nv3x x86, but I've no idea about nv4x and PPC :) It will
> probably help to boot with both monitors plugged so the open firmware stuff can
> set up as much as possible.
Sorry about the delay, but I was busy, and didn't get a chance to test it until now.

It's not moved forward, in fact it's even worse now. X doesn't even start on a single display, let alone get two of them up. Here's the kernel log, and I'll attach the Xorg.log in a moment.

From the kernel:
[   73.994279] [drm] Initialized drm 1.1.0 20060810
[   74.003382] PCI: Unable to reserve mem region #2:10000000@90000000 for device 0000:0b:00.0
[   74.003933] [drm] Detected an NV40 generation card (0x043100a4)
[   74.003940] [drm] Initialized nouveau 0.0.10 drm-2.3.0-1298-g8712f0a17bb135d4a on minor 0
[   74.003974] [drm] Used old pci detect: framebuffer loaded
[   74.004972] [drm] OF bios successfully copied (6447 bytes)

Versions:
xf86-video-nouveau df52dc4664df11d57fcf8a6c9ae3f87a149e5392
x11-drm 8712f0a17bb135d4ad3eb85b30f47c561cf9c148
libdrm 8712f0a17bb135d4ad3eb85b30f47c561cf9c148
mesa d785a0c8b2ff45d07a8d2992d089eb96c04658db (gallium-0.1 branch)

It's an endian problem.

0x36 into the BIOS, there is a pointer to the DCB.
On PPC, the pointer is _NOT_ swapped. If it does get swapped, then it points to a valid DCB structure. The definitions of le16_to_cpu/le32_to_cpu need changing!

0000030: 0100 0000 b010 0b18 3036 2f32 342f 3035
...
0001810: 18cb bddc 4e85 18d8 18e4 18f0 18fe 1812

See the attached hexdump of NVDA,BMP.

Created attachment 17275 [details]
Hexdump from /proc/device-tree/pci@0,f0000000/NVDA,Parent@0/NVDA,BMP

Created attachment 17276 [details]
20080620_Xorg_nouveau.log

After forcibly changing the le{16,32}_to_cpu definitions to do the bswap{16,32}, here's what happens.

The full Xorg.log is attached, but the snippet at the end that catches my eye is:
(II) [drm] DRM interface version 1.3
(II) [drm] DRM open master succeeded.
(II) NOUVEAU(0): [drm] Using the DRM lock SAREA also for drawables.
(II) NOUVEAU(0): [drm] framebuffer handle = 0x98000000
(II) NOUVEAU(0): [drm] added 1 reserved context for kernel
(II) NOUVEAU(0): X context handle = 0x1
(II) NOUVEAU(0): [drm] installed DRM signal handler
(EE) NOUVEAU(0): Failed to allocate memory for framebuffer!


Kernel log:
[84617.583277] [drm] Initialized drm 1.1.0 20060810
[84620.167843] PCI: Unable to reserve mem region #2:10000000@90000000 for device 0000:0b:00.0
[84620.168414] [drm] Detected an NV40 generation card (0x043100a4)
[84620.168423] [drm] Initialized nouveau 0.0.10 drm-2.3.0-1298-g8712f0a17bb135d4a on minor 0
[84620.168461] [drm] Used old pci detect: framebuffer loaded
[84621.597255] [drm] OF bios successfully copied (6447 bytes)
[84621.598177] [drm] OF bios successfully copied (6447 bytes)
[84622.202587] [drm] OF bios successfully copied (6447 bytes)
[84622.203405] [drm] OF bios successfully copied (6447 bytes)
[84622.204114] [drm] OF bios successfully copied (6447 bytes)
[84622.253426] [drm] Allocating FIFO number 0
[84622.266771] [drm] nouveau_fifo_alloc: initialised FIFO 0
[84622.266940] [drm:nouveau_ioctl_getparam] *ERROR* unknown parameter -4611686003779437824
[84622.267055] [drm:nouveau_ioctl_getparam] *ERROR* unknown parameter -4611686003779437824
[84622.267157] [drm:nouveau_ioctl_getparam] *ERROR* unknown parameter -4611686003779437824
[84623.330948] [drm] nouveau_fifo_free: freeing fifo 0

Tracing the memory allocation failure:
src/nv_driver.c:1556:NVMapMem fails calling nouveau_bo_new(...), returns -ENOMEM;
src/nouveau_bo.c:55:nouveau_bo_new drmCommandWriteRead fails, returns -ENOMEM;

Ok, I made some very significant progress now. The memory allocation issue was a bug in x11-drm, and was fixed by commit 1915de2c56d71bbd04a7c085cbd35fbe8e33af9d.

The display does come up [1], and xrandr thinks that both outputs work. However, when I do "xrandr --output DVI-D-1 --right-of DVI-D-0", while the taskbar etc all expand, nothing goes onto the second display. The power LED continues it's blinking to indicate there is no signal.

[1] Additionally, the bswap hack seems to have mucked up colors. White comes out as yellow. Magenta and cyan are reversed. Red and green are reversed. Attachment coming soon.

Created attachment 17284 [details]
New Xorg.log

New Xorg.log that shows both DVI-D-{0,1} coming up on PPC64-32ul / NV43, but there is no actual output on DVI-D-1 yet.

Ok, the bswap and color issue appears to be because of bug 16171 in xorg-server.

*** Bug 19450 has been marked as a duplicate of this bug. ***

Stuart,
we cannot trace the driver on OSX, but we can make register dumps. Would it be useful to dump and compare all known regs under OSX?

d.

"maybe" :)

This is why someone with hardware and time/motivation needs to try it; that's certainly a good first method of attack, equally it could be some magic bits in an unknown register.  Worst of all, it may need some I2C init sequence passing to the off-die chip, which makes it fairly hard to work out.

I don't know how much of this is done in OpenFirmware and how much the Mac driver -- if the OF can light up the DVI-I-1 output at boot there's a reasonable chance someone could get it to work.

This bug is against an ancient version of nouveau. Is this still an issue with recent nouveau?

Please retest. If we get no update within one month I will close this bug. Thanks.

I no longer own the PPC hardware where the bug occurred, so I cannot test.

Closing as we can't process this bug further.