On Thu, 4 Sep 2008, Yinghai Lu wrote:
> >
> > --- x 2008-09-03 21:38:24.000000000 -0700
> > +++ y 2008-09-03 22:29:04.000000000 -0700
> > ...
> > @@ -503,15 +503,15 @@
> > calling init_acpi_pm_clocksource+0x0/0x14a
> > initcall init_acpi_pm_clocksource+0x0/0x14a returned 0 after 32 msecs
> > calling pcibios_assign_resources+0x0/0x70
> > -pci 0000:06:05.0: BAR 9 too large: 0x00000000000000-0x00000003ffffff
> > pci 0000:06:05.0: CardBus bridge, secondary bus 0000:07
> > pci 0000:06:05.0: IO window: 0x002400-0x0024ff
> > pci 0000:06:05.0: IO window: 0x002800-0x0028ff
> > -pci 0000:06:05.0: MEM window: 0x54000000-0x57ffffff
> > +pci 0000:06:05.0: PREFETCH window: 0x50000000-0x53ffffff
> > +pci 0000:06:05.0: MEM window: 0x58000000-0x5bffffff
> > pci 0000:00:1e.0: PCI bridge, secondary bus 0000:06
> > pci 0000:00:1e.0: IO window: 0x2000-0x2fff
> > pci 0000:00:1e.0: MEM window: 0xb0100000-0xb01fffff
> > -pci 0000:00:1e.0: PREFETCH window: disabled
> > +pci 0000:00:1e.0: PREFETCH window: 0x00000050000000-0x00000053ffffff
> > pci 0000:00:1e.0: setting latency timer to 64
> > pci 0000:06:05.0: power state changed by ACPI to D0
>
> 06:05.0 is under 00:1e.0
Right. This is the depth-first bus assignment, so what happens is that
pci_assign_unassigned_resources() does:
/* Depth first, calculate sizes and alignments of all
subordinate buses. */
list_for_each_entry(bus, &pci_root_buses, node) {
pci_bus_size_bridges(bus);
}
where pci_bus_size_bridges() does depth-first (and _has_ to, of course,
since it needs to look at the inner bridges in order to be able to size
the outer ones!)
And there it will now successfully see that BAR 9 that used to get
ignored, so now it sizes the PCI bridge that leads _to_ the Cardbus bridge
with that in mind. So that is why the "BAR 9 too large" message has gone
away, but that is all that got printed out at the resource _sizing_ stage.
And then, after all the sizing has been done, the odd ordering of the
printout is because we next do:
/* Depth last, allocate resources and update the hardware. */
list_for_each_entry(bus, &pci_root_buses, node) {
pci_bus_assign_resources(bus);
pci_enable_bridges(bus);
}
and that "Depth last" comment is a bit mis-leading.
It is true that "pci_bus_assign_resources()" will make the actual call to
"pbus_assign_resources_sorted()" depth-last, but if you look at how it
then actually writes those assigned resources to the actual bridge
devices, it will do those "pci_setup_bridge/cardbus()" calls depth-first:
if you look at pci_bus_assign_resources(), you'll see that it does the
recursive call for the subordinate bus _before_ it sets up the upper
bridge.
And since the _printout_ comes when the final setup is done, that means
that the Cardbus bridge (that is deeper in the resource chain) will print
out first. So even though the resource was _allocated_ depth-last, it is
written out depth-first!
> wonder if some pci code change cause that.... doesn't get pref mem assigned.
>
> can you apply attached patches to get more dump?
It all works fine, and makes sense (well, except for the printout order,
which is a bit non-obvious, but it all boils down to us wanting to have
all the inner bridges set up correctly before we "enable" them through the
outer bridge mapping, so that depth-first makes sense, I think).
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
