Bug 15801 - _PR namespace not initialised on HP Pavilion dm1 with Intel Celeron SU2300
Summary: _PR namespace not initialised on HP Pavilion dm1 with Intel Celeron SU2300
Status: CLOSED DUPLICATE of bug 14824
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: acpi_acpica-core@kernel-bugs.osdl.org
URL:
Keywords:
: 15800 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-04-17 07:18 UTC by Elio Voci
Modified: 2010-09-29 01:57 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.33
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Disassembly listing of DSDT (401.02 KB, text/plain)
2010-04-17 07:39 UTC, Elio Voci
Details
Output of lshw (16.64 KB, text/plain)
2010-04-17 07:40 UTC, Elio Voci
Details
dmesg output (61.15 KB, text/plain)
2010-04-17 07:42 UTC, Elio Voci
Details
acpidump output (224.65 KB, text/x-log)
2010-04-19 16:16 UTC, Elio Voci
Details
script to get acpi tables (406 bytes, application/octet-stream)
2010-04-20 07:08 UTC, Zhang Rui
Details
output of acpidump -a 0xBBA6F598 -l 0x537 (1.30 KB, application/octet-stream)
2010-04-20 07:13 UTC, Elio Voci
Details
all the ACPI tables resulting from Zhang's script (21.42 KB, application/x-gzip)
2010-04-20 09:36 UTC, Elio Voci
Details
DSDT+SSDT modified to force loading dynamic SSDTn (138.63 KB, application/x-gzip)
2010-04-24 20:19 UTC, Elio Voci
Details

Description Elio Voci 2010-04-17 07:18:54 UTC
System reports at boot:
[    1.330173] ACPI Error (psargs-0359): [\_PR_.CPU0._PPC] Namespace lookup failure, AE_NOT_FOUND
[    1.330186] ACPI Error (psparse-0537): Method parse/execution failed [\CPUL] (Node f6c15ae0), AE_NOT_FOUND
[    1.330243] ACPI Error (psparse-0537): Method parse/execution failed [\_TZ_.TZ01.OTHD] (Node f6c15918), AE_NOT_FOUND
[    1.330303] ACPI Error (psparse-0537): Method parse/execution failed [\_TZ_.TZ01._TMP] (Node f6c15870), AE_NOT_FOUND

I've disassembled DSDT but nothing seems evidently wrong.
Problem appears with kernels 2.6.26, 2.6.30, 2.6.32, 2.6.33 (currently in use)
I've enabled ACPI debug and noticed that "Initialisation of Region [_PR_]" is not reported.

Obviously, processor is not recognised and all services depending on it fail (power, speedstep, etc.)

Firmware is F.13 (25/01/2010), the latest available from HP.

Any hint on what to address the attention is welcome.
Comment 1 Elio Voci 2010-04-17 07:39:25 UTC
Created attachment 26031 [details]
Disassembly listing of DSDT

this is the disassembled DSDT
Comment 2 Elio Voci 2010-04-17 07:40:26 UTC
Created attachment 26032 [details]
Output of lshw
Comment 3 Elio Voci 2010-04-17 07:42:49 UTC
Created attachment 26033 [details]
dmesg output

With ACPI debug enabled, acpi.debug_level=0xFFFFFFFF
Comment 4 Robert Moore 2010-04-19 15:39:21 UTC
Please post the acpidump for the machine.
Comment 5 Elio Voci 2010-04-19 16:16:24 UTC
Created attachment 26050 [details]
acpidump output
Comment 6 Robert Moore 2010-04-19 21:32:42 UTC
There are two dynamic tables that look like they should be loaded. Please post the acpidump for both.

They are at:
0xBBA70E18
0xBBA6F598
Comment 7 Zhang Rui 2010-04-20 07:08:39 UTC
Created attachment 26056 [details]
script to get acpi tables

please run this script to get all the ACPI tables, and attach them here, better in a tarball.
Comment 8 Elio Voci 2010-04-20 07:13:01 UTC
Created attachment 26057 [details]
output of acpidump -a 0xBBA6F598 -l 0x537

~$ sudo acpidump -a 0xBBA6F598 -o acpidump-BBA6F598.log
ACPI tables were not found. If you know location of RSD PTR table (from dmesg, etc), supply it with either --addr or -a option
~$ dmesg | grep bba6f598
[    6.774512] ACPI: SSDT bba6f598 00537 (v01  PmRef  Cpu0Cst 00003001 INTL 20051117)
~$ sudo acpidump -a 0xBBA6F598 -l 0x537 -o acpidump-BBA6F598.log
Comment 9 Elio Voci 2010-04-20 09:36:00 UTC
Created attachment 26058 [details]
all the ACPI tables resulting from Zhang's script
Comment 10 Robert Moore 2010-04-20 15:39:09 UTC
The _PPC object for CPU0 is defined in SSDT2:

    Scope (\_PR.CPU0)
    {
        Name (_PPC, Zero)

It looks as if SSDT2 is either not being loaded, or is not loaded at the time that _PPC is accessed from the DSDT.

SSDT2 would be dynamically loaded from the primary SSDT. The primary SSDT is loaded at table initialization time.

I'll look around some more for some answers. If I don't find anything, perhaps Zhang Rui can help some more.
Comment 11 Zhang Rui 2010-04-22 03:08:35 UTC
*** Bug 15800 has been marked as a duplicate of this bug. ***
Comment 12 Elio Voci 2010-04-22 07:04:54 UTC
What if I create a custom DSDT merging the code of SSDT2?
Comment 13 Robert Moore 2010-04-23 14:37:49 UTC
It would be more interesting to modify the first SSDT (which is in the XSDT) to unconditionally load the additional SSDTs.  

Original code:

            If (And (CFGD, One))
            {
                If (LAnd (LAnd (And (CFGD, 0x01000000), LEqual (And (PDC0, 
                    0x09), 0x09)), LNot (And (SDTL, One))))
                {
                    Or (SDTL, One, SDTL)
                    OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, One)), DerefOf (Index (SSDT, 0x02
                        )))
                    Load (IST0, HI0)
                }
            }

            If (And (CFGD, 0xF0))
            {
                If (LAnd (LAnd (And (CFGD, 0x01000000), And (PDC0, 0x18
                    )), LNot (And (SDTL, 0x02))))
                {
                    Or (SDTL, 0x02, SDTL)
                    OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08
                        )))
                    Load (CST0, HC0)
                }
            }


New code:

            Or (SDTL, One, SDTL)
            OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT, One)), DerefOf (Index (SSDT, 0x02
                )))
            Load (IST0, HI0)

            Or (SDTL, 0x02, SDTL)
            OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT, 0x07)), DerefOf (Index (SSDT, 0x08
                )))
            Load (CST0, HC0)

Just strip the surrounding If statements
Comment 14 Elio Voci 2010-04-24 20:16:57 UTC
I've done the following:

1) edited the DSDT.dsl and merged SSDT.dsl (according to http://www.lesswatts.org/projects/acpi/overridingDSDT.php) modified according to the last post
2) changed the name of _T_0 to TT_0 due to an error raised by iasl
3) compiled with "iasl -tc myDSDT.dsl"
4) compiled the kernel and installed
5) rebooted with acpi_no_auto_ssdt

Nothing really changed. Attached the relevant files.

Shall I merge in myDSDT also SSDT2-5?
Comment 15 Elio Voci 2010-04-24 20:19:11 UTC
Created attachment 26121 [details]
DSDT+SSDT modified to force loading dynamic SSDTn

log is obtained as:
$ dmesg | grep ACPI > dmesg-ACPI.log
Comment 16 Robert Moore 2010-04-27 20:09:14 UTC
It looks like _PPC is being accessed before the SSDT that contains it is actually loaded.

[    1.356711] ACPI Error (psargs-0359): [\_PR_.CPU0._PPC] Namespace lookup failure, AE_NOT_FOUND
[    1.356723] ACPI Error (psparse-0537): Method parse/execution failed [\CPUL] (Node f7014ae0), AE_NOT_FOUND
[    1.356800] ACPI Error (psparse-0537): Method parse/execution failed [\_TZ_.TZ01.OTHD] (Node f7014918), AE_NOT_FOUND
[    1.356879] ACPI Error (psparse-0537): Method parse/execution failed [\_TZ_.TZ01._TMP] (Node f7014870), AE_NOT_FOUND
[    1.558233] ACPI: Power Button [PWRB]
[    1.558881] ACPI: Lid Switch [LID0]
[    1.558985] ACPI: Sleep Button [SLPB]
[    1.559109] ACPI: Power Button [PWRF]
[    5.904325] ACPI: AC Adapter [ACAD] (on-line)
[    5.912570] ACPI: Battery Slot [BAT0] (battery present)

Dynamic table loads:

[    5.927188] ACPI: SSDT bba70e18 0019F (v01  PmRef  Cpu0Ist 00003000 INTL 20051117)
[    5.929040] ACPI: SSDT bba6f598 00537 (v01  PmRef  Cpu0Cst 00003001 INTL 20051117)
[    5.932728] ACPI: SSDT bba70c18 001CF (v01  PmRef    ApIst 00003000 INTL 20051117)
[    5.934392] ACPI: SSDT bba6ef18 0008D (v01  PmRef    ApCst 00003000 INTL 20051117)
[
Comment 17 Elio Voci 2010-05-07 18:58:31 UTC
Thanks Robert

Just a couple of remarks:
1 - kernel 2.6.26 does not have such behaviour
2 - The DSDT recompiled with all SSDT inside, and booted with acpi_no_auto_ssdt only complains about the absence of the thermal threshold

What should happen now? Shall I expect that the next kernel will manage the dynamic ssdts properly?
Comment 18 Zhang Rui 2010-05-10 06:45:20 UTC
please re-open the bug report if it is not a duplicate of bug #14824
and the problem still exists in the latest kenrel release, say 2.6.34-rcX.

*** This bug has been marked as a duplicate of bug 14824 ***

Note You need to log in before you can comment on or make changes to this bug.