Hi,
first of all: Thanks for your reply!
On Sat, Sep 08, 2012 at 04:04:41PM +0200, Mark Kettenis wrote:
> > most modern x86 hardware includes more than one PCI root segement.
> > E.g. a hardware that I have here has three PCI root segemnts with bus
> > numbers 0, 0x7f, 0x80 and 0xff respectively. (0x7f and 0xff host the
> > uncore devices of each processor).
>
> Well, machines with multiple host bridges have been around for a
> while. Some of them even pre-date ACPI.
>
> >
> > These segments are already detected by APCI but this information is not
> > used when attaching PCI busses to the mainbus. Below is a patch that
> > should solve the PCI bus detection problem in a robust way.
>
> I hate ACPI! It's full of lies; I don't trust it.
Agreed.
> It is much better
> to detect these additional PCI busses by looking at actual hardware
> registers.
This approach (unfortunately) means that device detection breaks
with each new chipset and I hate that :-)
> So before we go down this path, can you investigate that?
> It seems the bus number for the additional "Uncore" devices of the
> Xeon E5 1600/2600 CPUs is available in config register 0x108 of device
> 0:5:0.
Yes, I already figured that. It works and I can cook a patch if you want.
The patch is not completely straight forward, tough, because the device is
not just a bridge but a multi-purpose devices.
> But I haven't figured how to find the bus number for the
> second socket. Looking at the AML for this machine and determining
> how it detects these additional busses might provide some clues. Feel
> free to send me the acpidump output for this box.
I will send you ACPI data in private. However, the second PCI bus is
simply "hardwired" in DSDT, i.e. there does not seem to be code in ACPI that
would try to detect its presence.
I tend to believe that there is no bridge device that exposes the
second PCI bus.
> > There's a small problem though: Some of the secondary PCI segments
> > can show up as busses behind some kind of host bridge device dowstream
> > of pci bus 0, too. These PCI busses would be attached twice, now. Thus we
> > keep track of attached root segemnents in the ACPI code.
>
> Yup. Since we have code to detect additional host bridges some of
> them may already have been attached. And it would be a good way to
> defend against ACPI lying to us. However, please keep the ACPI hooks
> out of the MI PCI code. It'd be better if you used pci_attach_hook(),
> which lives in arch/pci/pci_machdep.c.
Ok, will do that.
However, there might be a different solution:
We could track attached busses (not just host bridge busses but all busses)
in the pci code (or via MD code and hooks but I think that would be a
generic thing) and do nothing in pciattach if a bus is discovered for
the second time.
With this MD code could use whatever methods it wants to detect otherwise
undiscovered host bridges. Possible methods might be magic numbers, hints
from ACPI or even a linear scan of all possible bus numbers.
Does this sound like a possible solution?
regards Christian
