Re: "new" dependencies on ACPI/BIOS

Tony Luck
2010-01-29T02:14:54Z

On Thu, Jan 28, 2010 at 3:41 PM, Bjorn Helgaas <bjorn.helgaas@hp.com> 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