On 25. okt. 2011 19:33, Steffen Persvold wrote: > On 10/25/2011 19:15, Bjorn Helgaas wrote: >> NumaChip sounds like an exception because you know you never care >> about using those BARs. But I'm curious -- it looks like Linux didn't >> even try to assign resources to them. I thought something in the >> pci_assign_unassigned_resources() path would have tried to do >> something with them. If we *did* assign resources to those BARs, I >> assume nothing would break, since there's no driver that actually uses >> them. Right? >> > > Correct, the BARs are there and if something sensible were written to > them (and MemorySpace was enabled in the Command register) NumaChip > *would* respond to mmio accesses to that address range. A minor point: adjusting the BARs would not strictly speaking be sufficient for the NumaChip to respond, as it would never see these accesses unless the [MMIO address range]->[HyperTransport node/link] registers of the CPU NorthBridges were also updated with the relevant ranges. This is a bit messy, but in a way much the same issue as when secondary southbridges are connected to secondary CPUs in any other HyperTransport-based system. Perhaps an alternative to this NumaChip-specific quirk would be to special-case BARs belonging to "PCI" devices 00:18 - 00:1f in AMD Opteron systems. These always indicate coherent HT devices and fiddling with the CPU NB maps are going to be required if anything is changed regarding the BAR assignments here. -- Arne. -- 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
