From: Len Brown <[email protected]>
Subject: [PATCH] Revert "x86/pci: remove rounding quirk from e820_setup_gap()"
This reverts commit 5d423ccd7ba4285f1084e91b26805e1d0ae978ed.
because it caused multiple regressions in 2.6.31-rc1
http://bugzilla.kernel.org/show_bug.cgi?id=13940
Signed-off-by: Len Brown <[email protected]>
---
Yinghai,
is there a reason we should not revert the offending patch, per below?
thanks,
-Len
arch/x86/kernel/e820.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 85419bb..b322e30 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -617,7 +617,7 @@ __init int e820_search_gap(unsigned long *gapstart, unsigned long *gapsize,
*/
__init void e820_setup_gap(void)
{
- unsigned long gapstart, gapsize;
+ unsigned long gapstart, gapsize, round;
int found;
gapstart = 0x10000000;
@@ -634,9 +634,14 @@ __init void e820_setup_gap(void)
#endif
/*
- * e820_reserve_resources_late protect stolen RAM already
+ * See how much we want to round up: start off with
+ * rounding to the next 1MB area.
*/
- pci_mem_start = gapstart;
+ round = 0x100000;
+ while ((gapsize >> 4) > round)
+ round += round;
+ /* Fun with two's complement */
+ pci_mem_start = (gapstart + round) & -round;
printk(KERN_INFO
"Allocating PCI resources starting at %lx (gap: %lx:%lx)\n",
--
1.6.5.rc2.17.gdbc1b
Len Brown wrote:
> From: Len Brown <[email protected]>
> Subject: [PATCH] Revert "x86/pci: remove rounding quirk from e820_setup_gap()"
>
> This reverts commit 5d423ccd7ba4285f1084e91b26805e1d0ae978ed.
>
> because it caused multiple regressions in 2.6.31-rc1
>
> http://bugzilla.kernel.org/show_bug.cgi?id=13940
>
> Signed-off-by: Len Brown <[email protected]>
> ---
>
> Yinghai,
> is there a reason we should not revert the offending patch, per below?
that patch is introduced fix another bug to get enough resource.
and that patch looks like reveal some bug in ACPI (?) because when
apci subsystem is enabled,
some BARs of some pci devices get cleared somehow.
actually there is patch that could workaround the problem too
---
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;
}
#define MAX_RESOURCE_SIZE ((resource_size_t)-1)
but Linus wants to know why those BARs get cleared, and who is using
that extra 32M.
It seems some guys request acpidump from the reporter, and not sure
what is the result from their checking.
or need the reporter to boot with acpi.debug_layer=0x400000
acpi.debug_level=0x04000807
to pull out more result?
YH