Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Our infrastructure migration is complete. Please remember to update your SSH remote to point to ssh.gitlab.freedesktop.org; SSH to the old hostname will time out. You should not see any problems apart from that. Please let us know if you do have any other issues.
On xorg-server-1.11.4 works fine with a Radeon 7850 running with the VESA
driver on FreeBSD 9.1. Upgrading to xorg-server-1.12.4 causes the X11
server to crash during startup when int10 / VBE is being initialized.
Tracing through the code shows the problem is cause by libpciaccess
missing routines for implementing legacy I/O on FreeBSD. With the
enclosed patch applied xorg-server-1.12.4 passes a quick smoke test.
My text somehow disappeared when attaching the patch.
This patch is a better more complete solution to the above problem. It has been in use for quite some time, and is tested on both i386 and amd64 (x86_64) platform, possibly others.
FreeBSD does not have PCI_MAGIC_IO_RANGE as far as I can tell, but the patch originally comes from the debian/kFreeBSD project, although it has been slightly modified locally by Jung-uk Kim (jkim@FreeBSD.org). I don't know if this should be added to the copyright notice as well. I assumed not, since it was not done when jkim committed the changes.
I have send mail to both Jung-un Kim and Robert Millan asking for their review and sign-off.
Since a revised patch in "git format-patch" style wasn't provided, I have
cobbled together a commit message from the previous bug comments and
pushed to git master:
I will have to look through this discussion, I was not aware that it existed.
So please, could you use my original patch instead?
I unfortunately know very little about how libpciaccess works, only that it does work. Another FreeBSD developer changed your patch to use in*/out* with the motivation that (from the commit log):
"Replace bus_space(9) functions with native CPU instructions. These KPIs
should never be used in user space. Also, this simplifies the patch a bit."
I'll ask him or someone else with more kernel knowledge, to take another look.
The "9" in bus_space(9) is a giveaway. This is a kernel-only API. The fact that it works in userland at all is an artifact of the i386/amd64-specific implementation, where bus_space_tag_t is a simple integer. On other systems, such as sparc64 and mips, it is a more complex type and these interfaces cannot possibly work outside the kernel.
The outb/outb/outl functions are pretty much standard in the various BSDs, and are intended to be used outside the kernel at least on OpenBSD and NetBSD. The kernel is supposed to use bus_space(9) after all. Just the header files from where to get them from aren't really standardized (and it seems NetBSD recently changed its mind on where to put them).
I don't see an issue to be solved. If there is an actual problem on GNU/kFreeBSD, it should provide a proper <machine/cpufunc.h>.