In:
http://lists.freebsd.org/pipermail/freebsd-ppc/2014-April/006924.html
I described a problem by which X.org cannot start on my PowerMac G5
using an NVIDIA card.
At first sight, the xf86-video-nv seems to be broken under powerpc64.
However, after a bit more digging, things appear way more broken
than that because libpciaccess has an undefined behavior on all
non-x86 platforms. This is why I'm filing this under ports and not
under powerpc.
Take a look at this stacktrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 51006400 (LWP 100425)]
0x00000000506557e4 in pci_io_read8 (handle=0x0, reg=10) at common_io.c:181
181 if (reg + 1 > handle->size)
(gdb) bt
#0 0x00000000506557e4 in pci_io_read8 (handle=0x0, reg=10) at common_io.c:181
#1 0x00000000516286a8 in stdReadST01 (hwp=0x510f2000) at vgaHW.c:212
#2 0x000000005162c61c in vgaHWSaveColormap (scrninfp=0x510e1400, save=0x510f2048) at vgaHW.c:1124
#3 0x000000005162c708 in vgaHWSave (scrninfp=0x510e1400, save=0x510f2048, flags=5) at vgaHW.c:1155
#4 0x00000000515bd734 in NVDACSave (pScrn=0x510e1400, vgaReg=0x510f2048, nvReg=0x510f1800, saveFonts=0) at nv_dac.c:311
#5 0x00000000515c4bdc in NVSave (pScrn=0x510e1400) at nv_driver.c:2662
#6 0x00000000515c4164 in NVScreenInit (scrnIndex=0, pScreen=0x510c7f00, argc=1, argv=0xffffffffffffdc18) at nv_driver.c:2430
#7 0x0000000010044b5c in AddScreen (pfnInit=@0x5160f778: 0x515c3f8c <NVScreenInit>, argc=1, argv=0xffffffffffffdc18) at dispatch.c:3797
#8 0x00000000100bfdf8 in InitOutput (pScreenInfo=0x10332b78 <screenInfo>, argc=1, argv=0xffffffffffffdc18) at xf86Init.c:834
#9 0x0000000010021be8 in main (argc=1, argv=0xffffffffffffdc18, envp=0xffffffffffffdc28) at main.c:203
which obviously tells us why the X.org server is crashing: we are
dereferencing a null pointer, and that null handle comes from the
libpciaccess library. The library is called on driver initialization
to get a pointer to the PCI memory (open_legacy_io) and that call
fails because of a missing implementation. The code later happily
stores a null pointer and uses it without care. (First problem:
nowhere in the code, the call to the open_legacy_io function below is
checked for success.)
The libpciaccess library has this gem:
static struct pci_io_handle *
pci_device_freebsd_open_legacy_io(struct pci_io_handle *ret,
struct pci_device *dev, pciaddr_t base, pciaddr_t size)
{
#if defined(__i386__) || defined(__amd64__)
ret->fd = open("/dev/io", O_RDWR | O_CLOEXEC);
if (ret->fd < 0)
return NULL;
ret->base = base;
ret->size = size;
return ret;
#elif defined(PCI_MAGIC_IO_RANGE)
ret->memory = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED,
aperturefd, PCI_MAGIC_IO_RANGE + base);
if (ret->memory == MAP_FAILED)
return NULL;
ret->base = base;
ret->size = size;
return ret;
#else
return NULL;
#endif
}
Which, as far as I can tell, is *completely* wrong because FreeBSD
does not define PCI_MAGIC_IO_RANGE (can't find mentions of it neither
in current nor stable/10) and thus the fallback for non-x86 platforms
cannot ever work (not to mention that aperturefd is not handled at all
in the freebsd_pci.c file).
As it turns out, the offending function was modified in:
https://bugs.freedesktop.org/show_bug.cgi?id=63583
to apparently support non-x86 platforms. Yeah, right...
How-To-Repeat: Attempt to start X on a non-x86 machine with the xf86-video-nv driver
(or possibly any other driver). See the server crash.
I'm unsure why this is failing now given that I think this used to
work fine a few months ago only. Don't know what has changed. Maybe
the new Xorg is triggering this, but no idea.

Nathan fixed this, it's a bug in the nVidia driver. You can find his
patch at http://people.freebsd.org/~nwhitehorn/new_xorg_ppc.diff
These really should go into ports, and I thought they had.
I just now ran into this problem myself, after running just fine for a
long time with that patch, and it turned out I had recompiled and
those patches had been lost in the Xorg update.
- Justin