From owner-freebsd-doc@FreeBSD.ORG Tue Mar 14 21:40:17 2006 Return-Path: X-Original-To: freebsd-doc@hub.freebsd.org Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B509C16A401 for ; Tue, 14 Mar 2006 21:40:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2FCE43D55 for ; Tue, 14 Mar 2006 21:40:16 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k2ELeGEv006384 for ; Tue, 14 Mar 2006 21:40:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k2ELeGrK006383; Tue, 14 Mar 2006 21:40:16 GMT (envelope-from gnats) Resent-Date: Tue, 14 Mar 2006 21:40:16 GMT Resent-Message-Id: <200603142140.k2ELeGrK006383@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Bill Moran Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5446316A41F for ; 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 ; 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" To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: docs/94454: [patch] add FAQ entry for memory probing incorrectly X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bill Moran List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 21:40:17 -0000 >Number: 94454 >Category: docs >Synopsis: [patch] add FAQ entry for memory probing incorrectly >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Tue Mar 14 21:40:16 GMT 2006 >Closed-Date: >Last-Modified: >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 @@ + + Why is &os; finding the wrong amount of memory? + + + + The reason is the difference between physical memory + addresses and virtual addresses. + + 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. + + 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. + + 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. + + 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 + this FAQ entry for + more information. + + 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. + + + What do I do when I have bad blocks on my hard drive? --- faq.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: