Bug#284111: xserver-xfree86: Doesn't scan PCI domains above 0000 on startup
On Thu, 13 Jan 2005 17:14:04 -0700, Bjorn Helgaas [EMAIL PROTECTED] said: Bjorn The domain changes to /proc/bus/pci are implemented for Bjorn sparc64, ppc64, ia64, alpha, and mips (see pci_name_bus()). Bjorn They aren't all identical (sparc64 uses %04x:%02x always, Bjorn while ia64 uses %04x:%02x only for non-zero domain) Ah, yes, I thought there was something that was done differently from sparc. Only printing non-zero domains seems like the right thing to do, since it preserves backwards-compatibility. Speaking of pci_name_bus(), it's amazing folks would introduce new APIs that take a string buffer argument _without_ a size argument... --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#284111: xserver-xfree86: Doesn't scan PCI domains above 0000 on startup
On Fri, 31 Dec 2004 03:01:27 -0500, Branden Robinson [EMAIL PROTECTED] said: Branden Yes; I apologize for hastily dismissing your report. The Branden fix is probably a for and a break away, but I think I will Branden CC David Mosberger on this message, as he almost certainly Branden has more clues to bring to the table than I do. Branden I wonder how many domains we should look for before we give Branden up. I get the feeling doing an ftw() on /proc/pci/pci is Branden not a good idea. Even doing as much as a readdir() feels Branden wrong, but maybe not. :-P Hmmh, my patch didn't change the behavior as far as domains are concerned. The old code also looked only at domain 0, IIRC. I'm not terribly familiar with multi-domain machines. From what I recall, the domain-changes to /proc/bus/pci were SPARC-specific and I'm not sure whether that approach is the final answer. I cc'd Bjorn Helgaas and Alex Williamson in case they want to comment, since they have more experience with large/multi-domain Itanium machines. --david
Bug#279436: xserver-xfree86: fix for bug #246782 breaks X server on machines with no PCI bus #0
Package: xserver-xfree86
Version: 4.3.0.dfsg.1-8
Severity: normal
Tags: patch
It appears this change:
xfree86 (4.3.0.dfsg.1-5) unstable; urgency=low
Changes by Branden Robinson:
* Fix XFree86 X server's PCI bus support code to be able to cope with both
Linux 2.4 and Linux 2.6 styles of organization for /proc/bus/pci, checking
for the 2.6 style first (thanks, Daniel Seyffer and Ciaran McCreesh).
(Closes: #225526)
is keeping X from working on my machine. That machine is a bit
unusual in the sense that it has no PCI bus numbered 0:
$ ls /proc/bus/pci/
40/ 60/ 80/ 81/ devices
Due to this, the workaround for bug #225526 actually ends up breaking
X on my machine:
- if (bus 256)
- sprintf(file, /proc/bus/pci/%02x/%02x.%1x,
- bus, dev, func);
- else
- sprintf(file, /proc/bus/pci/%04x/%02x.%1x,
- bus, dev, func);
+ if (bus 256) {
+ if (stat(/proc/bus/pci/00, ignored) 0)
+ sprintf(file, /proc/bus/pci/:%02x/%02x.%1x\
,
+ bus, dev, func);
+ else
+ sprintf(file, /proc/bus/pci/%02x/%02x.%1x,
+ bus, dev, func);
+ } else {
+ if (stat(/proc/bus/pci/00, ignored) 0)
+ sprintf(file, /proc/bus/pci/:%04x/%02x.%1x\
,
+ bus, dev, func);
+ else
+ sprintf(file, /proc/bus/pci/%04x/%02x.%1x,
+ bus, dev, func);
+ }
So, on my machine (bus is 256), the stat(/proc/bus/pci/00, ignored)
call fails and then X attempts to use PCI-domain numbers,
which is wrong for my machine.
As far as I know, it is bogus to assume every machine has a PCI bus
numbered 0. My proposal is to avoid that assumption by using a patch
along these lines:
---
orig/xfree86-4.3.0.dfsg.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c
2004-11-02 17:46:20.629996688 -0800
+++
xfree86-4.3.0.dfsg.1/build-tree/xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c
2004-11-02 13:52:36.465824860 -0800
@@ -101,10 +101,21 @@
static int
linuxPciOpenFile(PCITAG tag)
{
- static int lbus,ldev,lfunc,fd = -1;
+ static int lbus,ldev,lfunc,fd = -1,with_domain = 0;
+ static const char *format_string[2][2] = {
+ /* without PCI domain #: */
+ {
+ /proc/bus/pci/%02x/%02x.%1x, /* bus # 256 */
+ /proc/bus/pci/%04x/%02x.%1x /* bus # = 256 */
+ },
+ /* with PCI domain #: */
+ {
+ /proc/bus/pci/:%02x/%02x.%1x, /* bus # 256 */
+ /proc/bus/pci/:%04x/%02x.%1x /* bus # = 256 */
+ }
+ };
int bus, dev, func;
charfile[32];
- struct stat ignored;
bus = PCI_BUS_FROM_TAG(tag);
dev = PCI_DEV_FROM_TAG(tag);
@@ -112,22 +123,20 @@
if (fd == -1 || bus != lbus || dev != ldev || func != lfunc) {
if (fd != -1)
close(fd);
- if (bus 256) {
- if (stat(/proc/bus/pci/00, ignored) 0)
- sprintf(file,
/proc/bus/pci/:%02x/%02x.%1x,
- bus, dev, func);
- else
- sprintf(file, /proc/bus/pci/%02x/%02x.%1x,
- bus, dev, func);
- } else {
- if (stat(/proc/bus/pci/00, ignored) 0)
- sprintf(file,
/proc/bus/pci/:%04x/%02x.%1x,
- bus, dev, func);
- else
- sprintf(file, /proc/bus/pci/%04x/%02x.%1x,
- bus, dev, func);
- }
+ retry:
+ sprintf(file, format_string[with_domain][bus = 256],
+ bus, dev, func);
fd = open(file,O_RDWR);
+
+ if (fd 0) {
+ if (!with_domain) {
+ /* try again, this time with domains */
+ with_domain = 1;
+ goto retry;
+ }
+ /* failed even with domains; fall back again */
+ with_domain = 0;
+ }
lbus = bus;
ldev = dev;
lfunc = func;
This fixes the problem on my machine and should still do the right thing
on PCI-domain-enabled SPARC kernels, though I cannot test that myself.
If it looks OK, please merge this patch. It would
Bug#255270: xfree86: libglide3 has now ia64 and amd64 support
On Sat, 17 Jul 2004 05:40:31 +0100, Matthew Wilcox [EMAIL PROTECTED] said: Matthew On Sat, Jul 17, 2004 at 05:43:06AM +0200, Guillem Jover wrote: Could someone with an amd64, ia64 or alpha (I'll take care of i386) and a 3Dfx card with any of the following chipsets: Voodoo Banshee, Voodoo 3, Voodoo 4 or Voodoo 5 Matthew I don't *think* you're going to get any takers on ia64. I think the Matthew workstations have all shipped with ATI or NVidia cards to date. We use to demo OpenGL hw accel with a Merced workstation with a Voodoo 3 card (I think it was Voodoo 3). Unfortunately, the card is a 5V PCI card which cannot be used in the zx1-based workstations anymore, so I stopped using it. --david
Bug#178289: xfree86_4.2.1-5(unstable/ia64): FTBFS: Unknown architecture
On Mon, 3 Feb 2003 01:02:53 -0500, Branden Robinson [EMAIL PROTECTED] said: Branden Bad news. XFree86 CVS HEAD still had this bogus code as of Branden yesterday. As far as ia64 is concerned, the fix is obvious: just ignore all that __LP64__ ugliness. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#178289: xfree86_4.2.1-5(unstable/ia64): FTBFS: Unknown architecture
On Mon, 3 Feb 2003 01:02:53 -0500, Branden Robinson [EMAIL PROTECTED] said: Branden Bad news. XFree86 CVS HEAD still had this bogus code as of Branden yesterday. As far as ia64 is concerned, the fix is obvious: just ignore all that __LP64__ ugliness. --david
Bug#178289: xfree86_4.2.1-5(unstable/ia64): FTBFS: Unknown architecture
On Sun, 26 Jan 2003 16:20:19 -0500, Branden Robinson [EMAIL PROTECTED] said: Branden [debian-ia64: I do not subscribe to this list] On Fri, Jan Branden 24, 2003 at 07:30:43PM -0800, David Mosberger wrote: If you asked me, this has Dave Miller's name written all over it... ;-) Branden Hmmm. :) Actually, I'm wondering whether my theory is holding any water: Dave Miller is using the /emul prefix on SPARC64, so there shouldn't be any need for this gross hack (we do the same on ia64 linux for handling 32-bit x86 objects). Branden Okay. It's possible that this has since been fixed in Branden XFree86 CVS HEAD, then. I'll check. Let's hope so. That code definitively looked gross. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#178289: xfree86_4.2.1-5(unstable/ia64): FTBFS: Unknown architecture
On Sun, 26 Jan 2003 16:20:19 -0500, Branden Robinson [EMAIL PROTECTED] said: Branden [debian-ia64: I do not subscribe to this list] On Fri, Jan Branden 24, 2003 at 07:30:43PM -0800, David Mosberger wrote: If you asked me, this has Dave Miller's name written all over it... ;-) Branden Hmmm. :) Actually, I'm wondering whether my theory is holding any water: Dave Miller is using the /emul prefix on SPARC64, so there shouldn't be any need for this gross hack (we do the same on ia64 linux for handling 32-bit x86 objects). Branden Okay. It's possible that this has since been fixed in Branden XFree86 CVS HEAD, then. I'll check. Let's hope so. That code definitively looked gross. --david
Bug#178289: xfree86_4.2.1-5(unstable/ia64): FTBFS: Unknown architecture
Branden What the hell Mach64's have to do with locale handling is Branden utterly beyond me. Here are the relevant hunks of code: Branden 58 #ifdef _LP64 Branden 59 #if defined(__sparcv9) Branden 60 #define _MACH64_NAMEsparcv9 Branden 61 #define _MACH64_NAME_LEN(sizeof (_MACH64_NAME) - 1) Branden 62 #else /* !defined(__sparcv9) */ Branden 63 #error Unknown architecture Branden 64 #endif /* defined(__sparcv9) */ Branden 65 #endif /* _LP64 */ If you asked me, this has Dave Miller's name written all over it... ;-) The default shared objects on sparc boxes tend to be 32-bit objects, so the sparcv9 postfix is needed to explicitly select the 64-bit shared objects. None of that is needed for ia64. Branden Did the IA-64 toolchain in unstable recently change to Branden define the _LP64 symbol? It appears to be a gcc-3.2 feature: gcc-2.96 defines __LP64__ and gcc-3.2 adds _LP64 on top of that. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#178289: xfree86_4.2.1-5(unstable/ia64): FTBFS: Unknown architecture
Branden What the hell Mach64's have to do with locale handling is Branden utterly beyond me. Here are the relevant hunks of code: Branden 58 #ifdef _LP64 Branden 59 #if defined(__sparcv9) Branden 60 #define _MACH64_NAMEsparcv9 Branden 61 #define _MACH64_NAME_LEN(sizeof (_MACH64_NAME) - 1) Branden 62 #else /* !defined(__sparcv9) */ Branden 63 #error Unknown architecture Branden 64 #endif /* defined(__sparcv9) */ Branden 65 #endif /* _LP64 */ If you asked me, this has Dave Miller's name written all over it... ;-) The default shared objects on sparc boxes tend to be 32-bit objects, so the sparcv9 postfix is needed to explicitly select the 64-bit shared objects. None of that is needed for ia64. Branden Did the IA-64 toolchain in unstable recently change to Branden define the _LP64 symbol? It appears to be a gcc-3.2 feature: gcc-2.96 defines __LP64__ and gcc-3.2 adds _LP64 on top of that. --david
