From owner-freebsd-acpi@FreeBSD.ORG Wed Nov 30 18:13:56 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 9238916A41F; Wed, 30 Nov 2005 18:13:56 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39AD143D58; Wed, 30 Nov 2005 18:13:56 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id jAUIE9ZM018710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Nov 2005 10:14:09 -0800 Message-ID: <438DEBE2.2010006@root.org> Date: Wed, 30 Nov 2005 10:13:54 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20051127010724.GA1161@Grumpy.DynDNS.org> <7689ADE7-14BF-42C8-A3BD-B10E514799B3@FreeBSD.org> <438D6CE4.8010907@root.org> <200511301018.24822.jhb@freebsd.org> In-Reply-To: <200511301018.24822.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, 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 18:13:56 -0000 John Baldwin wrote: > On Wednesday 30 November 2005 04:12 am, Nate Lawson wrote: > >>John Baldwin wrote: >>>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: > > 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. That sounds like the problem. hw.physmem should still respect the SMAP restrictions even when overriding the memory size value. The way to tell the PA for the FACS is just look at the acpidump -t output. Look at what order the tables appear (FACP, FACS, ...) and then look up the address in the RSDT Entries list. As shown in his previous debug output, the 2nd entry in his RSDT is when acpidump -t errors out. That address is 0xfffc8fd7, and indeed is at top of memory - 200 KB. /* RSDT: Length=56, Revision=1, Checksum=215, OEMID=DELL, OEM Table ID=PE400SC, OEM Revision=0x7, Creator ID=ASL, Creator Revision=0x61 Entries={ 0x000fd17b, 0xfffc8fd7, 0x000fd1ef, 0x000fd25b, 0x000fd283 } */ -- Nate