http://bugzilla.kernel.org/show_bug.cgi?id=8630


[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|CODE_FIX                    |




------- Comment #44 from [EMAIL PROTECTED]  2007-09-05 16:42 -------
I agree with Yakui about Andreas' system:

#1 -- the garbled XSDT issue should be solved in 2.6.23-rc4.
Andreas,
Please boot an un-patched 2.6.23-rc4 or later, verify
that cpufreq is working, and attach the output from dmesg -s64000.

#2 -- yes, it appears that Linux is complaining about a real BIOS bug.
SSDT @ 0x7f6e82c0 (SSDT1)
SSDT @ 0x7f6e8820 (SSDT2)
are loaded at boot time because they are present in the RSDT.

SSDT2 has this:

       Name (SSDT, Package (0x1E)
        {
            "CPU0IST ",
            0x7F6E82C0,
            0x00000231,
            "CPU1IST ",
            0x7F6E8750,
            0x000000CE,

and SSDT1 does this:
    Scope (\_PR.CPU0)
...
       Method (_PDC, 1, NotSerialized)
        {
            CreateDWordField (Arg0, 0x08, CAP0)
            Store (CAP0, PDC0)
            If (LEqual (TLD0, 0x00))
            {
                If (LEqual (And (PDC0, 0x0A), 0x0A))
                {
                    If (And (CFGD, 0x02))
                    {
                        OperationRegion (IST0, SystemMemory, DerefOf (Index
(SSDT, 0x01)), DerefOf (Index (SSDT, 0x02
                            )))
                        Load (IST0, HI0)
                    }

                    Store (0x01, TLD0)
                }
            }
        }

ie. at run-time it Load's (0x7F6E82C0, 0x00000231),
which is indeed, the same SSDT that contains this load!

That explains the following message:

ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._PDC]
> (Node dfe90608), AE_ALREADY_EXISTS
> ACPI: Marking method _PDC as Serialized

This message can be ignored, and it should stay in Linux
because it could indicate a more severe problem on a different system.

The following two messages:
> ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not
> present [20070126]
> ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not
> present [20070126]

are explained by the dmesg log:

 nsutils-0869 [03] ns_get_node           : _STA, AE_NOT_FOUND
   utils-0273 [00] evaluate_integer      : Evaluate [\_PR_.CPU2._STA]:
AE_NOT_FOUND
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not
present [20070126]
    scan-0270 [00] device_probe          : Found driver [processor] for device
[CPU2]
    scan-0453 [00] bus_driver_init       : Driver successfully bound to device
processor_core-0533 [00] processor_get_info    : No bus mastering arbitration
control
 nsutils-0869 [03] ns_get_node           : _MAT, AE_NOT_FOUND
 nsutils-0869 [03] ns_get_node           : _STA, AE_NOT_FOUND
   utils-0273 [00] evaluate_integer      : Evaluate [\_PR_.CPU3._STA]:
AE_NOT_FOUND
ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not
present [20070126]

It is normal to find no processor 2 and processor 3 on a 2-processor system.
It is a Linux bug that these messages are printed on this system.

The 2nd remaining Linux bug is this:
> ACPI Error (utglobal-0126): Unknown exception code: 0xFFFFFFF0 [20070126]

which indicates a programming bug someplace.  As it is right
after an hpet message, it is probably the HPET code.

The 2.6.23-rc5 dmesg you are going to attach should contain
a stack-trace that will tell us exactly where that error lies.

As the processor message and the (suspected) hpet message
are both in code venki is responsible for, I'm assigning the
reset of this bug to him and re-opening to indicate that
these remaining 2 issues are unresolved.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla

Reply via email to