Date: Sun, 19 Sep 2004 23:20:38 -0700 From: Nate Lawson <nate@root.org> To: sklauder@trimind.de Cc: "Moore, Robert" <robert.moore@intel.com> Subject: Re: trouble overriding DSDT Message-ID: <414E76B6.1010107@root.org> In-Reply-To: <20040919221958.GA17850@trimind.de> References: <37F890616C995246BE76B3E6B2DBE05502071306@orsmsx403.amr.corp.intel.com> <414CA156.7040606@root.org> <20040919163706.GA904@trimind.de> <414DF52E.1030109@root.org> <20040919221958.GA17850@trimind.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Sascha Klauder wrote: > On Sun, Sep 19, 2004 at 02:07:58PM -0700, Nate Lawson wrote: > >>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, > > > Yes, that did the trick! > > >>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. > > > Right, the ASLs are effectively the same, with the exception > that the very changes I did in the first place now seem to be > "backed out". Is this the supposed behaviour when the DSDT > is overridden (i.e. acpidump(8) always dumps the DSDT pro- > vided by the BIOS (or something to that effect))? Oh, sorry. Yes, acpidump(8) will always pull the underlying "real" table from memory. -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?414E76B6.1010107>