Need to have support for the altix platform running Xorg. I have a patch ready for adding this support which I will post later today for analysis/criticism etc. the basic assumptions we have made are (and probably where contention is most likely) 1. Turning on a DomainSupport for the IA64 platform. 2. Using a legacyIO api that is available only from linux-2.6.11 onwards (failure to find these interfaces makes the Xserver revert to the current code paths) 3. Creating a pciBusAddrToHostAddr function for allowing drivers to examine the /proc/bus/pci interface to convert bus addrs to host addrs to catch the case of machines that do not have all IO mapped in the low 4GB.
Created attachment 1748 [details] [review] the actual patch for the changes that were needed. the actual patch for the changes that were needed.
how will this interact with bug #2368?
bug #2368 seems to address the discovery of the elements of the domain, whereas this patch adds the functionality of what to do with the elements xf86MapDomainIO/Memory and the ia64 functions that are needed to implement the xf86 interface layer. There will probably be sideeffects of one patch on the other, but fundamentally they are orthogonal. It would be nice to see the design goal of 2368.
Do you guys mind if I take this bug? I will review it and integrate it with 2368 (which is not yet complete). I may even have access to an Altrix machine.
I've got a few questions about the patch: 1. The functions xf86GetOSOffsetFromPCI() and xf86GetPciOffsetFromOS() are global although the former is used only in linuxPci.c while the latter one isn't used at all. I would like to move them to this file and make them static. Although it would be preferrable if xf86GetOSOffsetFromPCI() would cache the information someplace (in fact it is already contained in the pciConfigPtr which you can easily get by calling xf86scanpci(). Traversing this may be a lot easier than reading the data from /proc/bus/pci/devices. 2. I don't understand this code at all: static int ia64_port_to_fd(unsigned long port) { return (port >> 24) & 0xffffffff; } void outb(unsigned long port, unsigned char val) { int fd = ia64_port_to_fd(port); ... } Is the file handle calculated from the high byte of the port address? I would expect that libc for this platform contains the proper code for IO handling. Why cant we use these? 3. xf86PostScanAltix(void) I'm not comfortable with this code. We already insert a Host bridge for every bus that doesn't live behind a PCI-PCI bridge. PCI-PCI bridges have certain properties (ie the have a PCI id and a config space, you can set address ranges they allow to pass, or you can route VGA resources down a bridge). Those 'fake' bridges don't have these properties, therefore you don't want to have PCI-PCI bridges there.
> I've got a few questions about the patch: > 1. The functions xf86GetOSOffsetFromPCI() and xf86GetPciOffsetFromOS() > are global although the former is used only in linuxPci.c while the > latter one isn't used at all. I would like to move them to this file > and make them static. > Although it would be preferrable if xf86GetOSOffsetFromPCI() would cache > the information someplace (in fact it is already contained in the pciConfigPtr > which you can easily get by calling xf86scanpci(). Traversing this may be a > lot easier than reading the data from /proc/bus/pci/devices. I think that's fine. It'll speed the code up and make it a little easier to deal with. > 2. I don't understand this code at all: > static int ia64_port_to_fd(unsigned long port) > { > return (port >> 24) & 0xffffffff; > } > > void outb(unsigned long port, unsigned char val) > { > int fd = ia64_port_to_fd(port); > ... > } > Is the file handle calculated from the high byte of the port address? > I would expect that libc for this platform contains the proper code for > IO handling. Why cant we use these? It doesn't actually. I/O port access on sn2 is special so we needed to do it this way. The kernel provides an API in sysfs that this code uses. Each bus has its own legacy_io and memory space that the X server (and other apps that want to do ISA stuff) can use. glibc uses the in/out instructions which don't work on sn2. > 3. xf86PostScanAltix(void) > I'm not comfortable with this code. We already insert a Host bridge for every > bus that doesn't live behind a PCI-PCI bridge. > PCI-PCI bridges have certain properties (ie the have a PCI id and a config > space, you can set address ranges they allow to pass, or you can route VGA > resources down a bridge). Those 'fake' bridges don't have these properties, > therefore you don't want to have PCI-PCI bridges there. I don't know about this one. Shrijeet? Jesse
Reponse to 1. xf86scanpci will fine and caching is good. In the patch I grouped them in lnx_pci as I wanted it globally scoped for linux platforms (makes it easier to have 64/32 DD drivers if all drivers used this translation functions), and also since the other /proc functions lived there. If we move this to a scanpci model, then linuxPci.c does seem a better place. Also, the scanpci model will work, though we have to be careful about ranges (i.e. if we get a map request to a region within a bar or rom block). 2. Jesse's already talked about it. 3. Maybe the class PCI-PCI bridge is wrong, but we were not getting any host bridges when I looked at it. Will need to re-look. On our platform, we needed to insert a bridge since we don't have one at all and I just randomly picked one that worked, since all I wanted to do was make X thing that the card itself is a bridge and make resource requests against the card itself.
> 1. xf86scanpci will fine and caching is good. In the patch I grouped them in > lnx_pci as I wanted it globally scoped for linux platforms (makes it easier to > have 64/32 DD drivers if all drivers used this translation functions), and also > since the other /proc functions lived there. If we move this to a scanpci model, > then linuxPci.c does seem a better place. The current design lets you hook the translation functions into the pciBusFuncs_t structure. From there they are accessable from pciBusAddrToHostAddr() which is globally visible. The graphics drivers should not have to use translation functions at all as they are required to call special mapping functions that put the requested ranges into the processes address space. For other Linux platforms (PPC) there seems to be a different way of determining the translation. I've committed a patch just the other day (please check #325 and #327) in this bugzilla. > Also, the scanpci model will work, though we have to be careful about ranges > (i.e. if we get a map request to a region within a bar or rom block). Right, I've seen this in the code. > 2. Jesse's already talked about it. I would like to convince myself that this works ;-) We need to be careful that it also works with older kernels. > 3. Maybe the class PCI-PCI bridge is wrong, but we were not getting any host > bridges when I looked at it. Will need to re-look. On our platform, we needed > to insert a bridge since we don't have one at all and I just randomly picked one > that worked, since all I wanted to do was make X thing that the card itself > is a bridge and make resource requests against the card itself. This is strange. The code that should handle this is in xfree86/common/xf86pciBus.c:xf86GetPciBridgeInfo(). The first for loop handles all bridges that identify themselves in config space. The second one handles 'orphaned' buses, ie ones that don't have a bridge. It addes a fake bridge. If you can provide the output of 'lspci -vx' I may be able to find out what the problem is.
> The current design lets you hook the translation functions into the > pciBusFuncs_t structure. From there they are accessable from > pciBusAddrToHostAddr() which is globally visible. Hmm .. unless I am reading the patch (#1229) wrong, we are headed for a #define badness right now :-( .. we could break out into provider functions which are instantiated by the platform that we are running on ? You have far more visibility into this issue .. so I will just agree with whatever path you choose :-) >The graphics drivers should > not have to use translation functions at all as they are required to call > special mapping functions that put the requested ranges into the processes > address space. Well here lies the problem .. this would involve drmMap becoming smart and always assuming that the driver will not mmap on it's own. Also making drmMap unconditionally take the incoming address and translate them is a potentially a problem. IMHO, the 2D driver where the knowledge exists about what the address it's dealing with is, and what it wants to do with the address .. is where the translation should be explicitly requested. > 2. I would like to convince myself that this works ;-) > We need to be careful that it also works with older kernels. I have verified that it does no worse on a 2.4 system .. and the code (atleast in intent) will fallback to the old method if it does not detect the new interfaces. > > 3. If you can provide the output of 'lspci -vx' I may be able to find out what the > problem is. This is a small system so I will :-) .. but later I will have to add attachments. 0000:01:01.0 Co-processor: Silicon Graphics, Inc. IOC4 I/O controller (rev 4f) Flags: bus master, 66Mhz, medium devsel, latency 255, IRQ 60 Memory at c00000080f200000 (32-bit, non-prefetchable) 00: a9 10 0a 10 06 00 28 02 4f 00 40 0b 00 ff 00 00 10: 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 3c 01 00 00 0000:01:03.0 Class 0106: Vitesse Semiconductor VSC7174 PCI/PCI-X Serial ATA Host Bus Controller (rev 01) Subsystem: Vitesse Semiconductor VSC7174 PCI/PCI-X Serial ATA Host Bus Controller Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 61 Memory at c00000080f300000 (64-bit, non-prefetchable) Capabilities: [e0] PCI-X non-bridge device. Capabilities: [e8] Power Management version 2 Capabilities: [f0] Message Signalled Interrupts: 64bit+ Queue=0/2 Enable- 00: 25 17 74 71 07 00 b0 02 01 00 06 01 80 40 00 00 10: 04 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 25 17 74 71 30: 00 00 00 00 e0 00 00 00 00 00 00 00 3d 01 10 01 0000:01:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701 Gigabit Ethernet (rev 15) Subsystem: Silicon Graphics, Inc. SGI IO9/IO10 Gigabit Ethernet (Copper) Flags: bus master, 66Mhz, medium devsel, latency 48, IRQ 62 Memory at c00000080f310000 (64-bit, non-prefetchable) Capabilities: [40] PCI-X non-bridge device. Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable- 00: e4 14 45 16 06 00 b0 02 15 00 00 02 20 30 00 00 10: 04 00 31 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 a9 10 10 80 30: 00 00 00 00 40 00 00 00 00 00 00 00 3e 01 40 00 0000:02:01.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Orange Micro Root Hub Flags: bus master, medium devsel, latency 8, IRQ 63 Memory at c00000080fa00000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 00: 33 10 35 00 06 00 10 02 41 10 03 0c 00 08 80 00 10: 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ee 12 00 70 30: 00 00 00 00 40 00 00 00 00 00 00 00 3f 01 01 2a 0000:02:01.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Orange Micro Root Hub Flags: bus master, medium devsel, latency 8, IRQ 64 Memory at c00000080fa01000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 00: 33 10 35 00 06 00 10 02 41 10 03 0c 00 08 00 00 10: 00 10 20 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ee 12 00 70 30: 00 00 00 00 40 00 00 00 00 00 00 00 40 02 01 2a 0000:02:01.2 USB Controller: NEC Corporation USB 2.0 (rev 01) (prog-if 20 [EHCI]) Subsystem: Orange Micro Root hub Flags: bus master, medium devsel, latency 68, IRQ 64 Memory at c00000080fa02000 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 2 00: 33 10 e0 00 06 00 10 02 01 20 03 0c 00 44 00 00 10: 00 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ee 12 01 70 30: 00 00 00 00 40 00 00 00 00 00 00 00 40 03 10 22 0000:02:02.0 Class ff00: Silicon Graphics, Inc.: Unknown device 100f (rev 54) Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 65 Memory at c00000080fa03000 (32-bit, non-prefetchable) 00: a9 10 0f 10 06 00 20 02 54 00 00 ff 00 20 00 00 10: 00 30 20 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 41 01 00 00 0000:17:00.0 VGA compatible controller: ATI Technologies Inc R350 NK [Fire GL X2] (rev 80) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0152 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0, IRQ 67 Memory at c0000041c8000000 (32-bit, prefetchable) [size=c0000041c0120000] I/O ports at c000004023001000 [size=256] Memory at c0000041c0100000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 0000000000020000 [disabled] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 00: 02 10 4b 4e 87 00 b0 02 80 00 00 03 00 00 80 00 10: 08 00 00 08 01 04 00 00 00 00 10 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 52 01 30: 00 00 12 00 58 00 00 00 00 00 00 00 43 01 08 00 0000:17:00.1 Display controller: ATI Technologies Inc: Unknown device 4e6b (rev80) Subsystem: ATI Technologies Inc: Unknown device 0153 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0 Memory at c0000041d0000000 (32-bit, prefetchable) [size=c0000041c0000000] Memory at c0000041c0110000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at <unassigned> Capabilities: [50] Power Management version 2 00: 02 10 6b 4e 87 00 b0 02 80 00 80 03 00 00 00 00 10: 08 00 00 10 00 00 11 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 53 01 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 08 00 0000:1b:00.0 VGA compatible controller: ATI Technologies Inc R350 NK [Fire GL X2] (rev 80) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0152 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0, IRQ 66 Memory at c00000c1c8000000 (32-bit, prefetchable) [size=c00000c1c0120000] I/O ports at c00000c023001000 [size=256] Memory at c00000c1c0100000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 0000000000020000 [disabled] Capabilities: [58] AGP version 3.0 Capabilities: [50] Power Management version 2 00: 02 10 4b 4e 87 00 b0 02 80 00 00 03 00 00 80 00 10: 08 00 00 08 01 04 00 00 00 00 10 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 52 01 30: 00 00 12 00 58 00 00 00 00 00 00 00 42 01 08 00 0000:1b:00.1 Display controller: ATI Technologies Inc: Unknown device 4e6b (rev80) Subsystem: ATI Technologies Inc: Unknown device 0153 Flags: bus master, stepping, 66Mhz, medium devsel, latency 0 Memory at c00000c1d0000000 (32-bit, prefetchable) [size=c00000c1c0000000] Memory at c00000c1c0110000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at <unassigned> Capabilities: [50] Power Management version 2 00: 02 10 6b 4e 87 00 b0 02 80 00 80 03 00 00 00 00 10: 08 00 00 10 00 00 11 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 53 01 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 08 00
>> 2. I would like to convince myself that this works ;-) >> We need to be careful that it also works with older kernels. > I have verified that it does no worse on a 2.4 system .. and the code > (at least in intent) will fallback to the old method if it does not > detect the new interfaces. X11R6.8.2 + this patch doesn't work ("xf86MapDomainIO(): domain out of range") on a secondary card in my zx6000 running 2.6.11-rc1. Could be user error, but X11R6.8.2 *did* work. I'm still trying to figure out how to effectively build/debug this beast, so sorry this has no real details.
That could mean that xf86GetPciDomain() is returning 0 for your device. Shrijeet, how did we get around that on sn2? Thanks, Jesse
> That could mean that xf86GetPciDomain() is returning 0 for your device. Indeed it is. And the device *is* in fact, in PCI domain 0, at least as far as the kernel is concerned, so that makes perfect sense to me: 0000:81:05.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] but domain 0 must mean something different to X. sparcPCI.c also treats domain 0 as an error. I hoped to find a hint in hw/xfree86/Domain.note, but didn't see anything.
So maybe it's time to change that? Seems like domain 0 is ok to me, why should X treat it specially? Jesse
I believe that that is what it does on Altix .. i.e. return 0, will fire it up again today and cross check
The sparc code says: /* * Domain 0 is reserved for the one that represents the system as a whole, i.e. * the one without any resource relocations. */ I don't know right off hand where this is used though.
I'm not even sure what that means... resource relocations for non-domain 0? *Every* resource has to be located somewhere, and usually that's done before the kernel is even loaded, so what's this talk of relocation? At any rate, I don't think Bjorn's code is quite ready yet, but that shouldn't stop us from getting this patch applied right? Bjorn's new stuff can sit on top of it once he's happy with how it's working... Does that sound ok? Jesse
> At any rate, I don't think Bjorn's code is quite ready yet, but that > shouldn't stop us from getting this patch applied right? Did you guys test on non-Altix boxes? On my HP zx6000, the patch breaks a previously-working case. It could be because my kernel has preliminary legacy_io/legacy_mem stuff in it, though. Back to the domain 0 question, clearly Altix doesn't have devices in domain 0: if ((domain <= 0) || (domain >= MAX_DOMAINS)) FatalError("xf86MapDomainIO(): domain out of range\n"); On zx6000, devices are somehow munged into domain 1, but I have no idea where that happens (or more importantly, how to reverse that mapping).
> Did you guys test on non-Altix boxes? On my HP zx6000, the patch > breaks a previously-working case. It could be because my kernel > has preliminary legacy_io/legacy_mem stuff in it, though. No, I don't have any non-sn boxes I can test on easily, so thanks for doing it. :) > Back to the domain 0 question, clearly Altix doesn't have devices > in domain 0: Actually, all devices are in domain 0. > if ((domain <= 0) || (domain >= MAX_DOMAINS)) > FatalError("xf86MapDomainIO(): domain out of range\n"); > > On zx6000, devices are somehow munged into domain 1, but I have > no idea where that happens (or more importantly, how to reverse > that mapping). I think the altix code must do similar munging, but shm wrote that part. I'll see if he's around. Otherwise I'll have to dig through that ugly mess of os dependent X code again :( Jesse
Altix does use domain 0, but the xf86GetPciDomain function always adds 1 to the actual number. int xf86GetPciDomain(PCITAG Tag) { : : return result + 1; /* Domain 0 is reserved */ }
Then we must not be getting that far, I'll bet we hit one of the earlier return 0 statements... meaning that either the linuxPciOpenFile or ioctl failed. I know the ioctl is implemented unconditionally, so it must be the open that failed? Jesse
So any progress Bjorn or Egbert? Should we check this in, then fix up zx1 or wait for Bjorn's patches? Thanks, Jesse
The patch definitely breaks X on HP ia64 boxes. Does it even work on x86 boxes? The problem is that xf86MapDomainIO() has no fallback path to use linuxMapPci() on old kernels that don't supply /sys/.../legacy_io. This is what I suspect will break on every architecture. I'm also concerned that the "encode fd in address" thing is in hw/xfree86/os-support/bus/linuxPci.c, but the in/out changes to extract the fd back out are only in hw/xfree86/os-support/shared/ia64Pci.c. Shouldn't there be similar changes for non-ia64 architectures?
it definitely works on x86, i've been running with this patch included on x86 for several months now.
OK, I see why this patch works on x86 (x86 defines INCLUDE_XF86_NO_DOMAIN, so linuxMapPci() is never used). The ia64 problem remains because even if we make xf86MapDomainIO() fall back to using linuxMapPci(), we can't mmap IO port space on ia64. I guess we ought to be able to make it fall all the way back to something equivalent to what it does today (with INCLUDE_XF86_NO_DOMAIN defined).
Sounds reasonable, that would mean falling back to using the glibc versions of inX/outX rather than the ones that use sysfs.
Just so that I understand this right. The problem case is when we are on an IA64 machine running a pre-2.6.11-pre3 kernel since the sysfs interfaces do not exist. Furthermore if we go the MapDomainIO path, then we are already in trouble as we cannot fallback to the glibc routines (which is what NO_DOMAIN would do). We could further hack this and make the MapDomainIO path work .. but that seems to be a terrible hack. So .. can we go with compiling with NO_DOMAIN for the X releases before 2.6.11 and then switching it off for IA64 after 2.6.11 ?
> The problem case is when we are > on an IA64 machine running a pre-2.6.11-pre3 kernel since the sysfs > interfaces do not exist. Yes. And in fact, it's also a problem on 2.6.11-pre3 kernels on every machine except Altix, since you only implemented the interfaces for Altix (I'm not complaining -- it's decidedly non-trivial to do them for HP zx1). > Furthermore if we go the MapDomainIO path, > then we are already in trouble as we cannot fallback to the glibc > routines (which is what NO_DOMAIN would do). What's the reason we can't fall back to the glibc routines? > So .. can we go with compiling with > NO_DOMAIN for the X releases before 2.6.11 and then switching it off > for IA64 after 2.6.11 ? That sounds to me like a terrible user experience, and probably a major hassle in packaging. I don't see any fundamental reason why we can't fall all the way back to a NO_DOMAIN-style server if the sysfs stuff isn't there. I've been trying to get this to work for several days now, and it doesn't work yet, but I hope that's just because of my ignorance about X internals.
Falling back to the glibc routines should work fine, what trouble are you running into? It may be enough to just use them in the error cases of the ia64_in/out* routines... The compiler.h header file may #undef the normal macros though, so you'd have to use _in* and _out*. Jesse
Created attachment 2425 [details] [review] altix-support-head.patch updated the patch to head, and dropped the pointer fixes to the Radeon driver (which I'll make a new bug for). bjorn, can we apply this and fix zx1 later?
> bjorn, can we apply this and fix zx1 later? I'm opposed to that. That would make altix work, but it would break all other ia64 boxes. I'm glad to work on making zx1 and 460gx work (and indeed am working on it now), but I think it's better to keep the onus on SGI to at least not break other platforms.
Created attachment 2432 [details] [review] work-in-progress for p2p bridges This is incremental to the original altix patch, and is a start at support for devices behind P2P bridges. This isn't enough to make zx1 work, but it'd be useful to know whether this works on altix.
Created attachment 2461 [details] [review] latest legacy I/O patch This is a rollup of Bjorn's p2p code along with an update of the new legacy_io code (w/o all the unrelated stuff). I'm still testing it, but it looks pretty good so far.
Created attachment 2464 [details] [review] legacy I/O patch #6 This one includes fallback to _in/_out routines if xf86MapDomainIO couldn't find the legacy_io files. Bjorn, are you already using something like this? Thanks, Jesse
Comment on attachment 2461 [details] [review] latest legacy I/O patch forgot to mark this one obsolete
Created attachment 2478 [details] [review] legacy I/O patch #7 This one actually works on altix and appears to do the right thing with p2p bridges too (can't be 100% sure since my PROM won't let me POST PCI based devices, but it looks like it's doing everything but that correctly). I haven't tested the fallback code yet though...
Created attachment 2480 [details] [review] legacy I/O patch #8 Oops, last one didn't include the new altix files. This one is the same as #7 but for their addition.
Created attachment 2483 [details] [review] legacy I/O patch #9 This one fixes a bug that Eric Kunze found--lseek after doing the write to enable the rom otherwise we'll skip over the first couple of bytes. Jesse
Created attachment 2498 [details] [review] incremental patch to 2483: legacy I/O patch #9 This incremental diff to attachment 2483 [details] [review] fixes an argument swapping problem in outb/w/l and makes xf86GetPciDomain() return the correct domain for zx1 fake devices. At least, I *think* it's the correct domain, and it works on the single-domain zx1 system I'm testing. I don't know what will happen on multi-domain HP sx1000 systems (which currently don't work anyway). fakeDevice is set only by zx1, so it shouldn't break anybody else. With patch.2483 and this change, things work fine on HP boxes, so I'm ready for it to be checked in. I'm building it on an i2000 (460GX) to test that as well.
Created attachment 2508 [details] [review] legacy-io-9-cumulative.patch the previous two patches rolled up. i'll check this in shortly.
my reading of the code is that i460 and e8870 should follow the same domainless code paths as zx1. so, applied to HEAD, please reopen if this breaks either of those two. thanks all!
Ajax, I'm not at all happy that you committed this. The reason why I have assigned this to me is that I'm still working on integrating it into a lager solution for domain code. No that you have committed this the integration will be more work!
so should i back it out?
Created attachment 2645 [details] [review] e8870-domain-hack-1.patch i received a report today that this broke e8870 machines; xf86GetPciHostConfigFromTag returns NULL for some reason, so xf86GetPciDomain segfaults. attached patch is an ugly workaround that at least gets you to the driver probe. purely on that basis i'm willing to back the altix stuff out for now. egbert, i don't know if that will make your life harder or easier; please let me know.
Created attachment 2673 [details] [review] allow reading option ROM from devices behind a bridge The original code to read the option ROM from sysfs doesn't work if the device is behind a bridge.
*** Bug 3209 has been marked as a duplicate of this bug. ***
Created attachment 3082 [details] Xorg log file Quick temporary fix that clears up the resource ranges awkwardness and the "INVALID MEM ALLOCATION" warning.
Created attachment 2902 [details] [review] Re-attach 3082.
Comment on attachment 2902 [details] [review] Re-attach 3082. Committed.
Created attachment 4983 [details] [review] use /sys/bus/pci/devices/xxx instead of /sys/devices/pcixxx Note: this patch is against the xorg-x11 package in SLES10 Beta 7. But it's pretty trivial and should be easy to apply elsewhere. This is from https://bugzilla.novell.com/show_bug.cgi?id=159234. That's protected, but here's the content: X.org opens the /sys/.../rom and resource files for the VGA device. It uses paths like /sys/devices/pciDDDD:bb/DDDD:bb:dd.f/ (D=domain, b=bus, d=device, f=function). But this doesn't work if the VGA device is behind a bridge, because then the correct path would be /sys/devices/pciDDDD:bb/DDDD:bb:dd.f/DDDD:bb:dd.f/ (it contains the bridge address as well as the VGA device address). It should use /sys/bus/pci/devices/DDDD:bb:dd.f/ instead, which works regardless of whether any bridges are involved. HP MP (management processor) cards have a VGA device and a USB device behind a bridge. These cards are used on mid-range and high-end boxes, where we currently don't support VGA or X at all. VGA routing is disabled by default on these boxes, so we don't even try to start X. But if we turn on VGA routing, we *do* start X, and then we trip over this bug, which leads to an MCA on rx8640. VGA routing is not supported on these boxes yet, so this is not a must-fix for SLES10 as far as HP is concerned. This is obviously arch-independent, but I don't know how common VGA devices behind bridges are. And I don't know the consequences of the bug on other platforms. One possible bad effect is the following: X.org tries to read the option ROM from /sys/.../rom first, and falls back to looking in memory at 0xC0000. If you have multiple VGA devices, only one ROM can live at 0xC0000. So the bug might cause X.org to run an option ROM that doesn't match the card.
Making this bug depend on 6377. Ati Technologies Inc. Also a fellow ATI engineer pointed out that xf86GetOSOffsetFromPCI doesn't handle 64-bit BARs properly.
This patch actually breaks xorg on some sparc64 machines. Reverting it gets it working just fine, probably related to comment #50. My particular case is an ultra 5 with onboard ati, xorg-server 1.1.1, ati driver 6.6.1. For some reason it doesn't seem to affect other ultra 5 machines other people tested on - it may be memory and/or pci layout differences that trigger it. Symptom is usually a corrupted display with a hardlock. 01:02.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) (prog-if 00 [VGA]) Flags: bus master, stepping, medium devsel, latency 64, IRQ 006be7e0 Memory at 1ffe1000000 (32-bit, non-prefetchable) [size=16M] I/O ports at 1fe02c00400 [size=256] Memory at 1ffe2000000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at 1ffe0020000 [disabled] [size=128K]
Ok, think we can close this done since I just checked in the fix for #3914. Bjorn, if your patch still isn't upstream (the one that moves things over to /sys/devices/...) please open another bug for it and we'll get it merged for the next release. Thanks, Jesse
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.