Bug 8630 (besse) - ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126] - Core 2 Duo E4400
Summary: ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not p...
Status: CLOSED DUPLICATE of bug 8570
Alias: besse
Product: ACPI
Classification: Unclassified
Component: Config-Processors (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: ykzhao
URL:
Keywords:
: 8911 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-14 14:21 UTC by nona00
Modified: 2007-10-17 00:28 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.22-rc4
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
Acpi-Logfile (2.86 KB, application/txt)
2007-06-14 14:22 UTC, nona00
Details
decompiled DSDT (181.77 KB, application/octet-stream)
2007-06-14 14:24 UTC, nona00
Details
cpuinfo (2.03 KB, application/txt)
2007-06-14 14:26 UTC, nona00
Details
dmesg with ACPI_DEBUG=y (19.17 KB, application/txt)
2007-06-14 15:25 UTC, nona00
Details
acpidump (91.55 KB, application/octet-stream)
2007-07-12 00:23 UTC, nona00
Details
dmesg with acpi.debug_level=0x1f cpufreq.debug=7 (30.99 KB, application/octet-stream)
2007-07-27 01:43 UTC, nona00
Details
dmesg output for 2.6.21.1 booting Intel DG965RY firmware 1687 (23.58 KB, text/plain)
2007-08-03 19:45 UTC, John Karp
Details
acpidump output for Intel DG965RY version 1687 (87.83 KB, text/plain)
2007-08-03 19:52 UTC, John Karp
Details
acpidump with pmtools-20070714-debug and Bios 642F1D42 (99.12 KB, application/octet-stream)
2007-08-07 14:21 UTC, nona00
Details
Introduce boot option acpi=rsdt_forced (3.94 KB, patch)
2007-08-20 18:29 UTC, ykzhao
Details | Diff
Force to use RSDT when XSDT has NULL entry (4.88 KB, patch)
2007-08-21 03:58 UTC, ykzhao
Details | Diff
dmesg of kernel 2.6.22.2 with rsdt patch (30.53 KB, application/txt)
2007-08-21 05:17 UTC, nona00
Details
get the acpidump output using the attached binary (11.20 KB, application/octet-stream)
2007-08-21 23:23 UTC, ykzhao
Details
Get ACPIdump output using the attached binary (9.98 KB, application/octet-stream)
2007-08-22 01:00 UTC, ykzhao
Details
acpidump output (97.59 KB, application/octet-stream)
2007-08-22 01:05 UTC, nona00
Details
dmesg output with errors after patch applied (66.39 KB, text/plain)
2007-08-22 06:40 UTC, Alan Jenkins
Details
dmesg of kernel 2.6.22.2 with rsdt patch, without acpi debug (21.08 KB, application/octet-stream)
2007-08-22 09:29 UTC, nona00
Details
./acpidump --addr 0x7F6E82c0 --length 0x231 -o SSDT1 (561 bytes, application/octet-stream)
2007-08-23 02:55 UTC, nona00
Details
./acpidump --addr 0x7f6e8820 --length 0x2F9 -o SSDT2 (761 bytes, application/octet-stream)
2007-08-23 02:56 UTC, nona00
Details
acpidump --addr 0x7f6e8750 --length 0xce -o IST1 (767 bytes, application/x-tgz)
2007-08-23 05:25 UTC, Alan Jenkins
Details
./acpidump --addr 0x7f6e8750 --length 0xce -o IST1 (206 bytes, application/octet-stream)
2007-08-23 05:34 UTC, nona00
Details
patch vs 2.6.23-rc3 to use RSDT when NULL in XSDT (3.83 KB, patch)
2007-08-24 15:58 UTC, Len Brown
Details | Diff
dmesg -s64000 of unpatched 2.6.23-rc5 (19.59 KB, application/octet-stream)
2007-09-06 11:13 UTC, nona00
Details
Use acpi status code in the callback function of hpet_resources (1.83 KB, patch)
2007-09-18 19:20 UTC, ykzhao
Details | Diff
avoid the error message that processor device is not present (1.33 KB, patch)
2007-10-07 19:53 UTC, ykzhao
Details | Diff
avoid printing the error message that processor device is not present (1.36 KB, patch)
2007-10-07 20:22 UTC, ykzhao
Details | Diff

Description nona00 2007-06-14 14:21:40 UTC
Most recent kernel where this bug did not occur:none
Distribution:Debian, Knoppix (Kernel 2.6.19)
Hardware Environment: Foxconn 946GZ7MA-8KRS2H (intel 946gz chipset) with newest bios 642F1P34, Core 2 Duo E4400 (SLA3F), 2GB ram
Software Environment:Debian Testing with Distro-kernel 2.6.21-1-682 and mainline  kernel 2.6.22-rc4

Problem Description: Cpu scaling (EIST) isn't working. When I am trying to load the processor module i get:
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126]
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126]

When i try to load acpi-cpufreq i get:
FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.21-1-686/kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko): No such device

Steps to reproduce:Load processor kernel module.
Comment 1 nona00 2007-06-14 14:22:50 UTC
Created attachment 11752 [details]
Acpi-Logfile
Comment 2 nona00 2007-06-14 14:24:47 UTC
Created attachment 11753 [details]
decompiled DSDT
Comment 3 nona00 2007-06-14 14:26:50 UTC
Created attachment 11754 [details]
cpuinfo
Comment 4 nona00 2007-06-14 15:25:05 UTC
Created attachment 11755 [details]
dmesg with ACPI_DEBUG=y
Comment 5 Len Brown 2007-07-11 20:56:10 UTC
There is no indication that EIST is supported
by this BIOS:

    Scope (\_PR)
    {
        Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00) {}
        Processor (\_PR.CPU1, 0x01, 0x00000000, 0x00) {}
        Processor (\_PR.CPU2, 0x02, 0x00000000, 0x00) {}
        Processor (\_PR.CPU3, 0x03, 0x00000000, 0x00) {}
    }

Take a look in the BIOS Setup and see if there are some options
to enable EIST or Processor Power Management.
Comment 6 Len Brown 2007-07-11 20:57:57 UTC
oops, i really need the complete output from acpidump to
get a better look at this one -- please attach it.
Comment 7 nona00 2007-07-12 00:23:35 UTC
Created attachment 12006 [details]
acpidump

Here is the full output of acpidump. Currently i'm using a newer bios, but the issue is the same. EIST is enabled in Bios and is working with Windows Vista, but not with Linux.
Comment 8 Patrizio Bassi 2007-07-14 15:45:23 UTC
similar issue with me. windows scale, linux not
Comment 9 Patrizio Bassi 2007-07-15 07:48:55 UTC
after a bios update and reset to default values it came back working.

strange because windows worked like a charm even before it....
Comment 10 nona00 2007-07-27 01:43:51 UTC
Created attachment 12177 [details]
dmesg with acpi.debug_level=0x1f cpufreq.debug=7

tried vanilla kernel 2.6.22.1. Same issue:

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]
Comment 11 John Karp 2007-07-31 17:24:59 UTC
I think I'm getting the same issue with:
Intel DG965RY motherboard
Intel Core2 Duo 6300
BIOS version MQ1687
Kernel 2.6.22.1-cfs-v19 #1 SMP PREEMPT x86_64

dmesg snippet:
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Processor [CPU1] (supports 8 throttling states)
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]

Let me know if you want more info from me.
Comment 12 John Karp 2007-08-03 19:45:05 UTC
Created attachment 12243 [details]
dmesg output for 2.6.21.1 booting Intel DG965RY firmware 1687
Comment 13 John Karp 2007-08-03 19:52:31 UTC
Created attachment 12244 [details]
acpidump output for Intel DG965RY version 1687
Comment 14 Len Brown 2007-08-07 13:41:24 UTC
Andreas,
Thanks for the acpidump in comment #7.
I was hoping to find an SSDT that augmented the missing EIST support
in the DSDT.  However, as your dmesg showed, there is no SSDT,
and there are some mysterious zero addresses in your XSDT:

ACPI: RSDP 000F7DF0, 0024 (r2 IntelR)
ACPI: XSDT 7F6E30C0, 0044 (r1 IntelR AWRDACPI 42302E31 AWRD        0)
ACPI: FACP 7F6E7F80, 00F4 (r3 IntelR AWRDACPI 42302E31 AWRD        0)
ACPI: DSDT 7F6E3240, 4CCA (r1 INTELR AWRDACPI     1000 MSFT  100000E)
ACPI: FACS 7F6E0000, 0040
ACPI Error (tbutils-0219): Null physical address for ACPI table [<NULL>] [20070126]
ACPI Error (tbutils-0219): Null physical address for ACPI table [<NULL>] [20070126]
ACPI: APIC 7F6E80C0, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD        0)

It is possible that Linux and our debug tools are both failing
to find the EIST support in the BIOS for the same reason...

Please attach the output from the debug version of acpidump here.
If it works properly, it will follow not just the XSDT,
but also the RSDT -- and perhaps that will find our missing SSDT's.

http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20070714-debug.tar.gz
Comment 15 Len Brown 2007-08-07 13:47:27 UTC
John,
While the symptoms are the same, the cause is different on your DG965RY --
as its SSDT's do include EIST support.  It may be a _PDC issue
on your system. Please open a new bug report.
Comment 16 nona00 2007-08-07 14:21:38 UTC
Created attachment 12308 [details]
acpidump with pmtools-20070714-debug and Bios 642F1D42
Comment 17 Len Brown 2007-08-08 18:52:39 UTC
Andreas, thanks for the debug acpidump.
It shows that when we use the RSDT instead of the XSDT
that we find the SSDT's needed to enable EIST.
(there, is that enough acronyms for a single sentence?:-)

The fix is certainly to disqualify the XSDT from use because
it has null addresses in it.  debug patch on the way...
Comment 18 nona00 2007-08-19 07:22:12 UTC
(In reply to comment #17)
> Andreas, thanks for the debug acpidump.
> It shows that when we use the RSDT instead of the XSDT
> that we find the SSDT's needed to enable EIST.
> (there, is that enough acronyms for a single sentence?:-)
> 
> The fix is certainly to disqualify the XSDT from use because
> it has null addresses in it.  debug patch on the way...

is the patch already done?
Comment 19 Alan Jenkins 2007-08-20 04:07:55 UTC
I think I have the same bug as this one.  Filed separately as #8911, with similar attachments (dmesg with acpi & cpufreq debug, acpidump and acpidump-20070714-debug output).

/me queues up behind Andreas waiting for debug patch.
Comment 20 ykzhao 2007-08-20 18:29:10 UTC
Created attachment 12464 [details]
Introduce boot option acpi=rsdt_forced

    Maybe XSDT has NULL entry address. When it is found that
XSDT has NULL entry address, the promote info is given to user
("XSDT has NULL entry address, please try to boot with acpi=rsdt_forced").
The system had better be booted with acpi=rsdt_forced option
Comment 21 ykzhao 2007-08-21 03:58:28 UTC
Created attachment 12468 [details]
Force to use RSDT when XSDT has NULL entry

    Maybe XSDT has NULL entry address. When it is found that
XSDT has NULL entry address, the promote info is given to user
("XSDT has NULL entry address, Force to use RSDT ") and RSDT is
used automatically.
Comment 22 Patrizio Bassi 2007-08-21 04:36:49 UTC
will be this included in 2.6.23?
Comment 23 nona00 2007-08-21 05:16:32 UTC
(In reply to comment #21)
> Created an attachment (id=12468) [details]
> Force to use RSDT when XSDT has NULL entry

Thank you very much for this patch. EIST seems to work now, but i'm getting the following errors at boot:

hpet_resources: 0xfed00000 is busy
ACPI Error (utglobal-0126): Unknown exception code: 0xFFFFFFF0 [20070126]
...
ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._PDC] (Node dfe90608), AE_ALREADY_EXISTS
ACPI: Marking method _PDC as Serialized
ACPI: SSDT 7F6E8750, 00CE (r1  PmRef  Cpu1Ist     3000 INTL 20041203)
Parsing all Control Methods:
Table [SSDT](id 00D9) - 3 Objects with 0 Devices 3 Methods 0 Regions
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]

Can they Be Ignored?
Comment 24 nona00 2007-08-21 05:17:24 UTC
Created attachment 12470 [details]
dmesg of kernel 2.6.22.2 with rsdt patch
Comment 25 ykzhao 2007-08-21 23:23:26 UTC
Created attachment 12479 [details]
get the acpidump output using the attached binary

Can you get the acpidump output using the attached binary? 
Thanks.
Comment 26 nona00 2007-08-22 00:32:38 UTC
(In reply to comment #25)
> Created an attachment (id=12479) [details]
> get the acpidump output using the attached binary
> 
> Can you get the acpidump output using the attached binary? 
does not work:

./acpidump
-bash: ./acpidump: cannot execute binary file

file acpidump
acpidump: ELF 64-bit LSB executable ...

I'm using a 32bit system.
Comment 27 ykzhao 2007-08-22 01:00:39 UTC
Created attachment 12480 [details]
Get ACPIdump output using the attached binary
Comment 28 nona00 2007-08-22 01:05:41 UTC
Created attachment 12481 [details]
acpidump output
Comment 29 ykzhao 2007-08-22 01:58:28 UTC
(In reply to comment #23)
> (In reply to comment #21)
> > Created an attachment (id=12468) [details] [details]
> > Force to use RSDT when XSDT has NULL entry
> 
> Thank you very much for this patch. EIST seems to work now, but i'm getting
> the
> following errors at boot:
> 
> hpet_resources: 0xfed00000 is busy
> ACPI Error (utglobal-0126): Unknown exception code: 0xFFFFFFF0 [20070126]
> ...
> ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._PDC]
> (Node dfe90608), AE_ALREADY_EXISTS
> ACPI: Marking method _PDC as Serialized
> ACPI: SSDT 7F6E8750, 00CE (r1  PmRef  Cpu1Ist     3000 INTL 20041203)
> Parsing all Control Methods:
> Table [SSDT](id 00D9) - 3 Objects with 0 Devices 3 Methods 0 Regions
> 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]
> 
> Can they Be Ignored?
> 
Can you give the dmesg info not using acpi.debug_level ?
The error info is required.
Thanks.
Comment 30 Alan Jenkins 2007-08-22 06:35:22 UTC
*** Bug 8911 has been marked as a duplicate of this bug. ***
Comment 31 Alan Jenkins 2007-08-22 06:40:15 UTC
Created attachment 12485 [details]
dmesg output with errors after patch applied

Heres my dmesg with the same errors, after applying the patch on similar hardware.

Like Andreas, cpufreq now works (and HPET is detected) - yay!  But I still don't have C-states (/proc/acpi/processor/CPU0/power doesn't have anything at all after "states:").
Comment 32 nona00 2007-08-22 09:29:28 UTC
Created attachment 12489 [details]
dmesg of kernel 2.6.22.2 with rsdt patch, without acpi debug
Comment 33 Len Brown 2007-08-22 19:56:49 UTC
(moving this to RESOLVED state to reflect that a patch is present to review and test)
Comment 34 ykzhao 2007-08-23 02:38:50 UTC
(In reply to comment #31)
> Created an attachment (id=12485) [details]
> dmesg output with errors after patch applied
> Heres my dmesg with the same errors, after applying the patch on similar

Can you try to dump some information using the following command ?
acpidump --addr 0x7F6E82C0 --length 0x231 -o SSDT 
Thanks.
Comment 35 ykzhao 2007-08-23 02:47:26 UTC
Can you try to dump some information using the acpidump tool?Using Method are listed:
   acpidump --addr 0x7F6E82c0 --length 0x231 -o SSDT1
   acpidump --addr 0x7f6e8820 --length 0x2F9 -o SSDT2
Thanks.     

(In reply to comment #34)
> (In reply to comment #31)
> > Created an attachment (id=12485) [details] [details]
> > dmesg output with errors after patch applied
> > Heres my dmesg with the same errors, after applying the patch on similar
> Can you try to dump some information using the following command ?
> acpidump --addr 0x7F6E82C0 --length 0x231 -o SSDT 
> Thanks.
Comment 36 nona00 2007-08-23 02:55:59 UTC
Created attachment 12498 [details]
./acpidump --addr 0x7F6E82c0 --length 0x231 -o SSDT1
Comment 37 nona00 2007-08-23 02:56:17 UTC
Created attachment 12499 [details]
./acpidump --addr 0x7f6e8820 --length 0x2F9 -o SSDT2
Comment 38 ykzhao 2007-08-23 03:14:56 UTC
(In reply to comment #37)
> Created an attachment (id=12499) [details]
> ./acpidump --addr 0x7f6e8820 --length 0x2F9 -o SSDT2
> 
Thanks. 
Can you give more information?
acpidump --addr 0x7f6e8750 --length 0xce -o IST1
Comment 39 Alan Jenkins 2007-08-23 05:25:21 UTC
Created attachment 12502 [details]
acpidump --addr 0x7f6e8750 --length 0xce -o IST1

Heres my IST1 dump.

The SSDT acpidumps differed in some ways on my computer, so I've attached those as well [using the exact same commands as Andreas].
Comment 40 nona00 2007-08-23 05:34:22 UTC
Created attachment 12503 [details]
./acpidump --addr 0x7f6e8750 --length 0xce -o IST1
Comment 41 Len Brown 2007-08-24 15:58:48 UTC
Created attachment 12521 [details]
patch vs 2.6.23-rc3 to use RSDT when NULL in XSDT

this refreshed patch from comment #21 applied to acpi-test
Comment 42 Len Brown 2007-08-25 21:03:59 UTC
patch in comment #41 shipped in linux-2.6.23-rc3-git9
Comment 43 ykzhao 2007-08-29 22:45:26 UTC
Thanks for your info. 
I think that the bios has at least two bugs on the computer.
1. XSDT has NULL entry. The bug can be skipped using RSDT when XSDT NULL entry is found.
2. SSDT table is loaded twice. So the sytem prints the info of AE_ALREADY_EXISTS. And we can't fix the error in linux unless the bios is updated.
Of course the error info of "AE_ALREADY_EXISTS" and "AE_NOT_FOUND" can be ignored. They will have no effect on the system.
>
Comment 44 Len Brown 2007-09-05 16:42:32 UTC
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.
Comment 45 nona00 2007-09-06 11:13:40 UTC
Created attachment 12745 [details]
dmesg -s64000 of unpatched 2.6.23-rc5

ACPI Error (utglobal-0126) does not occur with 2.6.23-rc5
Comment 46 ykzhao 2007-09-12 09:01:52 UTC
Andreas Besse, Thanks for the dmesg. It seems that linux-2.6.23-rc5 can work well.
The remaining two bugs in comment #45 are described in the following:
1. AE_NOT_FOUND .Linux will check whether the defined CPU in DSDT exits using two methods.
    a. Using local APIC info. If CPU is enabled in the local APIC table, the CPU exists.
    b. Using the method of _STA method. If the CPU can't be foundin local apic table, the system will check whether the CPU is hot-added. If the method of STA fails, the defined CPU doesn't exist and the system will print the info of AE_NOT_FOUND.
2. Unknown exception code. If HPET table is defined, hpet will be initialized and started(mainly in the function of time_init and late_hpet_init). In the function of hpet_init the linux will check the hpet resources using the following function. 
 acpi_walk_resources(device->handle, METHOD_NAME__CRS, hpet_resources, &data);
 Because the hpet has been initialized, the resource_callback function of hpet_resources will print the info of "hpet is busy" and return -EBUSY(0xFFFFFFFF0). ACPI will check the status of return-code before leaving acpi_walk_resources. 
  Because the return-code(0xfffffff0) isn't defined in the acpi exception table, the system prints the unknown exception code (0xfffffff0).
Of course the above error message can be ignored. It has no effect on the system.
Comment 47 nona00 2007-09-12 09:32:11 UTC
@ Len Brown and ykzhao:

thank you very much for solving the issue and for your explanations.

Andreas 
Comment 48 Alan Jenkins 2007-09-12 13:39:32 UTC
Yes, many thanks for the explanation.  And thanks Adreas for reporting the problem first, so I didn't have to wait so long for it to be fixed for my identical system :-).
Comment 49 ykzhao 2007-09-18 19:20:02 UTC
Created attachment 12866 [details]
Use acpi status code in the callback function of hpet_resources

The status code in ACPI is used instead of the generic error code in the
ACPI callback function of hpet_resources.
For example: -EBUSY is replaced by AE_ALREADY_EXISTS
             -EINVAL is replaced by AE_NO_MEMORY
At the same time it is unnecessay to solve the problem about the error message of AE_NOT_FOUND(processor).
Comment 50 Len Brown 2007-09-20 18:34:39 UTC
patch in comment #49 applied to acpi tree.
This fixes:
ACPI Error (utglobal-0126): Unknown exception code: 0xFFFFFFF0

Please file a new bug against this message:
hpet_resources: 0xfed00000 is busy
Comment 51 Len Brown 2007-09-27 09:25:11 UTC
patch in comment #49 shipped in linux-2.6.23-rc8-git2

That leaves these two outstanding messages:

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

Per comment #44, this reflects a BIOS bug rather than a Linux bug,
so lets keep this one unless we find a many machines
have this same bug we can make it less scary.
(ie. yes Andreas, you can ignore it, since at least in this case,
 Linux is doing the right thing in the face of this BIOS bug.)

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]

Per comment #44, I think Linux can be smarter
and can avoid printing this message.  Yakui,
would you like to take a crack at fixing it?
Comment 52 Robert Moore 2007-09-27 09:33:07 UTC
A possible solution to this problem would be to not print the error message, mark the method serialized and re-run the method. This would fix the similar problem often seen with _BST methods.
Comment 53 Robert Moore 2007-09-27 09:41:14 UTC
I will take a look at this and build a prototype.
Comment 54 Robert Moore 2007-09-27 09:57:09 UTC
Oops, I was thinking of the AE_ALREADY_EXISTS issue, so comments 52 and 53 don't apply here.
Comment 55 Len Brown 2007-10-04 10:31:00 UTC
clearing RESOLVED setting, expecting Yakui to submit a patch
that gets rid of this message.
Comment 56 ykzhao 2007-10-07 19:53:05 UTC
Created attachment 13072 [details]
avoid the error message that processor device is not present
Comment 57 ykzhao 2007-10-07 20:22:48 UTC
Created attachment 13073 [details]
avoid printing the error message that processor device is not present
Comment 58 Len Brown 2007-10-17 00:27:56 UTC
The remaining issue in this bug report is the message:
"AE_NOT_FOUND, Processor Device is not present"
which makes this a duplicate of bug 8570 -- please
test the patch in that bug report.

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

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