From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 30 15:18:25 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B10E216A41F for ; Wed, 30 Nov 2005 15:18:25 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91B8443D46 for ; Wed, 30 Nov 2005 15:18:24 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 2875331 for multiple; Wed, 30 Nov 2005 10:16:19 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jAUFIE8u081326; Wed, 30 Nov 2005 10:18:15 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Wed, 30 Nov 2005 10:18:23 -0500 User-Agent: KMail/1.8.2 References: <20051127010724.GA1161@Grumpy.DynDNS.org> <7689ADE7-14BF-42C8-A3BD-B10E514799B3@FreeBSD.org> <438D6CE4.8010907@root.org> In-Reply-To: <438D6CE4.8010907@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511301018.24822.jhb@freebsd.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: David Kelly Subject: Re: Worked in RELENG_5, fails in RELENG_6 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2005 15:18:25 -0000 On Wednesday 30 November 2005 04:12 am, Nate Lawson wrote: > John Baldwin wrote: > > On Nov 29, 2005, at 10:50 PM, David Kelly wrote: > >> On Nov 29, 2005, at 5:10 PM, Alex Zbyslaw wrote: > >>> David Kelly wrote: > >>>> Could I > >>>> boot a 5.4 CDROM to test ACPI? > >>> > >>> Yes you could. I did this the other day on a machine that doesn't > >>> even have a disk yet ;-) acpidump is there. Select fixit then live > >>> file system (if memory serves) but you probably knew that ! > >> > >> Problem solved, but I've been working on it too hard not to share the > >> story which might be useful: > >> > >> Without hw.physmem="2G" its now finding the full memory load so I > >> don't know what was happening previously. > > > > Actually, this is the second report I've had that setting hw.physmem > > interacts badly with ACPI. The other report I had resulted in a kernel > > panic if it was set to 3G. > > I suspect mapping the memory to read the FACS is failing for the > hw.physmem case. His machine probably has tables at 2G (highmem). A > common location (other than < 1MB) is top of memory minus 16 MB. I > don't know what setting hw.physmem actually does -- does it change how > we can map high memory? Well, it can override what the SMAP tells us such that we can extend the last SMAP entry: /* * Maxmem isn't the "maximum memory", it's one larger than the * highest page of the physical address space. It should be * called something like "Maxphyspage". We may adjust this * based on ``hw.physmem'' and the results of the memory test. */ Maxmem = atop(physmap[physmap_idx + 1]); #ifdef MAXMEM Maxmem = MAXMEM / 4; #endif if (TUNABLE_ULONG_FETCH("hw.physmem", &physmem_tunable)) Maxmem = atop(physmem_tunable); if (atop(physmap[physmap_idx + 1]) != Maxmem && (boothowto & RB_VERBOSE)) printf("Physical memory use set to %ldK\n", Maxmem * 4); /* * If Maxmem has been increased beyond what the system has detected, * extend the last memory segment to the new limit. */ if (atop(physmap[physmap_idx + 1]) < Maxmem) physmap[physmap_idx + 1] = ptoa((vm_paddr_t)Maxmem); This would force the memory up to 2g to be included as pages and I think we zero out pages to test them before adding them to the VM. Extending Maxmem might have forced the pages holding his ACPI tables to be added to the valid pages resulting in those pages being overwritten. David, can you use a serial console to grab a boot -v output that includes the SMAP output? Also, the boot -v output might also provide the PA of FACS (or maybe acpidump -t would have that?) which would also be useful. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org