We should find out how windows handles table loading.
Bob
>-----Original Message-----
>From: Lin, Ming M
>Sent: Monday, May 05, 2008 11:21 PM
>To: Moore, Robert
>Cc: Len Brown; linux-acpi@xxxxxxxxxxxxxxx
>Subject: RE: ACPICA branch (0 Objects with 0 Devices 0 Methods 0
Regions)
>
>Hi, all
>
>The root cause found, it's caused by a patch
>which introduced in ACPICA version 20071019
>
>commit 7f4ac9f91383a0707de559dc8fbca986fc2d302f
>Author: Bob Moore <robert.moore@xxxxxxxxx>
>Date: Thu Apr 10 19:06:39 2008 +0400
>
> ACPICA: Fix for Load/LoadTable to specify load location
>
> Fixed a problem with the Load and LoadTable operators where
> the table location within the namespace was ignored. Instead,
> the table was always loaded into the root or current scope.
>
> Signed-off-by: Bob Moore <robert.moore@xxxxxxxxx>
> Signed-off-by: Alexey Starikovskiy <astarikovskiy@xxxxxxx>
> Signed-off-by: Len Brown <len.brown@xxxxxxxxx>
>
>
>For example,
>SSDT:
>Name(\tmp0, 0)
>
>DSDT:
>Method(m000)
>{
> <Load the SSDT above>
>}
>
>Namespace walking will start at node m000, so \tmp0 will never appear
at
>the namespace walking.
>
>It seems that we should again force the table always loaded into the
>root.
>Load statement is always inside a method.
>It makes no sense to install some nodes inside a method since the nodes
>in method should all be temporary nodes that will be deleted when
method
>exit.
>
>Lin Ming
>---
>diff --git a/drivers/acpi/executer/exconfig.c
>b/drivers/acpi/executer/exconfig.c
>index 24da921..508bb0e 100644
>--- a/drivers/acpi/executer/exconfig.c
>+++ b/drivers/acpi/executer/exconfig.c
>@@ -376,7 +376,7 @@ acpi_ex_load_op(union acpi_operand_object
*obj_desc,
> }
>
> status =
>- acpi_ex_add_table(table_index,
>walk_state->scope_info->scope.node,
>+ acpi_ex_add_table(table_index, acpi_gbl_root_node,
> &ddb_handle);
> if (ACPI_FAILURE(status)) {
>
>On Wed, 2008-04-30 at 00:09 +0800, Moore, Robert wrote:
>> It looks like the tables in question are dynamically loaded:
>>
>> >ACPI: SSDT 7D6E1B32, 02C4 (r1 PmRef Cpu0Ist 100 INTL
20050513)
>> >Table [SSDT](id 0044) - 0 Objects with 0 Devices 0 Methods 0 Regions
>> >ACPI: SSDT 7D6E1E7B, 085E (r1 PmRef Cpu0Cst 100 INTL
20050513)
>> >Table [SSDT](id 0045) - 0 Objects with 0 Devices 0 Methods 0 Regions
>> >ACPI: SSDT 7D6E1A6A, 00C8 (r1 PmRef Cpu1Ist 100 INTL
20050513)
>> >Table [SSDT](id 0050) - 0 Objects with 0 Devices 0 Methods 0 Regions
>> >ACPI: SSDT 7D6E1DF6, 0085 (r1 PmRef Cpu1Cst 100 INTL
20050513)
>> >Table [SSDT](id 0051) - 0 Objects with 0 Devices 0 Methods 0 Regions
>>
>> What the zeroes mean is that a WalkNamespace after the table load did
>> not find any such objects created by the table.
>>
>> Something does look wrong, it may not affect your machine, but has
the
>> potential to cause problems on other machines.
>>
>> The difference in owner IDs between the two traces might mean that
there
>> is some mismatch somewhere. I would debug and determine 1) The actual
>> owner id created for the newly loaded table, and 2) what owner id is
>> passed to AcpiDsInitializeObjects after the table is loaded.
>>
>> Bob
>>
>>
>>
>> >-----Original Message-----
>> >From: Len Brown [mailto:lenb@xxxxxxxxxx]
>> >Sent: Tuesday, April 29, 2008 2:05 AM
>> >To: linux-acpi@xxxxxxxxxxxxxxx; Moore, Robert; Lin, Ming M
>> >Subject: Re: ACPICA branch (0 Objects with 0 Devices 0 Methods 0
>> Regions)
>> >
>> >Hmm, i just noticed something strange on the T61
>> >
>> >Linus' tree prints these messages:
>> >
>> >[lenb@t61 sut]$ grep -i ssdt 2.6.25-06058-ga01e035/dmesg
>> >ACPI: SSDT 7D6BB9B4, 0269 (r1 LENOVO TP-7L 2100 MSFT
3000000)
>> >ACPI: SSDT 7D6E26D9, 025F (r1 LENOVO TP-7L 2100 INTL
20050513)
>> >ACPI: SSDT 7D6E2938, 00A6 (r1 LENOVO TP-7L 2100 INTL
20050513)
>> >ACPI: SSDT 7D6E29DE, 04F7 (r1 LENOVO TP-7L 2100 INTL
20050513)
>> >ACPI: SSDT 7D6E2ED5, 01D8 (r1 LENOVO TP-7L 2100 INTL
20050513)
>> >Table [SSDT](id 0002) - 11 Objects with 0 Devices 7 Methods 0
Regions
>> >Table [SSDT](id 0003) - 7 Objects with 0 Devices 3 Methods 0 Regions
>> >Table [SSDT](id 0004) - 4 Objects with 0 Devices 3 Methods 0 Regions
>> >Table [SSDT](id 0005) - 14 Objects with 0 Devices 5 Methods 0
Regions
>> >Table [SSDT](id 0006) - 14 Objects with 1 Devices 2 Methods 0
Regions
>> >ACPI: SSDT 7D6E1B32, 02C4 (r1 PmRef Cpu0Ist 100 INTL
20050513)
>> >Table [SSDT](id 003A) - 6 Objects with 0 Devices 4 Methods 0 Regions
>> >ACPI: SSDT 7D6E1E7B, 085E (r1 PmRef Cpu0Cst 100 INTL
20050513)
>> >Table [SSDT](id 003B) - 16 Objects with 0 Devices 1 Methods 0
Regions
>> >ACPI: SSDT 7D6E1A6A, 00C8 (r1 PmRef Cpu1Ist 100 INTL
20050513)
>> >Table [SSDT](id 0046) - 4 Objects with 0 Devices 4 Methods 0 Regions
>> >ACPI: SSDT 7D6E1DF6, 0085 (r1 PmRef Cpu1Cst 100 INTL
20050513)
>> >Table [SSDT](id 0047) - 1 Objects with 0 Devices 1 Methods 0 Regions
>> >
>> >
>> >The acpi test tree prints these messages:
>> >
>> >[lenb@t61 sut]$ grep -i ssdt 2.6.25-06238-gf4e0ea3/dmesg
>> >ACPI: SSDT 7D6BB9B4, 0269 (r1 LENOVO TP-7L 2100 MSFT
3000000)
>> >ACPI: SSDT 7D6E26D9, 025F (r1 LENOVO TP-7L 2100 INTL
20050513)
>> >ACPI: SSDT 7D6E2938, 00A6 (r1 LENOVO TP-7L 2100 INTL
20050513)
>> >ACPI: SSDT 7D6E29DE, 04F7 (r1 LENOVO TP-7L 2100 INTL
20050513)
>> >ACPI: SSDT 7D6E2ED5, 01D8 (r1 LENOVO TP-7L 2100 INTL
20050513)
>> >Table [SSDT](id 0002) - 11 Objects with 0 Devices 7 Methods 0
Regions
>> >Table [SSDT](id 0003) - 7 Objects with 0 Devices 3 Methods 0 Regions
>> >Table [SSDT](id 0004) - 4 Objects with 0 Devices 3 Methods 0 Regions
>> >Table [SSDT](id 0005) - 14 Objects with 0 Devices 5 Methods 0
Regions
>> >Table [SSDT](id 0006) - 14 Objects with 1 Devices 2 Methods 0
Regions
>> >ACPI: SSDT 7D6E1B32, 02C4 (r1 PmRef Cpu0Ist 100 INTL
20050513)
>> >Table [SSDT](id 0044) - 0 Objects with 0 Devices 0 Methods 0 Regions
>> >ACPI: SSDT 7D6E1E7B, 085E (r1 PmRef Cpu0Cst 100 INTL
20050513)
>> >Table [SSDT](id 0045) - 0 Objects with 0 Devices 0 Methods 0 Regions
>> >ACPI: SSDT 7D6E1A6A, 00C8 (r1 PmRef Cpu1Ist 100 INTL
20050513)
>> >Table [SSDT](id 0050) - 0 Objects with 0 Devices 0 Methods 0 Regions
>> >ACPI: SSDT 7D6E1DF6, 0085 (r1 PmRef Cpu1Cst 100 INTL
20050513)
>> >Table [SSDT](id 0051) - 0 Objects with 0 Devices 0 Methods 0 Regions
>> >
>> >ie. "0 Objects with 0 Devices 0 Methods 0 Regions"
>> >
>> >dunno if this is just cosmetic -- the p-states that are advertised
in
>> >the SSDT's seem to be working normally, and C-states do too.
>> >
>> >-Len
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
