Most recent kernel where this bug did not occur: 2.6.12.6 Distribution: Slackware 10.1 Hardware Environment: Toshiba Satellite A60-772 laptop with P4-M 3.2Ghz CPU Software Environment: Problem Description: System (kernel 2.6.13.x (x -- 1, 2, 3, 4)) crashes with 'Attempt to kill init' message (acpi-cpufreq compiled into kernel whith module -- the same result). Before crash, I can see this message (it taken from 2.6.14-rc5): .............................................................................. ACPI-0292: *** Error: Looking up [_PPC] in namespace, AE_ALREADY_EXISTS ACPI-0508: *** Error: Method execution failed [\_PR_.CPU0._PDC] (Node dbf83260), AE_ALREADY_EXISTS acpi-cpufreq: CPU0 - ACPI performance management activated. ACPI-0292: *** Error: Looking up [_PPC] in namespace, AE_ALREADY_EXISTS ACPI-0508: *** Error: Method execution failed [\_PR_.CPU1._PDC] (Node dbf83200), AE_ALREADY_EXISTS acpi-cpufreq: CPU1 - ACPI performance management activated. .............................................................................. I can't send 2.6.13.x dmesg message, because magic sequence doesn't work. After disabling acpi-cpufreq sysntem works normally. With 2.6.12.6 kernel -- all ok. With 2.6.14-rc5 i get the same error message, but system works normally and I can change cpu frequency. Also, acpi_serialize option not helpful. Steps to reproduce: Install 2.6.13 kernel on @#$@$@ Toshiba Satellite A60-772 notebook.
Created attachment 6359 [details] acpidump output No differences in 2.6.12.6 and 2.6.14-5
Created attachment 6360 [details] DSDT No differences in 2.6.12.6 and 2.6.14-5
Created attachment 6361 [details] dmesg output of 2.6.12.6 kernel
Created attachment 6362 [details] dmesg output of 2.6.14-rc5 kernel
Created attachment 6363 [details] DSDT No differences in 2.6.12.6 and 2.6.14-rc5
Created attachment 6364 [details] _PDC call sequence change. This patch should help. Let me know how it goes with this patch. If this works I will send out a cleaner version of this to base later.
This patch normalizes 2.6.13.4 and remove error message from 2.6.14-rc5. Thank you very much -- it's work ! In attachments dmesg from patched 2.6.13.4 and 2.6.14-rc5.
Created attachment 6365 [details] dmesg output of patched 2.6.13.4 kernel
Created attachment 6366 [details] dmesg output of patched 2.6.14-rc5 kernel
Thats great! I will attach a cleaner patch in a day or two.
Created attachment 6367 [details] Cleaner ACPI _PDC cleanup patch Attached is a cleaner (and bigger) patch. Minimally tested at this point and needs more testing before going to the base. Please check whether this still fixes the issue here.
I try cleaner ACPI PDC patch with 2.6.14-rc5 kernel and it's working normally. I can't try it with 2.6.13.4 kernel because file 'linux-2.6.13/arch/ia64/kernel/cpufreq/acpi-cpufreq.c' doesn't exist. Later I can test this patch without patching unexisting files.
Created attachment 6377 [details] dmesg of 2.6.14-rc5 kernel with applied cleaner PDC patch
Thanks. Just testing it against 2.6.14-rc5 should be enough. I don't think you need to retest it with 2.6.13. This patch will need some more testing and I expect it to go in 2.6.15 timeframe. So, you may still see failures with 2.6.14 release :(.
*** Bug 4454 has been marked as a duplicate of this bug. ***
Cleaner PDC patch seems to be not included in 2.6.15-rc1 2.6.15-rc1 works without patch same as 2.6.14, with patch -- all ok.
Created attachment 6731 [details] refreshed patch against 2.6.15-rc3 acpi tree refreshed patch from comment 11 applied to acpi-test tree
Before this patch an SE7525GP2 (dual 3.6GHz Xeon) running the latest BIOS (SE7525GP20.86B.P.09.00.0039.092120051351) was unable to load acpi-cpufreq. After this patch it works normally -- yipee!
Created attachment 6745 [details] 5483 earlier patch had an issue with IPF. Incremental patch to fix it.
patch in comment #19 applied to acpi-test tree
Created attachment 6968 [details] acpidump output This patch causes acpi-cpufreq to ENODEV on Brice Goglin's machine.
Created attachment 6969 [details] brice's dmesg
Brice's dmesg doesn't contains messages, related acpi-cpufreq to ENODEV issue.
Brice's issue was that the preferred native driver, speedstep-centrino, was missing from the configuration. we need to merge these two drivers to make it impossible to mis-configure. Shipped in 2.6.16-rc1-git6 -- closing.