[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinJhVj7sY6wC1tFRA+rYW72j7GqKvxfRsyRC=Vs@mail.gmail.com>
Date: Thu, 2 Dec 2010 17:19:20 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Bjorn Helgaas <bjorn.helgaas@...com>
Cc: "H. Peter Anvin" <hpa@...or.com>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, Matthew Garrett <mjg@...hat.com>
Subject: Re: [PATCH] x86/PCI: never allocate PCI space from the last 1M below 4G
On Mon, Nov 29, 2010 at 2:04 PM, Bjorn Helgaas <bjorn.helgaas@...com> wrote:
>
> I think we're talking about whether to reserve the top 1MB or top 2MB.
> I freely admit I don't know the right answer. My point is merely that
> since we're using a heuristic anyway, copying Windows is a pretty good
> starting point. In my mind, doing something different requires a
> stronger argument than "it might fix some machines where Windows is
> broken."
What's the status of this? The original patch is pretty nasty, and I
think that hack to put things in the bios_align_resource() function is
just disgusting.
And why is the fix not the really _trivial_ one, which does just this:
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index ca0437c..aef9f77 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -141,7 +141,7 @@ void dma32_reserve_bootmem(void);
/* generic pci stuff */
#include <asm-generic/pci.h>
-#define PCIBIOS_MAX_MEM_32 0xffffffff
+#define PCIBIOS_MAX_MEM_32 0xfff00000
#ifdef CONFIG_NUMA
/* Returns the node based on pci bus */
Hmm?
(Ok, so that doesn't protect a 64-bit resource that just happens to be
inside a window that ends at 0xffffffff, but if you have those kinds
of bus windows, that means that there's nothing there at the 4GB mark
anyway, no?)
Linus
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists