From owner-freebsd-current@FreeBSD.ORG Mon Apr 26 15:01:13 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 C303016A4CE for ; Mon, 26 Apr 2004 15:01:13 -0700 (PDT) Received: from jk.homeunix.net (dhcp-19-33.dsl.CSUChico.EDU [132.241.19.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5674B43D48 for ; Mon, 26 Apr 2004 15:01:11 -0700 (PDT) (envelope-from jk@jk.homeunix.net) Received: from jk.homeunix.net (localhost [127.0.0.1]) by jk.homeunix.net (8.12.11/8.12.11) with ESMTP id i3QM0wNt015371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Apr 2004 15:00:58 -0700 (PDT) Received: (from warlock@localhost) by jk.homeunix.net (8.12.11/8.12.11/Submit) id i3QM0wpW015370 for freebsd-current@freebsd.org; Mon, 26 Apr 2004 15:00:58 -0700 (PDT) Date: Mon, 26 Apr 2004 15:00:58 -0700 From: John Kennedy To: freebsd-current@freebsd.org Message-ID: <20040426220058.GA14716@memnoch.jk.homeunix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-jk-MailScanner: No infection found X-jk-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.9, required 6, autolearn=not spam, BAYES_00 -4.90) X-jk-MailScanner-From: warlock@jk.homeunix.net Subject: 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 22:01:13 -0000 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?