Latest working kernel version: 2.6.27.7 (the _PR_... message did not appear) Earliest failing kernel version: not know Distribution: Bluewhite64 Linux (x86_64) Hardware Environment: AMD Turion(tm) 64 X2 Mobile Technology TL-50 processors (2 cpu cores) (version 2.20.00) Problem Description: When loading acpi-cpufreq module it return the below message. Also, CPU scaling is not working. ACPI Warning (nspredef-0858): \_PR_.CPU1._PSD: Return Package type mismatch at index 3 - found [NULL Object Descriptor], expected Integer [20080926] ACPI: Invalid _PSD data ACPI Warning (nspredef-0858): \_PR_.CPU2._PSD: Return Package type mismatch at index 3 - found [NULL Object Descriptor], expected Integer [20080926] ACPI: Invalid _PSD data Steps to reproduce: try to load acpi-cpufreq module on a 64-bit kernel before the powernow-k8 module at boot time. If I try to load the acpi-cpufreq after the powernow-k8 module it return: FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.28.7/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko): Device or resource busy
Will you please attach the output of acpidump? Do you try the power-k8 cpufreq driver for AMD 64X2 ? Thanks.
does the acpi-cpufreq driver work for you in 2.6.27.7?
Created attachment 20538 [details] acpidump
(In reply to comment #1) > Will you please attach the output of acpidump? See the attached file. > Do you try the power-k8 cpufreq driver for AMD 64X2 ? > Thanks. > Yes. Also tested on a AMD Phenom II 940 and the acpi-cpufreq has the same output message.
(In reply to comment #2) > does the acpi-cpufreq driver work for you in 2.6.27.7? > No, the same output message. Also. tested last night the 2.6.29-rc8 on this laptop and both messages appear.
(In reply to comment #0) > Latest working kernel version: 2.6.27.7 (the _PR_... message did not appear) then I'm confused by this. You said the _PR_... warning message did not apprear in 2.6.27.7...
(In reply to comment #6) > (In reply to comment #0) > > Latest working kernel version: 2.6.27.7 (the _PR_... message did not > appear) > > then I'm confused by this. You said the _PR_... warning message did not > apprear > in 2.6.27.7... > The _PR_ message appear in 2.6.28.8 and 2.6.29-rc8. The acpi-cpufreq messages appear in 2.6.27.7, 2.6.28.7 and 2.6.29-rc8.
hah, got it. In 2.6.29-rc8, please 1.apply the customized DSDT attached below, 2.set CONFIG_CPUFREQ_DEBUG=y, CONFIG_X86_ACPI_CPUFREQ=y 3.rebuild and boot with cpufreq.debug=7, 4.attach the dmesg output.
Created attachment 20540 [details] customized DSDT
Created attachment 20543 [details] dmesg
Okay, 1. the _PR_ message, this is actually a BIOS bug. Name (_PSD, Package (0x01) { Package (0x05) { 0x05, 0x00, 0x00000000, 0x000000FD, } }) _PSD should return a package with 5 elements, but only four in this BIOS. 2. acpi_cpufreq driver message This just indicates that acpi_cpufreq driver doesn't support this processor. i.e. we can not control the processor p-state via acpi-cpufreq driver. I guess there is no real problem except these warning messages on your box, right? I'll close this bug as we will not fix it. please re-open it if you still have any questions.
There appears to be more to this problem than simply a missing package element. Here is the actual disassembly: Name (_PSD, Package (0x01) { Package (0x05) { 0x05, 0x00, 0x00000000, 0x000000FD } }) Zero Zero Zero 0x00000002 ACPI Error (psloop-0225): Found unknown opcode FD at AML address 00585759 offset 56ED, ignoring [20090220] The AML parser has become confused in the middle of the package. It looks like the NumProcessors should be 2. Here is the AML from the acpidump: 56f0: 08 5f 50 53 ......_PPC..._PS 5700: 44 12 0f 01 12 15 05 0a 05 0a 00 0c 00 00 00 00 D............... 5710: 0c fd 00 00 00 0c 02 00 00 00 ...........N.\._ The inner package has an AML length of 15 and 5 objects. However, the outside package (_PSD) only has an AML length of 0F. This is what is causing the parser to abort in the middle of the package. The outside package should have an AML length at least as long as the inner package. Compiling with the original compiler used for the BIOS (iASL 20060113), we get: Name (_PSD, Package (0x01) { Package (0x05) { 0x05, 0x00, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF } }) 00000057....08 5F 50 53 44 ................................. "._PSD" 0000005C....12 18 01 ....................................... 0000005F....12 15 05 0A 05 0A 00 0C FF FF FF FF 0C FF FF FF 0000006F....FF 0C FF FF FF FF .............................. Here, the inside package has the same length (15), and the outside package has the correct length (18). I used the 0xFFFFFFFF values to force the compiler to emit DWORD opcodes for the constants (0C) and bring up the package size (AML length) to what we saw in the original BIOS AML code (15). So, I don't think there is a problem with the iASL compiler. This is the kind of package that the BIOS often attempts to change on the fly. For example, if the number of CPUs changes. It may be that the BIOS screwed up the package when it tried to set the number of CPUs on the fly. Here's my guess. This was probably the original BIOS ASL code: Scope (\_PR.CPU1) { Name (_PPC, 0x00) Name (_PSD, Package (0x01) { Package (0x05) { 0x05, 0x00, 0x00, 0x00, 0x00 } }) } Compiled: 00000057....08 5F 50 53 44 ................................. "._PSD" 0000005C....12 0F 01 ....................................... 0000005F....12 0C 05 0A 05 0A 00 0A 00 0A 00 0A 00 ......... Note that now the outside package length is the same as what we have seen in the acpidump -- namely, 0F. Also, note that all of the constants within the inner package are declared with a BYTE opcode (0A). I think that the BIOS stuffed new values into the inner package using DWORD opcodes. It updated the inner package length, but ***forgot to update the outer package length***. Presumably, the original code had a bunch of NOOPs or similar after the inner package so that there was room for the longer constants. The upshot of all this is that we should probably discover what Windows does with this type of problem. If the ACPICA parser did not abort when the outside package length was exceeded, it could probably parse this code as it was "intended". If we need to do this for Windows compatibility, then we should do it.
It would be interesting to get the original AML code if BIOS changes it on the fly. Arny, would you please boot with acpi=off and then attach the acpidump output?
Created attachment 20609 [details] acpidump with acpi=off
The 2 acpidump files(acpi=off and acpi on) are same. Bob, is it possible that BIOS change the aml code before OS starts?
I have made a bios update, attached below is the acpidump. Also, the dump is the same if I use acpi=off. I think I forgot to mention, the real problem is that I cannot scale the CPU frequency. I'm using vanilla kernels here. I found something similar here: https://bugs.launchpad.net/ubuntu/+source/kdebase/+bug/322590 It looks like Ubuntu managed to fix the scaling but maybe patching the kernel, I will test they liveCD to seeif the acpi-cpufreq is loading and the scaling is working.
Created attachment 20616 [details] acpidump with new BIOS
(In reply to comment #16) > I think I forgot to mention, the real problem is that I cannot scale the CPU > frequency. I'm using vanilla kernels here. You can scale the CPU frequency with the custom DSDT in comment #11, right?
No, there are two problems here. 1. the the _PSD warning, this is because the buggy acpi tables exported by BIOS 2. cpu p-state not working, this is because that the HARDWARE address space is used for p-state control on a non-Intel processor, which is not supported. Q1 is a BIOS issue, and Q2, it's also not a software problem. We don't know why the HARDWARE address space is exported and don't know if it works, unfortunately we don't have any AMD guys here to consult. Venki, do you have any thought?
Arny, please try powernow-k8 instead.
Ok. I have tested different kernel configurations, with ACPI modules and ACPI build in. I can scale the CPU using cpufrequtils when the powernow-k8 driver is loaded.
okay. close this bug because 1. it doesn't have a _PSD method so the warning message is right. 2. powernow-k8 can be used for cpu p-state control instead of acpi-cpufreq driver.