Latest working kernel version: Earliest failing kernel version:2.6.22 Distribution:debian (lenny), ubuntu(gutsy and hardy), gentoo(livecd) Hardware Environment:hp dv2756tx laptop, stock config, T9300 core 2 duo processor Software Environment: Problem Description:acpi_cpufreq driver will not load, says no device. i am having the same problem as someone posted on bug 9486 with an hp laptop and not being able to load this driver as listed in bug 9486 post #13, i have compiled a debugging enabled kernel and booted with the requested options. I have the dmesg and acpidump from booting into a 2.6.24.3 kernel built with debugging for acpi The original poster does not seem to have followed up by posting a new bug, so since I am having this problem, I want to pick up where he left off. when i run acpidump -o acpidump.txt i get the message afterwards that bad checksum for generic tables. of note from dmesg that i can tell is : ACPI Error (exnames-0219): Bad character 01 in name, at ffffc20000609067 [20070126] and Marking TSC unstable due to TSCs unsynchronized if there is anything else i need to add please let me know. Steps to reproduce: boot any prebuilt kernel from a distribution or a self build kernel downloaded from kernel archives.
Created attachment 15406 [details] acpidump output
Created attachment 15407 [details] dmesg from 2.6.24.3 kernel boot
Disassemble SSDT2, I got "ACPI Warning (nssearch-0421): Found bad character(s) in name, repaired: [EI*0]" Does it work in windows?
(In reply to comment #3) > Disassemble SSDT2, I got > "ACPI Warning (nssearch-0421): Found bad character(s) in name, repaired: > [EI*0]" > Does it work in windows? > yes the scaling works perfectly in windows vista, I checked by changing power profiles and monitoring with a 3rd party hardware monitoring utility and can see the changes occurring scales all the way down to 800mhz and seems like everything in between. I do not know what you mean by disassemble SSDT2, is this a step you would like me to take? Not sure if this matters or not but I can monitor the Graphics chip throttling in linux with the nvidia driver, and the brightness can be changed on the lcd and it recognizes battery, ac adapter etc, so most power management seems to work.
Hi, Kevin In the SSDT2.dsl there exists the following errors: > Method (_OSC, 4, NotSerialized) { > CreateDWordField (Arg0, 0x00, IID0) > CreateDWordField (Arg0, 0x04, IID1) > CreateDWordField (UID0, 0x00, EI*0) //Maybe should EIDO Because of the above error OSPM will report the following error message and can't load cpufreq table for the CPU0. Of course the error will have no effect on the graphics, lcd or battery. >ACPI Exception (dsutils-0735): AE_AML_BAD_NAME, While creating Arg 3 [20070126] >[ 25.640386] ACPI Error (psparse-0537): Method parse/execution failed >[\_PR_.CPU0._OSC] (Node ffff81013b23f220), AE_AML_BAD_NAME >[ 25.640668] ACPI Error (psparse-0537): Method parse/execution failed >[\_PR_.CPU0._PDC] (Node ffff81013b23f200), AE_AML_BAD_NAME But it is interesting that scaling works in vista.
Is there anything that can be done to correct this? Any sort of work around?
after following these instructions to look at the disassembled DSDT.dat http://gentoo-wiki.com/HOWTO_Fix_Common_ACPI_Problems#Diagnosing_a_Buggy_DSDT I took a peek at Method (_OSC, 4, NotSerialized) and on line 3326 of the disassembled DSDT, it indeed says EIDO, not EI*0 the line reads CreateDWordField (UID0, 0x00, EID0) it does not say EI*0 in the decompiled DSDT. Is this a possible indication of a runtime error if the EID0 is becoming EI*0 in the generated table? I do not have much experience with ACPI, but it seems odd to me that the deconstructed DSDT would not have the incorrect EI*0, which apparently is the problem, but the table trying to be loaded by the kernel does. If i am understanding that method correctly it is somehow checking which lines to add to the SSDT2 table some sort if then type structure. But if isal generated code says EID0, why does the kernel see EI*0 sorry if this is completely off base, but I really find it odd that the method doesn't match the apparent output error. I am attaching the decompiled DSDT.dat incase that helps. It was made with the iasl -d dsdt.aml > dsdt.asl command. I also tried to used acpidump to get the DSDT, but it gives me errors and I cannot get a DSDT this way. # acpidump > acpidump.out $ acpixtract DSDT acpidump > DSDT.dat $ iasl -d DSDT.dat hope this means something.
Created attachment 15444 [details] iasl decompiled DSDT from /proc/acpi/dsdt
Hi, Kevin There is no difference between the DSDT.dsl in comment #7 and that in the comment #8. In fact the error happens in the SSDT2.dsl file as described in the comment #5. (SSDT2.dsl is extracted from the SSDT2.dat, which is located in the address of 0xBFECFEDF). Will you please use the pmtool-20071116 to dump the acpi tables? The pmtool-20071116 can be found in the following address: http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ Thanks.
Hello, I followed the link in comment #9 and dumped the tables. it was as you said in the SSDT2.dsl file. but when I dumped the acpi table to acpidump.txt, it gave me this error Wrong checksum for SSDT Wrong checksum for SSDT! This would indicate to me that somewhere the SSDT table is either getting read wrong or was stored with errors in my bios. How do I find out if it was written incorrectly to the bios. Because of the checksum error, isn't it possible that somehow the table is either getting read incorrectly, or somehow it is corrupted on my computer's bios. the fact that it works in windows might suggest the bios is not corrupted though. But the fact that in the DSDT has almost an identical method which has EID0 instead of EI*0. I hope my line of thinking makes sense. I think the checksum error is indicative of something. I would try to just reflash my bios to make sure it wasn't corrupted, but HP only has version f.25 available for download, but my computer already has a version f.26 installed on it. because of the same result I am assuming there is no point in attaching acpidump.txt again. Please let me know if there is anything else that would help. do you know what is causing the checksum error? especially if it is in the SSDT which is where our problem is. Thank you
Created attachment 15472 [details] using pmtools-20071116 acpidump.txt decided to attach anyway. just incase it helps.
Thanks for the info. The error in SSDT2.dsl is related with the error message "Wrong checksum for SSDT". The SSDT2 table is located in the address 0xbfecfedf, which is reserved as ACPI NVS region by BIOS. >ACPI: SSDT BFECFEDF, 04E6 (r1 PmRef CpuPm 3000 INTL 20061109) >BIOS-e820: 00000000bfec0000 - 00000000bfedf000 (ACPI NVS) The checksum error is caused by the incorrect content of 0xBfecfedf - 0xbfed03c4. Anyway, will you please attach the output of the following command? acpidump --addr 0xbfecfedf --length 0x4e6 -o ssdt2 >But the fact that in the DSDT has almost an identical method which has >EID0 instead of EI*0 What you said is right. In fact several _OSC methods are defined under several devices. For example: CPU0, CPU1, PCI0. But the error occurs in the _OSC method defined in the CPU0 device.
Created attachment 15521 [details] output as requested after decompiling with iasl it has the same * problem. is it possible this is a hardware problem that requires warranty work? could it be as simple as just re-flashing the bios? one other question, is there any way to just keep a static copy of a corrected SSDT2 file and point the kernel to that instead? but shouldn't an error like this break window's cpu scaling as well?
Hi, Kevin This problem is caused by the broken bios. It is more appropriate to fix it by upgrading bios.
*** Bug 10513 has been marked as a duplicate of this bug. ***
linming, how should we handle this bug? this is clearly a BIOS bug. Is it possible we could workaround it in acpica? if not, we should reject it.
No workaround for this case.
can not we add a kernel parameter and allow users to store ACPI tables in an extra buffer if needed?
oops. sorry, I've mixed it up with another bug... please ignore comment #18.
If this works in Windows, we should try to figure out why, and how to do it in ACPICA.
Hi, Kevin As there exist some errors in the SSDT table, the acpi_cpufreq driver can't be loaded correctly on your machine. But it is very strange that cpufreq scaling can work on windows. Maybe windows uses another cpufreq driver, which is different with acpi_cpufreq. Will you please try the P4 clock cpufreq driver on your machine and see whether the cpufreq scaling can work? Thanks.
I guess Windows uses an replacement DSDT? I don't think it would be very useful to use the p4 clock throttling driver. The tables supplied by the BIOS are just totally broken, aren't they? I don't think we can do much about that other than recommending the user tries to find a working DSDT somewhere (might be somewhere in the windows installation) and uses the DSDT replacement CONFIG option. Any reason we should keep this bug open?
Close this one since it's obviously a bios bug.
wow, and you wonder why people get turned off from linux. could you at least point me in the direction on how I can use a custom SSDT table? I've already updated my BIOS 3 times from HP so I can assume they have no intention of fixing this themselves.
ok, further correction, it seems that the driver is now loading, but no governors are available other than performance. It appears the bios/kernel stuff has been worked out. now i need to find out why its not working correctly.