All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Moore <tmoore@spatial.ca>
To: Bodo Eggert <7eggert@gmx.de>, linux-kernel@vger.kernel.org
Cc: andi@firstfloor.org
Subject: Re: [RFC][PATCH] Re: 4Gb ram not showing up
Date: Thu, 07 Jun 2007 09:49:06 -0400	[thread overview]
Message-ID: <46680CD2.1000007@spatial.ca> (raw)
In-Reply-To: <Pine.LNX.4.58.0706061356310.2657@be1.lrz>

This looks like it would have probably given me the hint I needed.  Can 
I also suggest that you make a change to arch/i386/kernel/setup.c, line 296:

                if (max_pfn > MAX_NONPAE_PFN) {
                        max_pfn = MAX_NONPAE_PFN;
                        printk(KERN_WARNING "Warning only 4GB will be 
used.\n");
-                        printk(KERN_WARNING "Use a PAE enabled kernel.\n");
+                        printk(KERN_WARNING "Use a PAE enabled kernel 
by selecting the HIGHMEM64G configuration option.\n");
                }

It does not seem that PAE is a configuration option that is exposed 
through make menuconfig.  How else are people supposed to know that PAE 
is a side effect of CONFIG_HIGHMEM64G unless they know the kbuild logic?

Tom

Bodo Eggert wrote:
> Change the description of CONFIG_*HIGHMEM* to reflect "lost" memory due to 
> PCI space and the existence of the NX flag.
>
> Signed-Off-By: Bodo Eggert <7eggert@gmx.de>
> ---
> I made this quick patch using the information from LKML as I remembered 
> it. Please verify.
>
> --- 2.6.21/arch/i386/Kconfig.ori	2007-06-06 13:41:09.000000000 +0200
> +++ 2.6.21/arch/i386/Kconfig	2007-06-06 14:07:40.000000000 +0200
> @@ -495,8 +495,8 @@ config NOHIGHMEM
>  	bool "off"
>  	depends on !X86_NUMAQ
>  	---help---
> -	  Linux can use up to 64 Gigabytes of physical memory on x86 systems.
> -	  However, the address space of 32-bit x86 processors is only 4
> +	  Linux can use up to 64 Gigabytes of physical address space on x86
> +	  systems. However, the address space of 32-bit x86 processors is only 4
>  	  Gigabytes large. That means that, if you have a large amount of
>  	  physical memory, not all of it can be "permanently mapped" by the
>  	  kernel. The physical memory that's not permanently mapped is called
> @@ -510,8 +510,15 @@ config NOHIGHMEM
>  	  by the kernel to permanently map as much physical memory as
>  	  possible.
>  
> -	  If the machine has between 1 and 4 Gigabytes physical RAM, then
> +
> +	  If the machine has between 1 and 3.5 Gigabytes physical RAM, then
>  	  answer "4GB" here.
> +	  
> +	  The PCI address space will usurally take 512 MB or 1 GB of address
> +	  space. This address space is unavailable to RAM, but depending on the
> +	  chipset (and BIOS settings), memory overlapping the PCI address space
> +	  may be mapped beyond the 4 GB limit and be available using "64GB".
> +
>  
>  	  If more than 4 Gigabytes is used then answer "64GB" here. This
>  	  selection turns Intel PAE (Physical Address Extension) mode on.
> @@ -520,6 +527,10 @@ config NOHIGHMEM
>  	  processors (Pentium Pro and better). NOTE: If you say "64GB" here,
>  	  then the kernel will not boot on CPUs that don't support PAE!
>  
> +	  An additional benefit of the 64GB-Mode is the availability of the
> +	  no-execute-pageflag, which can be used to prevent some attacks from
> +	  injecting malicious code into applications.
> +
>  	  The actual amount of total physical memory will either be
>  	  auto detected or can be forced by using a kernel command line option
>  	  such as "mem=256M". (Try "man bootparam" or see the documentation of
> @@ -532,14 +543,14 @@ config HIGHMEM4G
>  	bool "4GB"
>  	depends on !X86_NUMAQ
>  	help
> -	  Select this if you have a 32-bit processor and between 1 and 4
> +	  Select this if you have a 32-bit processor and between 1 and 3.5
>  	  gigabytes of physical RAM.
>  
>  config HIGHMEM64G
> -	bool "64GB"
> +	bool "64GB (enables no-execute memory protection if available)"
>  	depends on X86_CMPXCHG64
>  	help
> -	  Select this if you have a 32-bit processor and more than 4
> +	  Select this if you have a 32-bit processor and more than 3.5
>  	  gigabytes of physical RAM.
>  
>  endchoice
>   


  parent reply	other threads:[~2007-06-07 13:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06 12:12 [RFC][PATCH] Re: 4Gb ram not showing up Bodo Eggert
2007-06-06 14:37 ` Lennart Sorensen
2007-06-06 21:55   ` Wakko Warner
2007-06-06 22:12   ` H. Peter Anvin
2007-06-06 22:41     ` Andrew Lyon
2007-06-07 16:18       ` H. Peter Anvin
2007-06-07 17:37         ` Andrew Lyon
2007-06-09  0:47           ` H. Peter Anvin
2007-06-09 20:38           ` Matt Keenan
2007-06-07 13:49 ` Tom Moore [this message]
     [not found] <fa.KfNZpadRG0eZUXpSEPaw6ru0bsI@ifi.uio.no>
     [not found] ` <fa.onZVzrCKi+mc+cmivZh4BhVROlY@ifi.uio.no>
     [not found]   ` <fa./NQsJ0P5QQw7SMr++Q5kkRcAJHs@ifi.uio.no>
     [not found]     ` <fa.v/tV4BtD9VBbszRCBALGEBt2uUw@ifi.uio.no>
2007-06-07  0:09       ` Robert Hancock

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=46680CD2.1000007@spatial.ca \
    --to=tmoore@spatial.ca \
    --cc=7eggert@gmx.de \
    --cc=andi@firstfloor.org \
    --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.