From owner-freebsd-stable@FreeBSD.ORG Fri Feb 24 00:20:37 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2FF516A422 for ; Fri, 24 Feb 2006 00:20:37 +0000 (GMT) (envelope-from atanas@asd.aplus.net) Received: from pro20.abac.com (pro20.abac.com [66.226.64.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77D9743D45 for ; Fri, 24 Feb 2006 00:20:37 +0000 (GMT) (envelope-from atanas@asd.aplus.net) Received: from [216.55.129.41] (asd0.aplus.net [216.55.129.41]) (authenticated bits=0) by pro20.abac.com (8.13.4/8.13.4) with ESMTP id k1O0KZHF019960 for ; Thu, 23 Feb 2006 16:20:36 -0800 (PST) (envelope-from atanas@asd.aplus.net) Message-ID: <43FE517B.8050704@asd.aplus.net> Date: Thu, 23 Feb 2006 16:21:15 -0800 From: Atanas User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.47 (SPF_SOFTFAIL) Subject: hw.realmem on i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2006 00:20:38 -0000 I'm setting 6.1-BETA2/i386 on a AMD-based (dual Opteron 270) Tyan K8SE S2892 motherboard with 4GB RAM. The PCI memory address range on this board takes entire gigabyte, leaving only 3GB of usable memory in i386 mode. The remaining part gets remapped (by the BIOS) above the 4GB limit. On the Intel server boards the PCI range used to take only 256MB or 512MB, so I could afford ignoring that. But 1GB now seems too much and I decided to compile a PAE enabled kernel and see what happens. The PAE enabled kernel detects the full amount of RAM, boots normally and seems all right so far (not in production yet): # dmesg |grep memory real memory = 5368709120 (5120 MB) avail memory = 4182597632 (3988 MB) # memcontrol list ... 0x0/0x80000000 BIOS write-back set-by-firmware active 0x80000000/0x40000000 BIOS write-back set-by-firmware active 0x100000000/0x40000000 BIOS write-back set-by-firmware active The thing that puzzles me is the sysctl hw.realmem value: # sysctl -a |grep hw.*mem: hw.physmem: 4286291968 hw.usermem: 4106076160 hw.realmem: 1073741824 Wasn't this supposed to be greater that both hw.physmem and hw.usermem? Or at least this is what I see on all other (non-PAE) boxes I have: realmem > physmem > usermem Here are a few examples: Intel SE7501WV2, 4GB (-256MB), non-PAE i386: hw.physmem: 4017508352 hw.usermem: 3792785408 hw.realmem: 4026466304 Intel SE7520JR2, 4GB (-512MB), non-PAE i386: hw.physmem: 3749007360 hw.usermem: 3285360640 hw.realmem: 3757965312 AMD-based, 4GB, amd64: hw.physmem: 4218327040 hw.usermem: 3933339648 hw.realmem: 4227792896 I'm wondering what impact such a supposedly incorrect hw.realmem < hw.physmem value could have, and whether the kernel options would need to be tweaked manually in order to fix that. I remember a case when I had to upgrade a 4.x based box from 2GB to 4GB, so vm.kvm_free became larger than vm.kvm_size resulting in random crashes (until I realized that I had to manually adjusting the KVA_PAGES kernel option, but it does not seems to be much relevant here). I'm running 6.1-PRERELEASE (6-STABLE) from Feb 22 2005 with the following mods to the kernel configuration files: GENERIC: < cpu I486_CPU < options INET6 # IPv6 communications protocols < options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI > options QUOTA > options SMP # Symmetric MultiProcessor Kernel PAE: > options IPFIREWALL > options DUMMYNET Regards, Atanas