public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox