trouble overriding DSDT

[Nate Lawson]

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