Date: Mon, 20 Sep 2004 16:03:37 -0700 From: "Moore, Robert" <robert.moore@intel.com> To: "Nate Lawson" <nate@root.org>, <sklauder@trimind.de> Cc: freebsd-acpi@freebsd.org Subject: RE: trouble overriding DSDT Message-ID: <37F890616C995246BE76B3E6B2DBE055020AD7F8@orsmsx403.amr.corp.intel.com>
next in thread | raw e-mail | index | archive | help
> Oh, sorry. Yes, acpidump(8) will always pull the underlying "real" > table from memory. If acpidump is dumping the "real" tables, why does the DSDT get combined with the SSDT? > -----Original Message----- > From: Nate Lawson [mailto:nate@root.org] > Sent: Sunday, September 19, 2004 11:21 PM > To: sklauder@trimind.de > Cc: Moore, Robert; freebsd-acpi@freebsd.org; Marcel Moolenaar > Subject: Re: trouble overriding DSDT >=20 > 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))? >=20 > Oh, sorry. Yes, acpidump(8) will always pull the underlying "real" > table from memory. >=20 > -Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37F890616C995246BE76B3E6B2DBE055020AD7F8>