From wmoran@collaborativefusion.com  Tue Mar 14 21:34:55 2006
Return-Path: <wmoran@collaborativefusion.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5446316A41F
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 14 Mar 2006 21:34:55 +0000 (UTC)
	(envelope-from wmoran@collaborativefusion.com)
Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199])
	by mx1.FreeBSD.org (Postfix) with ESMTP id DC9AA43D48
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 14 Mar 2006 21:34:54 +0000 (GMT)
	(envelope-from wmoran@collaborativefusion.com)
Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61])
  by wingspan with esmtp; Tue, 14 Mar 2006 16:34:54 -0500
  id 00056422.441736FE.0000B8A4
Received: by vanquish.pgh.priv.collaborativefusion.com (sSMTP sendmail emulation); Tue, 14 Mar 2006 16:34:54 -0500
Message-Id: <20060314213454.DC9AA43D48@mx1.FreeBSD.org>
Date: Tue, 14 Mar 2006 16:34:54 -0500
From: "Bill Moran" <wmoran@collaborativefusion.com>
Reply-To: Bill Moran <wmoran@collaborativefusion.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [patch] add FAQ entry for memory probing incorrectly
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         94454
>Category:       docs
>Synopsis:       [patch] add FAQ entry for memory probing incorrectly
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    keramida
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 14 21:40:16 GMT 2006
>Closed-Date:    Wed May 10 19:04:24 GMT 2006
>Last-Modified:  Wed May 10 19:04:24 GMT 2006
>Originator:     Bill Moran
>Release:        FreeBSD 6.0-RELEASE-p5 i386
>Organization:
Collaborative Fusion Inc.
>Environment:
System: FreeBSD vanquish.pgh.priv.collaborativefusion.com 6.0-RELEASE-p5 FreeBSD 6.0-RELEASE-p5 #2: Thu Mar 2 10:57:03 EST 2006 root@vanquish.pgh.priv.collaborativefusion.com:/usr/obj/usr/src/sys/VANQUISH i386


	
>Description:
	non PAE kernel probes 3.5G RAM when there is 4G
        PAE kernel (or 64 bit kernel) probes 4.5G when there is 4G
	By the response from the amd64 mailing list, this deserves to be
        in the FAQ.
>How-To-Repeat:
	boot some different kernels on a machine with 4G of RAM
>Fix:

This is the source material I used:
http://lists.freebsd.org/pipermail/freebsd-amd64/2005-August/005849.html

--- faq.diff begins here ---
--- book.sgml.old	Tue Mar 14 16:28:40 2006
+++ book.sgml	Tue Mar 14 16:27:34 2006
@@ -2871,6 +2871,45 @@
 
     <qandaset>
       <qandaentry>
+        <question id="pae">
+          <para>Why is &os; finding the wrong amount of memory?</para>
+        </question>
+
+        <answer>
+          <para>The reason is the difference between physical memory
+            addresses and virtual addresses.</para>
+
+          <para>The convention for most PC hardware is to use memory
+            between 3.5G and 4G for special use (usually for PCI).
+            This is physical memory address space that is used to access
+            the PCI hardware.  As a result real memory (RAM) can not
+            exist there.</para>
+
+          <para>What happens to the memory that should appear in that
+            location is dependent on your hardware.  Unfortunately,
+            some hardware does nothing and the ability to use that
+            last 500M of RAM is lost.</para>
+
+          <para>Luckily, most hardware remaps the memory to a higher
+            location so that it can still be used.  However, this can
+            cause some confusion if you watch the boot messages.</para>
+
+          <para>On a 32 bit version of &os;, the memory appears lost,
+            since it will be remapped above 4G, which a 32 bit kernel
+            is unable to access.  In this case, the solution is to
+            build a PAE enabled kernel.  See
+            <link linkend="memory-limits">this FAQ entry</link> for
+            more information.</para>
+            
+          <para>On a 64 bit version of &os;, or when running a PAE-enabled
+            kernel, &os; will correctly detect and remap the memory so
+            it is usable.  During boot, however, it may seem as if &os;
+            is detecting more memory than the system really has.  This
+            is normal and the available memory will be corrected as the
+            boot process completes.<para>
+        </answer>
+      </qandaentry>
+      <qandaentry>
         <question id="awre">
           <para>What do I do when I have bad blocks on my hard drive?</para>
         </question>
--- faq.diff ends here ---


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: keramida 
State-Changed-When: Wed May 10 19:03:08 UTC 2006 
State-Changed-Why:  
I committed a slightly reworded version, as revision 1.781 
of the FAQ.  Thanks for taking the time to summarize the 
mailing-list posts and SGML'ifying this :) 


Responsible-Changed-From-To: freebsd-doc->keramida 
Responsible-Changed-By: keramida 
Responsible-Changed-When: Wed May 10 19:03:08 UTC 2006 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=94454 
>Unformatted:
