Hi, Len
Please apply this patch.
Load the dynamic table under root node.
Lin Ming
Signed-off-by: Lin Ming <ming.m.lin@xxxxxxxxx>
---
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 Tue, 2008-05-06 at 14:20 +0800, Lin Ming wrote:
> 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
