From owner-freebsd-acpi@FreeBSD.ORG Thu Dec 1 17:09:37 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 4EE6416A41F for ; Thu, 1 Dec 2005 17:09:37 +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 A4FC343D58 for ; Thu, 1 Dec 2005 17:09:36 +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 2948486 for multiple; Thu, 01 Dec 2005 12:06:51 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jB1H8dLR090530; Thu, 1 Dec 2005 12:08:44 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Thu, 1 Dec 2005 12:08:05 -0500 User-Agent: KMail/1.8.2 References: <20051127010724.GA1161@Grumpy.DynDNS.org> <8DCC8546-767A-42A4-9A80-A950E1FFEF89@hiwaay.net> <438E7F53.1040001@root.org> In-Reply-To: <438E7F53.1040001@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512011208.06633.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 , freebsd-acpi@freebsd.org 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: Thu, 01 Dec 2005 17:09:37 -0000 On Wednesday 30 November 2005 11:42 pm, Nate Lawson wrote: > David Kelly wrote: > > On Nov 30, 2005, at 9:18 AM, John Baldwin wrote: > >> 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. > > > > Serial console boot -v with working ACPI, attempted to edit ^H's out: > > http://home.hiwaay.net/~dkelly/opus_serialconsole.log > > > > I don't grep SMAP in acpidump output but there was plenty in boot -v > > above: > > > > acpidump -t -d: > > http://home.hiwaay.net/~dkelly/opus_acpidump-t-d.txt > > > > acpidump -t: > > http://home.hiwaay.net/~dkelly/opus_acpidump-t.txt > > > > acpidump -d: > > http://home.hiwaay.net/~dkelly/opus_acpidump-d.txt > > > > And ultimately this is what started it all. Re-enabled hw.physmem and > > captured the boot -v panic via serial console and didn't bother to edit > > the ^H's: > > http://home.hiwaay.net/~dkelly/opus-panic.log > > Even with the user setting hw.physmem, we should only be mapping type 1 > memory values: > > SMAP type=01 base=0000000000000000 len=00000000000a0000 > SMAP type=02 base=00000000000f0000 len=0000000000010000 > SMAP type=01 base=0000000000100000 len=000000007fe74000 > > As you can see, the last part up to 2 GB (> 0x7fe74000) should not be > mapped (and later zeroed). So it seems this bug is apparent. Can you > fix it John? No, not easily. The problem is that we only keep one smap entry around at a time and don't save the whole table. For the most part people shouldn't be using hw.physmem with ACPI anyways except to shrink the memory down for testing, so I'm almost inclined to say "don't use it". Ideally hw.physmem would only extend the end of physical memory to cover chunks not reserved by a type of !1 (IOW, either type = 1 regions or outright holes in the map), but without full access to the SMAP table that's not that easy to do. I think folks should just stop setting hw.physmem, it mostly exists as workaround for when we don't get the memory size right from the BIOS, and folks shouldn't use it if we get the size right without it unless they want to blow their feet off. :) -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org