Cc: Thomas Meyer <thomas@...>, Ingo Molnar <mingo@...>, Stefan Richter <stefanr@...>, Thomas Gleixner <tglx@...>, Rafael J. Wysocki <rjw@...>, LKML <linux-kernel@...>, Adrian Bunk <bunk@...>, Andrew Morton <akpm@...>, Natalie Protasevich <protasnb@...>, Benjamin Herrenschmidt <benh@...>, Gary Hade <garyhade@...>
On Tue, Mar 25, 2008 at 02:47:35PM -0700, Linus Torvalds wrote:
Note that 'Memory at 100000000' is totally bogus as this is 32-bit BAR
and respective PCI bridge is 32-bit either.
Most interesting thing is that under 2.6.24 Tomas had
PCI: Bridge: 0000:00:1e.0
IO window: disabled.
MEM window: 8c000000-8c0fffff
PREFETCH window: disabled.
but with 2.6.25
PCI: Bridge: 0000:00:1e.0
IO window: disabled.
MEM window: 0x00000000-0x000fffff
PREFETCH window: disabled.
I'm sure that MEM window was actually 0x100000000-0x1000fffff as that
printk shows only 8 hex digits.
Yeah, it's resource issue for sure. The 00:1e.0 is a transparent bridge,
so I blame commit 8fa5913d54f3b1e09948e6a0db34da887e05ff1f
(PCI: remove transparent bridge sizing). It's wrong for two reasons:
- we cannot ignore standard windows of a transparent bridge as they
always positive decode, so they are potential source of address conflicts;
- that patch just broke whole bridge setup logic in unpredictable way.
What confused me a lot initially is that the patch was already there
in 2.6.24. But I think that issue was somehow masked by 'unsigned
longs' used in setup-bus.c all over the place instead of resource_size_t,
which has been fixed by Ben in 2.6.25...
I think that's why Thomas has everything working again without
CONFIG_RESOURCES_64BIT.
Thomas, can you put CONFIG_RESOURCES_64BIT=y back and either
revert commit 8fa5913d54f3b1e09948e6a0db34da887e05ff1f, or
just comment out these two lines in drivers/pci/setup-bus.c:
if (bus->self->transparent)
break;
and check if it helps?
Ivan.
--
