On Wed, Jun 01, 2011 at 02:10:56AM +0100, Ben Hutchings wrote:
> On Tue, 2011-05-31 at 17:51 -0700, Yinghai Lu wrote:
> > On 05/31/2011 03:52 PM, Ben Hutchings wrote:
> > > Following commit da7822e5ad71ec9b745b412639f1e5e0ba795a20 ('PCI: update
> > > bridge resources to get more big ranges when allocating space (again)'),
> > > SFC9000-family network controllers in a Dell PE R905 are getting their
> > > memory BARs disabled.
> > >
> > > These devices have:
> > > BAR 0: I/O, 256 bytes
> > > BAR 2: memory, 64-bit, 16 MB (for general registers)
> > > BAR 4: memory, 64-bit, 64 KB (for MSI-X tables)
> [...]
> > > pci 0000:0c:00.1: address space collision: [mem 0xec000000-0xec01ffff pref] conflicts with 0000:0c:00.0 [mem 0xec000000-0xec01ffff pref]
> > > pci 0000:21:00.1: address space collision: [mem 0xd5000000-0xd501ffff pref] conflicts with 0000:21:00.0 [mem 0xd5000000-0xd501ffff pref]
> >
> > your system is 4 sockets AMD quad cores system.
> > two peer root bus: one to cpu 0, and one to cpu 3.
> >
> > 1. BIOS does assign same resource to func0 and func1.
>
> Only for the expansion ROM BARs, which never need to be mapped at the
> same time. Previous kernel versions do fix this up, though. Would you
> like a log of the previous behaviour?
>
> > 2. BIOS does not assign resource to SR-IOV BAR...
>
> Right, sorry I forgot to mention the SR-IOV BAR. The current
> configuration for these devices has SR-IOV functionality disabled in the
> firmware, but unfortunately the PCIe core is hardwired to expose the
> capability.
Ben,
Can you send me the output of lspci -vvv -s <your sriov capable device>?
I wonder there might be something in there to indicate that the SRIOV
capability of the device is not fully enabled??
RP
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
