Hi,
Kernel 2.4.0-test12-pre7
There appears to be a possibility whereby the root resources (ioport_resource
and iomem_resource) can get modified by the PCI code:
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 1: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: Fast back to back transfers enabled
ioport: 00000000 - 0000ffff
ioport0: 00001000 - 0000ffff
ioport1: 00001000 - 0000ffff
PCI: Bus 1, bridge: Digital Equipment Corporation DECchip 21152
IO window: 0000-0fff
MEM window: 00000000-000fffff
ioport2: 00001000 - 00001fff
ioport: 00001000 - 00001fff
So now the PCI IO resource contains 0x1000 to 0x1fff. Unfortunately,
the PCI devices on the root bus are allocated to IO ports 0x4000 and
up.
This means that drivers are unable to request their resources:
Linux Tulip driver version 0.9.11 (November 3, 2000)
conflict: 1000-1fff: PCI IO (100)
tulip: eth0: I/O region (0x80@0x4400) unavailable, aborting
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.35 $ 2000/11/17 Modified by Andrey V. Savochkin <[email protected]> and others
conflict: 1000-1fff: PCI IO (100)
eepro100: cannot reserve I/O ports
It appears to be caused by the pci_read_bridge_bases code copying the
pointer to the resources instead of making a copy of the resources
themselves.
I'm not sure what the correct fix is here (there have been some recent
changes in this area, but I'll hack around it for now).
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [email protected] --- ---
| | | | http://www.arm.linux.org.uk/personal/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
On Thu, Dec 07, 2000 at 10:46:08PM +0000, Russell King wrote:
> It appears to be caused by the pci_read_bridge_bases code copying the
> pointer to the resources instead of making a copy of the resources
> themselves.
No, pci_read_bridge_bases() is obsoleted by new pci setup code. ;-)
You have to set up bus resources properly in pcibios_fixup_bus().
For a single root bus configuration, you don't need to do anything
with the root bus itself - its resources already point to ioport_resource
and iomem_resource, which should be ok. For pci-pci bridges you have
to add something like this:
struct pci_dev *bridge = bus->self;
if (bridge) {
int i;
for(i=0; i<3; i++) {
bus->resource[i] =
&bridge->resource[PCI_BRIDGE_RESOURCES+i];
bus->resource[i]->name = bus->name;
}
bus->resource[0]->flags = pci_bridge_check_io(bridge);
bus->resource[1]->flags = IORESOURCE_MEM;
bus->resource[0]->end = ioport_resource.end;
bus->resource[1]->end = iomem_resource.end;
/* Turn off downstream PF memory address range by default */
bus->resource[2]->start = 1024*1024;
bus->resource[2]->end = bus->resource[2]->start - 1;
}
Check arch/alpha/kernel/pci.c:pcibios_fixup_bus() for reference.
Ivan.
>
>No, pci_read_bridge_bases() is obsoleted by new pci setup code. ;-)
>You have to set up bus resources properly in pcibios_fixup_bus().
>For a single root bus configuration, you don't need to do anything
>with the root bus itself - its resources already point to ioport_resource
>and iomem_resource, which should be ok. For pci-pci bridges you have
>to add something like this:
The problem I have (and this is why I don't setup host resources
properly on multi-host PPCs yet) is that some hosts can have several
non-contiguous ranges (especially with memory, IO is usually a single
contiguous range).
There are simply not enough resource "slots" in the current structures
to handle all possibles cases.
They basically have a host bridge register in which each low bit enables
decoding of a 256Mb region in the range 0xn0000000 and each high bit
enable decoding of a 16Mb region in the range 0xFn000000
The typical setup is to have one (or more) 256Mb regions, and one 16Mb
region, but that can change from model to model.
Ben
On Fri, Dec 08, 2000 at 03:31:08PM +0100, Benjamin Herrenschmidt wrote:
> The problem I have (and this is why I don't setup host resources
> properly on multi-host PPCs yet) is that some hosts can have several
> non-contiguous ranges (especially with memory, IO is usually a single
> contiguous range).
What about creating dummy resources covering "holes" between those
ranges and claiming them on the parent bus? Resource allocation code
will put everything in the right places in this case.
Ivan.