LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Balaji Rao <balajirrao@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	jesse.barnes@intel.com, yhlu.kernel@gmail.com, ak@suse.de,
	Yinghai Lu <yinghai.lu@sun.com>
Subject: Re: [PATCH][Regression] x86, 32-bit: trim memory not covered by wb mtrrs - FIX
Date: Thu, 7 Feb 2008 09:02:45 +0100	[thread overview]
Message-ID: <20080207080245.GA28631@elte.hu> (raw)
In-Reply-To: <200802071257.51893.balajirrao@gmail.com>


* Balaji Rao <balajirrao@gmail.com> wrote:

> Hello,
> 
> The following commit caused my X server to stop working.
> 
> commit 99fc8d424bc5d803fe92cad56c068fe64e73747a
> Author: Jesse Barnes <jesse.barnes@intel.com>
> Date:   Wed Jan 30 13:33:18 2008 +0100
> 
>     x86, 32-bit: trim memory not covered by wb mtrrs
> 
> This patch fixes the improper handling of addresses > 4G by 
> mtrr_trim_uncached_memory. This, now brings up X on my system.

thanks. Incidentally this same bug was reported and fixed yesterday, and 
that fix is upstream already. Could you please compare your solution to 
Yinghai Lu's fix below, and send us a patch for any further improvements 
(or cleanups) you might notice in that code? It seems to be almost the 
same fix as yours. (and hopefully it fixes your X problem too)

	Ingo

------------------>
commit 20651af9ac60fd6e31360688ad44861a7d05256a
Author: Yinghai Lu <yinghai.lu@sun.com>
Date:   Wed Feb 6 22:39:45 2008 +0100

    x86: fix mttr trimming
    
    Pavel Emelyanov reported that his networking card did not work
    and bisected it down to:
    
    "
    The commit
    
      093af8d7f0ba3c6be1485973508584ef081e9f93
      x86_32: trim memory by updating e820
    
    broke my e1000 card: on loading driver says that
    
      e1000: probe of 0000:04:03.0 failed with error -5
    
    and the interface doesn't appear.
    "
    
    on a 32-bit kernel, base will overflow when try to do PAGE_SHIFT,
    and highest_addr will always less 4G.
    
    So use pfn instead of address to avoid the overflow when more than
    4g RAM is installed on a 32-bit kernel.
    
    Many thanks to Pavel Emelyanov for reporting and testing it.
    
    Bisected-by: Pavel Emelyanov <xemul@openvz.org>
    Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
    Tested-by: Pavel Emelyanov <xemul@openvz.org>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 1e27b69..b6e136f 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -659,7 +659,7 @@ static __init int amd_special_default_mtrr(void)
  */
 int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
 {
-	unsigned long i, base, size, highest_addr = 0, def, dummy;
+	unsigned long i, base, size, highest_pfn = 0, def, dummy;
 	mtrr_type type;
 	u64 trim_start, trim_size;
 
@@ -682,28 +682,27 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
 		mtrr_if->get(i, &base, &size, &type);
 		if (type != MTRR_TYPE_WRBACK)
 			continue;
-		base <<= PAGE_SHIFT;
-		size <<= PAGE_SHIFT;
-		if (highest_addr < base + size)
-			highest_addr = base + size;
+		if (highest_pfn < base + size)
+			highest_pfn = base + size;
 	}
 
 	/* kvm/qemu doesn't have mtrr set right, don't trim them all */
-	if (!highest_addr) {
+	if (!highest_pfn) {
 		printk(KERN_WARNING "WARNING: strange, CPU MTRRs all blank?\n");
 		WARN_ON(1);
 		return 0;
 	}
 
-	if ((highest_addr >> PAGE_SHIFT) < end_pfn) {
+	if (highest_pfn < end_pfn) {
 		printk(KERN_WARNING "WARNING: BIOS bug: CPU MTRRs don't cover"
-			" all of memory, losing %LdMB of RAM.\n",
-			(((u64)end_pfn << PAGE_SHIFT) - highest_addr) >> 20);
+			" all of memory, losing %luMB of RAM.\n",
+			(end_pfn - highest_pfn) >> (20 - PAGE_SHIFT));
 
 		WARN_ON(1);
 
 		printk(KERN_INFO "update e820 for mtrr\n");
-		trim_start = highest_addr;
+		trim_start = highest_pfn;
+		trim_start <<= PAGE_SHIFT;
 		trim_size = end_pfn;
 		trim_size <<= PAGE_SHIFT;
 		trim_size -= trim_start;

  reply	other threads:[~2008-02-07  8:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-07  7:27 Balaji Rao
2008-02-07  8:02 ` Ingo Molnar [this message]
2008-02-07  8:21   ` Balaji Rao
2008-02-07  8:50     ` Yinghai Lu
2008-02-07  9:04       ` Ingo Molnar
2008-02-07  9:11         ` Yinghai Lu
2008-02-07 10:16           ` Ingo Molnar
2008-02-07 11:35       ` Balaji Rao
2008-02-07  8:56   ` Yinghai Lu
2008-02-07  9:00     ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080207080245.GA28631@elte.hu \
    --to=mingo@elte.hu \
    --cc=ak@suse.de \
    --cc=balajirrao@gmail.com \
    --cc=jesse.barnes@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=yhlu.kernel@gmail.com \
    --cc=yinghai.lu@sun.com \
    --subject='Re: [PATCH][Regression] x86, 32-bit: trim memory not covered by wb mtrrs - FIX' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).