Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

[Yinghai Lu]

On Fri, Aug 29, 2008 at 8:24 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> we need to use insert_resource_split_to_fit instead...
>>
>> otherwise __request_region will not be happy.
>
> Are you really really sure?
>
> Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI
> BAR's to work with the e820 resources, then BUSY really is simply not
> right any more. Not that I think it should matter either..
>
> The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones
> that cover RAM), but the others we now expect to nest with PCI BARs.

not all. some are MMCONF, some are for GART, and some for fixed lapic,
and fixed ioapic, and fixed HPET.

>
> But since we add them after we have parsed the BAR's, I don't even see why
> the BUSY bit should even matter - we've already added the fixed BARs, and
> any newly allocated non-fixed ones shouldn't be allocated in e820 areas
> _regardless_ of whether the BUSY bit is set or not.
>
> So pls explain why it matters?

if we don't add the IORESOURCE_BUSY, why bother to add these entries...

good layout from BIOS, it should only reserve mmio range is not showing in BAR.

for example:
0xdc000000 - 0xdd000000 for GART ( some offset BAR 0x94)
0xdd000000 - 0xde000000 is for bus 0x80
0xde000000 - 0xdf000000 is for bus 0x00
0xe0000000 - 0xf0000000 is for mmconfig ( CPU set it in MSR for amd fam 10h)

if one stupid BIOS set
0xdc000000 - 0x100000000 for reserved.

then when in insert that range late
we should still have set ranges other than range 0xdd000000 - 0xdf000000

also do we need set other leaf range in 0xdd000000 - 0xdf0000000 ?

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/