From owner-freebsd-acpi@FreeBSD.ORG Sun Sep 19 21:08:00 2004 Return-Path: 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 A42AF16A4DF for ; Sun, 19 Sep 2004 21:08:00 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A19343D2F for ; Sun, 19 Sep 2004 21:08:00 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.52] (adsl-64-171-186-250.dsl.snfc21.pacbell.net [64.171.186.250])i8JL7swn014599; Sun, 19 Sep 2004 17:07:55 -0400 Message-ID: <414DF52E.1030109@root.org> Date: Sun, 19 Sep 2004 14:07:58 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sascha Klauder References: <37F890616C995246BE76B3E6B2DBE05502071306@orsmsx403.amr.corp.intel.com> <414CA156.7040606@root.org> <20040919163706.GA904@trimind.de> In-Reply-To: <20040919163706.GA904@trimind.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-acpi@freebsd.org cc: "Moore, Robert" Subject: Re: trouble overriding DSDT X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2004 21:08:00 -0000 Sascha Klauder wrote: > On Sat, Sep 18, 2004 at 01:57:58PM -0700, Nate Lawson wrote: > >>To do this on freebsd, build the module with options ACPI_DEBUG and then >>set the loader variables of debug.acpi.layer and debug.acpi.level >>according to the man page. I suggest to start with: >> >>debug.acpi.layer="ACPI_ALL_COMPONENTS" >>debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" > > Ok, just tried that. Unfortunately, I was unable to get the serial > console working (it was just outputting garbage, while the same > setup (cabling, software) works just fine as soon as the kernel has > finished booting), so I had to transcribe the parts looking most re- > levant to me: > > tbget-0497 [08] TbGetThisTable : Found table [DSDT] at 200000c07b4a54, mapped/copied to 0xc1989028 > tbget-0374: *** Info: Table [DSDT] replaced by host OS > tbinstall-0233 [06] TbInstallTable : DSDT located at 0xc1989028 > tbxface-0195 [03] AcpiLoadTables : ACPI Tables successfully aquired > nsload-0264 [05] NsLoadTableByType : Loading DSDT > nsload-0171 [06] NsLoadTable : AML block at 0xc198904c > nsload-0190 [06] NsLoadTable : *** Loading table into namespace *** > nsload-0289 [06] NsLoadTable : *** Completed Table Method Parsing and Object Initialization *** > nsload-0289 [05] NsLoadTableByType : Loading 1 SSDTs ^^^^^^^^^^^^^^^^ There's your problem. > nsload-0171 [06] NsLoadTable : AML block at 0xd421eeeb > nsload-0190 [06] NsLoadTable : *** Loading table into namespace *** > dswload-0380: *** Error: Looking up [_PCT] in namespace, AE_ALREADY_EXISTS > psparse-0710 [10] PsParseLoop : During name lookup/catalog, AE_ALREADY_EXISTS > psparse-1303: *** Error: [NULL NAME], AE_ALREADY_EXISTS > > Fatal trap 12: page fault while in kernel mode > [...] When we disassemble the DSDT in acpidump(8), we also disassemble any SSDTs as well. When you override the DSDT, you are loading a combined DSDT+SSDT table but the original SSDT is still in memory. Thus you get the duplicated namespace values. An easy way to test this is to comment out everything in your ASL from the Scope(...CPU0) to the end, recompile, load it, then if it boots ok, do another acpidump and diff the two. If I'm right, you'll find commenting out some part gets you the same ASL after booting with the custom one. The right fix I think is to disable SSDT loading if we've overridden the DSDT. Bob, what do you think? Marcel, we should fix this for 5.3R because it will prevent people from using custom ASL easily. Another quick fix would be to put a comment block around the disassembled SSDT so it is there for inspection but doesn't affect recompilation. -Nate