From owner-freebsd-amd64@FreeBSD.ORG Fri Jul 21 21:15:28 2006 Return-Path: X-Original-To: amd64@freebsd.org Delivered-To: freebsd-amd64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C6D716A4DD; Fri, 21 Jul 2006 21:15:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4596043D46; Fri, 21 Jul 2006 21:15:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k6LLFQKb001253; Fri, 21 Jul 2006 17:15:26 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: acpi@freebsd.org Date: Fri, 21 Jul 2006 17:15:00 -0400 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607211715.00759.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Fri, 21 Jul 2006 17:15:26 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1614/Fri Jul 21 16:27:38 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: amd64@freebsd.org, njl@freebsd.org Subject: [PATCH] Fix hw.physmem use with ACPI.. X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jul 2006 21:15:28 -0000 Several folks had problems using hw.physmem with ACPI as depending on where the system's ACPI tables were located in physical address space, using the hw.physmem tunable could result in the kernel zero'ing part of the ACPI tables. This resulted from the rather peculiar behavior of the hw.physmem/MAXMEM tunable. A (relatively) long time ago in FreeBSD land, machines did not provide a reliable way of detecting how much memory was installed (and/or FreeBSD didn't reliable detect it). As a result, the MAXMEM/hw.physmem stuff was added with 2 apparent purposes. First off, any memory above that limit was not to be used, so it could cap memory usage. The second purpose is more curious though. If the system had claimed to have less than MAXMEM, the kernel would extend the last memory segment up to MAXMEM. Thus, if your system had 64 MB of RAM but only detected 16, you could use MAXMEM to force it to see all 64 MB. This second feature is what got machines into trouble. Modern machines (such as those with ACPI) all include a BIOS-supplied map of physical memory (known as the SMAP (I think it stands for system map)) that specifies which regions of the physical address space are available RAM, which are reserved for the BIOS or devices, etc. On these systems, we can trust the SMAP, and extending the top of memory can only produce pain (e.g. moving the top of memory up into the area reserved for ACPI tables). All this is to provide the background for the change in this patch. The patch is simple. If we used the SMAP to figure out our memory map, then we turn off the second feature of MAXMEM and just use it to cap the top of memory. Since amd64 always uses the SMAP, the second feature has been axed altogether on that platform. http://www.FreeBSD.org/~jhb/patches/hw.physmem.patch Please test it. Especially if you used to have problems using hw.physmem with ACPI in the past. -- John Baldwin