Bug 827 - sparc64 needs support for pci domains
Summary: sparc64 needs support for pci domains
Status: RESOLVED DUPLICATE of bug 2368
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xorg (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact:
URL: http://bugs.gentoo.org/show_bug.cgi?i...
Depends on:
Reported: 2004-07-06 02:52 UTC by Donnie Berkholz
Modified: 2005-12-28 22:05 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

xorg-6.7.0-pci-domains.patch (1.16 KB, patch)
2004-07-06 02:53 UTC, Donnie Berkholz
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Donnie Berkholz 2004-07-06 02:52:27 UTC
In 2.6, sparc64 has pci domains. This breaks X.org, without the following patch,
backwards-compatible with 2.4.
Comment 1 Donnie Berkholz 2004-07-06 02:53:00 UTC
Created attachment 442 [details] [review]
Comment 2 Donnie Berkholz 2004-07-06 03:16:34 UTC
Credit to Daniel Seyffer <gentoo-bugs@seyffer.de> and Ciaran McCreesh
Comment 3 Donnie Berkholz 2004-07-26 15:21:28 UTC
It appears that a similar fix has already been integrated. See
Comment 4 rspchan 2005-01-11 06:53:34 UTC
What if the graphics card is not on domain 0000?
I have an Radeon at 00003 and it is not being found.
Comment 5 rspchan 2005-01-11 13:39:45 UTC
XFree86 has modified linuxPci.c significantly to
traverse PCI domains -- looks like this is exactly
what is needed to detect graphics cards on higher
numbered domains. Could the maintainer kindly consider
folding in similar changes?

Comment 6 Donnie Berkholz 2005-01-11 13:59:41 UTC
The license is always questionable .. but it was Marc Aurele La France who
committed it.
Comment 7 Evan Langlois 2005-12-19 18:35:20 UTC
Definately would like to know if anyone is working on this.  Can we use the code
from Xfree86 legally (if I use it and get it working, can it be accepted), or do
I have to find my own solution?  Is anyone else working on this?

The "fixed" code is absolutely no use on my box at all.  I'd like to see what
everyone else's /proc/bus/pci looks like to make sure I don't rule anyone out
when I go hacking away ... assuming we can't just plug in the Xfree version.
Comment 8 Alan Coopersmith 2005-12-19 18:44:53 UTC
As far as I know, all code distributed by XFree86 can be reused by anyone legally,
as long as you follow the license terms.   However, X.Org has made the decision 
that the terms of the XFree86 1.1 license do not meet X.Org's goals, and will not
accept code under that license into the X.Org CVS.   Redistributors may choose to
add code under that license into their own packages, but are responsible for 
ensuring they meet the terms imposed by the license.   Code under other licenses
in the XFree86 tree may be acceptable to import to X.Org (and much of it has been
in the original XFree86 4.4RC2 import for X.Org X11R6.7 release).
Comment 9 Evan Langlois 2005-12-21 03:17:59 UTC
There is a PCI domain patch listed in bug #2368 that applies cleanly to my 6.8.2
tree.  It does find my video card in domain 5, but then crashes leaving the
video card in an unknown state.  I don't know which bug is a duplicate of which
since 2368 isn't sparc specific, this bug is, but I don't think the problem is
sparc specific, but thats what I'm testing on.

It only takes me about 3-4 hours to recompile X, so I'm gonna see if I figure
anything out.

I've not tested the patch listed in the Xfree86 tree.  Has anyone else?
Comment 10 Evan Langlois 2005-12-25 18:15:37 UTC
The patch in bug #2368 will solve the remaining issues with PCI domains on
Sparc.  I have a Sun Ultra E450 running kernel 2.6 and have tested the patch
listed in bug #2368 in multiple PCI domains.  Works well and stable!
Comment 11 Alex Deucher 2005-12-29 17:05:59 UTC
dup of 2368

*** This bug has been marked as a duplicate of 2368 ***

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.