All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: franck.bui-huu@innova-card.com
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] bootmem.c clean up bad pfn convertions
Date: Fri, 08 Apr 2005 16:52:39 -0700	[thread overview]
Message-ID: <1113004359.16633.6.camel@localhost> (raw)
In-Reply-To: <425687DB.4000205@innova-card.com>

On Fri, 2005-04-08 at 15:32 +0200, Franck Bui-Huu wrote:
> As I described in my previous email, bootmem.c does improper
> pfn convertions into phys addr. This simple patch fixes that.
...
> -       bdata->node_bootmem_map = phys_to_virt(mapstart << PAGE_SHIFT);
> -       bdata->node_boot_start = (start << PAGE_SHIFT);
> +       bdata->node_bootmem_map = phys_to_virt(pfn_to_phys(mapstart));
> +       bdata->node_boot_start = pfn_to_phys(start);

The only arch with phys_to_pfn() defined is UML, so the patch simply
won't compile anything but UML on current kernels (unless I'm missing
something).

Could you try to give us a more complete description of your problem?  I
know your memory doesn't start at 0x0, but what problems does that
cause?  Does the mem_map[] allocation blow up, etc...  

If it's just mem_map[], That calculation could be fixed pretty easily.
Something like

+#ifdef CONFIG_CRAZY_MIPS_FOO_MEM_MAP_START... 
+extern unsigned long mem_map_start_pfn
+#else
+#define mem_map_start_pfn 0UL
+#endif
-#define pfn_to_page(pfn)        (mem_map + (pfn))
+#define pfn_to_page(pfn)        (mem_map + (pfn) - mem_map_start_pfn)

(those names are horrid, please improve them, if you plan to do this)

All of the zone (and allocator) calculations should be just fine,
because it already has a zone_start_pfn.

-- Dave


  reply	other threads:[~2005-04-08 23:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-08 13:32 [PATCH] bootmem.c clean up bad pfn convertions Franck Bui-Huu
2005-04-08 23:52 ` Dave Hansen [this message]
2005-04-11  8:22   ` Franck Bui-Huu

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=1113004359.16633.6.camel@localhost \
    --to=haveblue@us.ibm.com \
    --cc=franck.bui-huu@innova-card.com \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.