From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 16:12:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51D3716A4D9 for ; Mon, 26 Apr 2004 16:12:16 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3CBA43D1F for ; Mon, 26 Apr 2004 16:12:15 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Apr 2004 19:12:14 -0400 Message-ID: From: Don Bowman To: 'John Kennedy' , freebsd-current@freebsd.org Date: Mon, 26 Apr 2004 19:12:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Any way to limit available memory? [5.2.1-R-p5] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2004 23:12:16 -0000 From: John Kennedy [mailto:jk@jk.homeunix.net] > It looks like one of my Dell boxes has some memory that is > accessible but > shouldn't be. Sort of peculiar in that it: > > 1: Is .2MB in from the upper memory limit, and changes when > available memory changes > 2: Isn't slot or memory-stick dependent > 3: Can lock the machine up solid when you write certain data > patterns to it > 4: Doesn't seem to be OS-dependent (Memtest86 ISO, FreeBSD) > > Between the data corruption (segmentation violations, > mostly), the memory > location (we tend to have problems after the machine has been up and > thrashing for a while) and the symptoms (periodic solid > lockups) it looks > like this may be the smoking gun for some of the problems > we've been seeing > on that machine. > > I'll obviously be pursuing some solutions in the near future (BIOS > upgrades, Dell hardware diagnostics, hard-coding available memory for > operating system, etc). > > For the short term, however, is there some way to get the > system to think > that we have ~1MB less RAM than it actually tests for? This is the SMM [System Management Mode]. Its owned by a special virtual machine. You can set hw.physmem= to restrict access.