Bug 9586
Summary: | ACPI Error [...] AE_NOT_FOUND -> Cpu frequency scaling not working on C2D T7500 | ||
---|---|---|---|
Product: | ACPI | Reporter: | Nicola B. (icestorm) |
Component: | BIOS | Assignee: | ykzhao (yakui.zhao) |
Status: | REJECTED WILL_NOT_FIX | ||
Severity: | normal | CC: | acpi_power-processor, ralpax, rui.zhang |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.23.11 vanilla | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
acpidump
dmesg cpu0ist cpu0cst cpu1ist cpu1cst Try the customed DSDT Try the customed DSDT Dmesg with ACPI & CPU_FREQ debugs activated Try the customed DSDT dmesg with acpi_osi=!Linux switch DSDT.aml for bios F.25 |
Description
Nicola B.
2007-12-16 13:05:45 UTC
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. *** |