Bjorn Helgaas wrote: > On Sunday 11 October 2009 03:17:16 pm Yinghai Lu wrote: >> for >> >> http://bugzilla.kernel.org/show_bug.cgi?id=13940 >> >> some system when acpi are enabled, acpi clears some BAR for some devices without >> reason, and kernel will need to allocate devices for them. > > "ACPI clears some BARs"? I'm dubious. The handoff state is the same > whether we boot with "acpi=off" or not, so the BIOS can't be clearing > them. I really don't think the ACPI code in Linux clears BARs. The > Linux PCI code might be clearing BARs, but it sure would be nice to > know exactly why. Did you ever figure that out? please check the mail is reponsed to Ingo. > >> try to increase alignment to get more safe range for unassigned devices. >> >> Signed-off-by: Yinghai Lu <yinghai@xxxxxxxxxx> >> >> --- >> arch/x86/kernel/e820.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> Index: linux-2.6/arch/x86/kernel/e820.c >> =================================================================== >> --- linux-2.6.orig/arch/x86/kernel/e820.c >> +++ linux-2.6/arch/x86/kernel/e820.c >> @@ -1378,8 +1378,8 @@ static unsigned long ram_alignment(resou >> if (mb < 16) >> return 1024*1024; >> >> - /* To 32MB for anything above that */ >> - return 32*1024*1024; >> + /* To 64MB for anything above that */ >> + return 64*1024*1024; > > How do we know 64MB is the correct alignment? > > This feels like a hack that accidentally covers up the problem. I > don't think we understand what's happening well enough. yes, we need to figure out why when acpi=on, those BAR are cleared, before pci code try to scan and read BAR. (node early pic print out untouched, but after APCI subsystem is enabled, those BAR got clearred) YH -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
