Hello guys,
How does the enumeration decide if the devices in 8111/8131 are on bus 0 or other bus ? Isn't that all these non-coherent devices are on PCIDEV(0,0,0), at power up ? How are they changed to their "real" PCIDEVFN ?
We are having problems on ibm/e325 that these devices remain on bus 0 such that the current HT and PCI scan or resource allocation is totally fucked. The devices are on bus 0 device 1 or something, these devices are enumerated first than the northbridge so the northbridge does not get correct information about its "link" and can not set IO/MEM/BUS routing correctly (actually it refuse to set at all).
Does anyone can help on this ?
Ollie
Li-Ta Lo ollie@lanl.gov writes:
Hello guys,
How does the enumeration decide if the devices in 8111/8131 are on bus 0 or other bus ?
In LinuxBIOS only the cpus are on bus 0, at least when we are done.
Isn't that all these non-coherent devices are on PCIDEV(0,0,0), at power up ? How are they changed to their "real" PCIDEVFN ?
Not quite. Their bridge decides their bus number. The just start out at devfn 0 on which ever bus they are assigned.
We do enumerate one of the chains statically before the general resource allocator hits, and I think we leave it at bus 0.
We are having problems on ibm/e325 that these devices remain on bus 0 such that the current HT and PCI scan or resource allocation is totally fucked. The devices are on bus 0 device 1 or something, these devices are enumerated first than the northbridge so the northbridge does not get correct information about its "link" and can not set IO/MEM/BUS routing correctly (actually it refuse to set at all).
You might need to specify the bridges/busses in Config.lb. I know the current code works and can handle this.
Does anyone can help on this ?
Without something like a serial console trace so that the details of what are going on are clear I don't know.
I have a hunch. The default code for setting things up is for pci devices. In the opteron mainboard files we need to specify non-default operations so we do the hypertransport scan. One of the things that does is to put everything back at devfn 0 if they have changed from someplace else.
amdk8_scan_root_bus very deliberately avoids all of the other functions that are not cpus so if you are using it I don't see how you would run into the problem you have described.
Eric
You might need to specify the bridges/busses in Config.lb. I know the current code works and can handle this.
Does anyone can help on this ?
Without something like a serial console trace so that the details of what are going on are clear I don't know.
Please see that attached log. As you ca see the HyperTransport scan is not actually done in northbridge.c:amdk8_scan_chain(). It only prints the message before and after the for loop but skip the loop.
Ollie
I have a hunch. The default code for setting things up is for pci devices. In the opteron mainboard files we need to specify non-default operations so we do the hypertransport scan. One of the things that does is to put everything back at devfn 0 if they have changed from someplace else.
amdk8_scan_root_bus very deliberately avoids all of the other functions that are not cpus so if you are using it I don't see how you would run into the problem you have described.
Eric
Li-Ta Lo ollie@lanl.gov writes:
You might need to specify the bridges/busses in Config.lb. I know the current code works and can handle this.
Does anyone can help on this ?
Without something like a serial console trace so that the details of what are going on are clear I don't know.
Please see that attached log. As you ca see the HyperTransport scan is not actually done in northbridge.c:amdk8_scan_chain(). It only prints the message before and after the for loop but skip the loop.
Please reread my hunch below. It looks like I nailed it on the head. The fact that the first pci_scan_bus shows devices below 0x18 is confirmation of this.
mainboard_operations needs to specify amdk8_scan_root_bus.
I have a hunch. The default code for setting things up is for pci devices. In the opteron mainboard files we need to specify non-default operations so we do the hypertransport scan. One of the things that does is to put everything back at devfn 0 if they have changed from someplace else.
amdk8_scan_root_bus very deliberately avoids all of the other functions that are not cpus so if you are using it I don't see how you would run into the problem you have described.
Eric
On Mon, 2004-04-26 at 11:58, Eric W. Biederman wrote:
Li-Ta Lo ollie@lanl.gov writes:
You might need to specify the bridges/busses in Config.lb. I know the current code works and can handle this.
Does anyone can help on this ?
Without something like a serial console trace so that the details of what are going on are clear I don't know.
Please see that attached log. As you ca see the HyperTransport scan is not actually done in northbridge.c:amdk8_scan_chain(). It only prints the message before and after the for loop but skip the loop.
Please reread my hunch below. It looks like I nailed it on the head. The fact that the first pci_scan_bus shows devices below 0x18 is confirmation of this.
mainboard_operations needs to specify amdk8_scan_root_bus.
What exactly are you talking about ? It is amdk8_scan_root_bus in ibm/e325/mainboard.c.
static struct device_operations mainboard_operations = { .read_resources = root_dev_read_resources, .set_resources = root_dev_set_resources, .enable_resources = enable_childrens_resources, .init = mainboard_init, .scan_bus = amdk8_scan_root_bus, .enable = 0, };
Ollie
Li-Ta Lo ollie@lanl.gov writes:
On Mon, 2004-04-26 at 11:58, Eric W. Biederman wrote:
Li-Ta Lo ollie@lanl.gov writes:
You might need to specify the bridges/busses in Config.lb. I know the current code works and can handle this.
Does anyone can help on this ?
Without something like a serial console trace so that the details of what are going on are clear I don't know.
Please see that attached log. As you ca see the HyperTransport scan is not actually done in northbridge.c:amdk8_scan_chain(). It only prints the message before and after the for loop but skip the loop.
Please reread my hunch below. It looks like I nailed it on the head. The fact that the first pci_scan_bus shows devices below 0x18 is confirmation of this.
mainboard_operations needs to specify amdk8_scan_root_bus.
What exactly are you talking about ? It is amdk8_scan_root_bus in ibm/e325/mainboard.c.
static struct device_operations mainboard_operations = { .read_resources = root_dev_read_resources, .set_resources = root_dev_set_resources, .enable_resources = enable_childrens_resources, .init = mainboard_init, .scan_bus = amdk8_scan_root_bus, .enable = 0, };
Hmm. So it is there.
For some reason it is not being called. A missing chip.h perhaps?
My old copy of that code does: max = pci_scan_bus(&root->link[0], PCI_DEVFN(0x18, 0), 0xff, max);
So it starts at device 0x18 (The first cpu) and works down. That is not happening so that code is not being called.
I don't know why/how it is failing except possibly for fragility in the config tool. But I observe it is not.
Eric
-
ebiederman＠lnxi.com -
Li-Ta Lo