On Thu, Jan 28, 2010 at 3:41 PM, Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > I don't see the connection between the commits you identified and > the fact that we don't find any host bridge memory windows. > > The problem I see is that the PNP0A08:00 host bridge has a bunch > of memory resources that are marked as "Consumer," which means the > bridge doesn't forward those regions downstream. It's normal for > a bridge to have a couple things like that, e.g., 0xcf8, which the > bridge consumes and turns into config space accesses downstream, > but most of these are huge regions that are obviously supposed to > be Producer, not Consumer. > > That would certainly explain why the downstream devices don't work, > but it doesn't explain why they worked prior to 2.6.31. We've been > checking that Producer/Consumer bit since 463eb297401e in 2005. > > Are you sure there wasn't a BIOS change at the time things broke? > I guess if you bisected it, there shouldn't be a BIOS change in the > middle, but I just don't see how this could ever have worked with > the _CRS we're getting from the BIOS. > Bjorn, Thanks for the help on this. There was a BIOS change, but I don't think that it is connected to this. I don't have any old boot logs from the old BIOS, but I can definitely build & boot old kernels like 2.6.29 on the new BIOS and see all the devices. One theory for how old kernels managed to work is that when pci_create_bus() is called it initially sets resource[0] to map all possible IO space, and resource[1] to map all MEM space. In the current kernel these get overwritten with the actual windows before we do anything with them. But perhaps in the old kernel (before Willy changed the ordering) we might have accepted by ehci devices while the bus apparently mapped everything? > resource_to_window() ignores consumer-only resources, which explains > why we aren't treating these memory descriptors as host bridge windows. I commented out that check in resource_to_window() ... and my system booted with a lot more windows reported, and all the devices working. So a good theory for what is wrong is that the BIOS has all the right windows listed in _CRS, but it just has the wrong flags on some/all of them. But in particular this one: > DWORD addr space descriptor: [mem 0x50000000-0x9fffffff] > >> 8a 2b 00 00 0d 01 ff ff ff 03 00 00 >> 00 00 00 00 00 00 00 01 00 00 fe ff ff ff 00 01 >> 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 >> 00 00 I'll see if I can find the BIOS people for this platform and ask them if they can change the 'd' to a 'c'. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|