Most recent kernel where this bug did not occur: Distribution: Ubuntu Gutsy 7.10 64bit Hardware Environment: HP Pavillon dv2699el (dv2500 series) laptop Software Environment: latest gutsy 64bit packages Problem Description: cpu frequency scaling not working, seems not recognized at all for CPU. Maybe the culprit is the Phoenix Bios (using latest version F.21 available), as it seems that it only allows MS Vista to manage ACPI functions (on Vista all working well). When modprobing acpi-cpufreq or speedstep-centrino or any other frequency scaling module I get this error: FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.23.11-vanilla/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): No such device No frequency scaling support seems to be available for cpu. brex@ubuntu-box:~$ ls /sys/devices/system/cpu/ cpu0 cpu1 sched_mc_power_savings brex@ubuntu-box:~$ ls /sys/devices/system/cpu/cpu0/ cache crash_notes thermal_throttle topology Cpu info: brex@ubuntu-box:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping : 11 cpu MHz : 2194.742 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4394.01 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management:
Created attachment 14070 [details] acpidump Acpidump from 2.6.23.11-vanilla
Created attachment 14071 [details] dmesg Dmesg from 2.6.23.11 vanilla
Hi, Nicola Will you please attach the following outputs? ./acpidump --addr 0x7fed0735 --length 0x27a -o cpu0ist ./acpidump --addr 0x7fed0412 --length 0x29e -o cpu0cst ./acpidump --addr 0x7fed09af --length 0x0c8 -o cpu1ist ./acpidump --addr 0x7fed06b0 --length 0x085 -o cpu1cst Thanks.
Created attachment 14073 [details] cpu0ist output from: ./acpidump --addr 0x7fed0735 --length 0x27a -o cpu0ist
Created attachment 14074 [details] cpu0cst Output from: ./acpidump --addr 0x7fed0412 --length 0x29e -o cpu0cst
Created attachment 14075 [details] cpu1ist Output from: ./acpidump --addr 0x7fed09af --length 0x0c8 -o cpu1ist
Created attachment 14076 [details] cpu1cst Output of: ./acpidump --addr 0x7fed06b0 --length 0x085 -o cpu1cst
(In reply to comment #3) > Hi, Nicola > Will you please attach the following outputs? > ./acpidump --addr 0x7fed0735 --length 0x27a -o cpu0ist > ./acpidump --addr 0x7fed0412 --length 0x29e -o cpu0cst > ./acpidump --addr 0x7fed09af --length 0x0c8 -o cpu1ist > ./acpidump --addr 0x7fed06b0 --length 0x085 -o cpu1cst > Thanks. Hi Yakui, please see the attachments. Thanks
Thanks for the info. The problem in this bug is caused by the following error in SSDT: CreateDWordField (Arg3, 0x00, S*S0) //S*S0 can't be recognized by ACPI interpreter and it is very clear BIOS bug. Because of this error the _PDC method for CPU0 can't be executed so that OS can't load table dynamically from the address of 0x7fed0735 and 0x7fed0412 , which contains the CST and PSS for CPU0. But the CST and PSS for CPU0 is refered by CPU1, so OS will report the error message of AE_NOT_FOUND(CST, PSS) and acpi_cpufreq driver can't be loaded correctly. This is a BIOS bug and can be fixed by BISO update.
(In reply to comment #9) > Thanks for the info. > The problem in this bug is caused by the following error in SSDT: > CreateDWordField (Arg3, 0x00, S*S0) //S*S0 can't be recognized by ACPI > interpreter and it is very clear BIOS bug. > > Because of this error the _PDC method for CPU0 can't be executed so that OS > can't load table dynamically from the address of 0x7fed0735 and 0x7fed0412 , > which contains the CST and PSS for CPU0. But the CST and PSS for CPU0 is > refered by CPU1, so OS will report the error message of AE_NOT_FOUND(CST, > PSS) > and acpi_cpufreq driver can't be loaded correctly. > > This is a BIOS bug and can be fixed by BISO update. Thanks for pointing this out. Since I'm already running latest bios, can I just fix DSDT myself and load it dinamically at boot to bypass the problem? In this case, can you please just tell me how to proceed with the fix? Thanks a lot. Nicola
Created attachment 14115 [details] Try the customed DSDT
Will you please try the customed DSDT in comment #10 and attach the output of dmesg? How to use the customed DSDT can found in the following address: http://www.lesswatts.org/projects/acpi/faq.php Thanks.
Created attachment 14119 [details] Try the customed DSDT
Sorry for late reply. I did try your suggestion but didn't work as expected: it did load: brex@ubuntu-box:~$ dmesg | grep DSDT [ 0.000000] ACPI: DSDT 7FED0D54, AE72 (r2 INTEL CRESTLNE 6040000 MSFT 3000000) [ 18.912770] ACPI: Looking for DSDT in initramfs... successfully read 41082 bytes from /DSDT.aml. [ 18.912932] ACPI: Table DSDT replaced by host OS [ 18.913100] ACPI: DSDT 00000000, A07A (r2 INTEL CRESTLNE 6040000 INTL 20061109) [ 19.321187] ACPI: EC: Look up EC in DSDT but: FATAL: Error inserting acpi_cpufreq (/lib/modules/2.6.22-14-generic/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko): No such device even though your DSDT fixed the `Acpi Error [...] AE_NOT_FOUND` problem. Probably this is not linked to frequency scaling. what I did in these days was to test also old bios (F.13) and on it I found that frequency scaling was still working ok under linux, if this can be of any help.
Will you please attach the output of dmesg? It will be great if you can enable the debug function of ACPI in kernel configuration and boot the system with the option of "acpi.debug_layer=0x01000011 acpi.debug_level=0x1f". Of course the customed DSDT is also required.
Please set CONFIG_CPU_FREQ_DEBUG and boot with cpufreq.debug=7 as well. And attach the dmesg after loading acpi-cpufreq driver.
Created attachment 14140 [details] Dmesg with ACPI & CPU_FREQ debugs activated As per your requests.
Hi Yakui and Rui, thanks for your care. Please find the attachment in comment #17 as per your requests.
Created attachment 14165 [details] Try the customed DSDT Hi, Nicola thanks for the log. From the dmesg log in comment #17 it seems that one SSDT table can't be loaded because of the failure. Will you please try this customed DSDT ? Thanks.
Hi yakui, this works great! Just 2 things to comment on: 1. [ 13.965572] ACPI: Looking for DSDT in initramfs... successfully read 41851 bytes from /DSDT.aml. [ 13.965606] ACPI: Table DSDT replaced by host OS [ 13.965608] ACPI: DSDT 00000000, A37B (r2 INTEL CRESTLNE 6040000 INTL 20061109) [ 13.967785] ACPI Error (dswload-0334): [SSDT] Namespace lookup failure, AE_ALREADY_EXISTS [ 13.967789] ACPI Exception (psloop-0225): AE_ALREADY_EXISTS, During name lookup/catalog [20070126] Are those errors serious problems? 2. [ 14.301427] ACPI: System BIOS is requesting _OSI(Linux) [ 14.301429] ACPI: Please test with "acpi_osi=!Linux" Do I need to test with this boot switch?
Hi, Nicola It is a good news that the laptop can work after using the customed DSDT. Please attach the output of dmesg. It will be great if you can test with boot option of "acpi_osi!=Linux". In your laptop there are two SSDT tables and the content of one SSDT table is copied into customed DSDT. When the SSDT table is loaded by OS, some nodes already exist and OS reports the above error message. Of course the error message is not a serious problem and they won't affect the system.
Created attachment 14187 [details] dmesg with acpi_osi=!Linux switch Hi Yakui, first of all merry christmas :) This is the dmesg with acpi_osi=!Linux, it's not with debug options enabled, tell me if you need that. Anyway I don't know why it still asks to boot with acpi_osi=!Linux even if I added that switch to kernel line on menu.lst...tell me if I've done something wrong...thanks!
HI, Nicola Thanks for the test and it is enough. The message can be ignored and the system is working well. Your system only reports the message regardless of boot option(acpi_osi!=linux) and it doesn't matter. The root cause of this bug is caused by BIOS . It is appropriate to fix this bug by BIOS update although the customed DSDT can make your system work well. So I will close this bug.
Yakui, just a question, since I've just tried a new bios with HP, hoping that they would have solved the problem, but it still persist, may I know what part I should modify to have a consistent DSDT table also for new bios? thanks
Will you please attach the acpidump output for new bios?
Created attachment 15055 [details] DSDT.aml for bios F.25 This is DSDT.aml for bios F.25, should be ok for you. Please tell me if you need anything else, thanks
Hi, Nicola I am sorry for the delay. Before bios is upgraded, the error occurs in the SSDT2.dsl. >Method (_OSC, 4, NotSerialized) { > CreateDWordField (Arg3, 0x00, S*S0) //incorrect, should be STS0 CreateDWordField (Arg3, 0x04, CAP0) You should modify the SSDT2.dsl file and put all the content in SSD2.dsl into DSDT.dsl. (Now linux only supports custom DSDT and can't support custom SSDT). Please check whether the error still exists in the SSDT2.dsl after bios is upgraded. If it still exists, you can modify it and see whether the custom DSDT can make cpufreq work. thanks.
*** Bug 10277 has been marked as a duplicate of this bug. ***