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 kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
