Bug 2373

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