public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Horms <horms@verge.net.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [Fastboot] [PATCH] saved_max_pfn too small on a specific machine
Date: Wed, 07 Mar 2007 08:24:31 +0000	[thread overview]
Message-ID: <20070307082429.GA29770@verge.net.au> (raw)

On Tue, Mar 06, 2007 at 07:07:32PM +0100, Bernhard Walle wrote:
> Hello,
> 
> I has a problem with the patch "Make saved_max_pfn point to max_pfn of
> entire system":
> 
> On a HP rx8640 system with following memory map, the saved_max_pfn was wrong,
> i.e. there was memory in /proc/iomem marked as "System RAM" but above
> saved_max_pfn. This patch fixes the problem.
> 
> If you have a better solution, please give me some hints. Thanks!

Hi Bernard,

this seems reasonable to me.

Acked-by: Simon Horman <horms@verge.net.au>

Magnus Damm suggested to me that if this change is going to be made,
then the whole chunk may as well be moved up to just after md is
validated. See below:

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

As only md is used to calculate saved_max_pfn it seems reasonable
to move setting saved_max_pfn to imediately after md is validated.
This shouldn't change the logic at all. And it seems to make what is 
going on a little clearer.

As suggested to me by Magnus Damm

Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>

Index: linux-2.6/arch/ia64/kernel/efi.c
=================================--- linux-2.6.orig/arch/ia64/kernel/efi.c	2007-03-07 16:57:00.000000000 +0900
+++ linux-2.6/arch/ia64/kernel/efi.c	2007-03-07 17:00:02.000000000 +0900
@@ -971,6 +971,11 @@
 		if (!is_memory_available(md))
 			continue;
 
+#ifdef CONFIG_CRASH_DUMP
+		/* saved_max_pfn should ignore max_addr= command line arg */
+		if (saved_max_pfn < (efi_md_end(md) >> PAGE_SHIFT))
+			saved_max_pfn = (efi_md_end(md) >> PAGE_SHIFT);
+#endif
 		/*
 		 * Round ends inward to granule boundaries
 		 * Give trimmings to uncached allocator
@@ -1010,11 +1015,6 @@
 		} else
 			ae = efi_md_end(md);
 
-#ifdef CONFIG_CRASH_DUMP
-		/* saved_max_pfn should ignore max_addr= command line arg */
-		if (saved_max_pfn < (efi_md_end(md) >> PAGE_SHIFT))
-			saved_max_pfn = (efi_md_end(md) >> PAGE_SHIFT);
-#endif
 		/* keep within max_addr= and min_addr= command line arg */
 		as = max(as, min_addr);
 		ae = min(ae, max_addr);

             reply	other threads:[~2007-03-07  8:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-07  8:24 Horms [this message]
2007-03-07  9:47 ` [Fastboot] [PATCH] saved_max_pfn too small on a specific machine Bernhard Walle
2007-03-08  0:35 ` Horms
2007-03-08  9:33 ` Bernhard Walle

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=20070307082429.GA29770@verge.net.au \
    --to=horms@verge.net.au \
    --cc=linux-ia64@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox