Bug 8630 (besse)
|
Description
nona00
2007-06-14 14:21:40 UTC
Created attachment 11752 [details]
Acpi-Logfile
Created attachment 11753 [details]
decompiled DSDT
Created attachment 11754 [details]
cpuinfo
Created attachment 11755 [details]
dmesg with ACPI_DEBUG=y
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.
oops, i really need the complete output from acpidump to get a better look at this one -- please attach it. 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.
similar issue with me. windows scale, linux not after a bios update and reset to default values it came back working. strange because windows worked like a charm even before it.... 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]
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. Created attachment 12243 [details]
dmesg output for 2.6.21.1 booting Intel DG965RY firmware 1687
Created attachment 12244 [details]
acpidump output for Intel DG965RY version 1687
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 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. Created attachment 12308 [details]
acpidump with pmtools-20070714-debug and Bios 642F1D42
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... (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? 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. 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
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.
will be this included in 2.6.23? (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? Created attachment 12470 [details]
dmesg of kernel 2.6.22.2 with rsdt patch
Created attachment 12479 [details]
get the acpidump output using the attached binary
Can you get the acpidump output using the attached binary?
Thanks.
(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. Created attachment 12480 [details]
Get ACPIdump output using the attached binary
Created attachment 12481 [details]
acpidump output
(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. *** Bug 8911 has been marked as a duplicate of this bug. *** 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:").
Created attachment 12489 [details]
dmesg of kernel 2.6.22.2 with rsdt patch, without acpi debug
(moving this to RESOLVED state to reflect that a patch is present to review and test) (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. 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. Created attachment 12498 [details]
./acpidump --addr 0x7F6E82c0 --length 0x231 -o SSDT1
Created attachment 12499 [details]
./acpidump --addr 0x7f6e8820 --length 0x2F9 -o SSDT2
(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 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].
Created attachment 12503 [details]
./acpidump --addr 0x7f6e8750 --length 0xce -o IST1
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 patch in comment #41 shipped in linux-2.6.23-rc3-git9 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. > 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.
Created attachment 12745 [details]
dmesg -s64000 of unpatched 2.6.23-rc5
ACPI Error (utglobal-0126) does not occur with 2.6.23-rc5
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. @ Len Brown and ykzhao: thank you very much for solving the issue and for your explanations. Andreas 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 :-). 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).
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 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? 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. I will take a look at this and build a prototype. Oops, I was thinking of the AE_ALREADY_EXISTS issue, so comments 52 and 53 don't apply here. clearing RESOLVED setting, expecting Yakui to submit a patch that gets rid of this message. Created attachment 13072 [details]
avoid the error message that processor device is not present
Created attachment 13073 [details]
avoid printing the error message that processor device is not present
|